Die Herkunft von Code kennzeichnen: warum es nötig ist und wie es ohne Leistungskontrolle geht
Die Frage klingt bürokratisch und ist die Voraussetzung für alles andere: Wenn niemand weiß, welcher Anteil des Codes aus einem Modell stammt, lässt sich weder die Lizenzlage klären noch begründen, welche Stellen zusätzliche Prüfung brauchen.
Die Kennzeichnung, ob ein Modell an einer Änderung beteiligt war, ist Voraussetzung für Risikozuordnung, Lizenzklärung und die eigene Auswertung. Rechtlich entscheidend ist die Trennung: Erfasst wird die Herkunft der Änderung am Commit, nicht die Leistung der Person am Konto; ausgewertet wird aggregiert über Bereiche und Zeiträume. Der Betriebsrat sollte vor der Einführung einbezogen werden — mit der Zusage, dass keine personenbezogene Auswertung und keine Verwendung in der Leistungsbeurteilung erfolgt.
Wofür die Angabe tatsächlich gebraucht wird
Für drei Dinge. Erstens für die Risikozuordnung: Wenn sich zeigt, dass generierte Änderungen in einem bestimmten Bereich häufiger nachgebessert werden müssen, ist das ein Grund, dort die Prüftiefe anzuheben — ohne die Kennzeichnung ist diese Auswertung nicht möglich. Zweitens für Lizenz- und Urheberfragen, die in Kundenverträgen zunehmend auftauchen. Drittens für die eigene Lernkurve: Welche Aufgaben laufen gut, welche nicht.
Der Unterschied, auf den es rechtlich ankommt
Erfasst wird die Herkunft der Änderung, nicht die Leistung der Person. Technisch heißt das: Die Kennzeichnung hängt am Commit oder am Pull Request, nicht am Benutzerkonto, und die Auswertung erfolgt aggregiert über Bereiche und Zeiträume, nicht über Personen. Diese Trennung ist sauber ziehbar, und sie ist der Punkt, an dem eine Betriebsvereinbarung steht oder fällt.
Wie die Kennzeichnung praktisch entsteht
Am zuverlässigsten über einen Vermerk, den die Entwicklungsumgebung oder der Assistent selbst setzt — als Metadatum am Commit, nicht als Kommentar im Code. Eine Selbsteinschätzung im Pull Request ist der einfachere Einstieg und in der Praxis erstaunlich verlässlich, solange klar ist, dass sie nicht bewertet wird. Was nicht funktioniert, sind nachträgliche Schätzungen aus dem Code selbst: Die Erkennungsverfahren dafür sind zu ungenau, um eine Entscheidung darauf zu stützen.
Der Weg über die Mitbestimmung
Vor der Einführung, nicht danach. Die Erfahrung zeigt, dass die Zustimmung meistens kommt, wenn drei Punkte zugesagt und technisch abgesichert sind: keine personenbezogene Auswertung, keine Verwendung in der Leistungsbeurteilung, und Einsicht in die Auswertungen für den Betriebsrat. Wer diese drei Punkte im ersten Gespräch anbietet, verkürzt den Prozess erheblich.
Was zu erwarten ist
Ein Anteil, der höher liegt als gedacht, und eine Verteilung, die überrascht: Meist konzentriert sich generierter Code auf Tests, Anbindungen und Standardstrukturen, während die kritische Fachlogik weiterhin überwiegend von Hand entsteht. Diese Erkenntnis allein verändert oft die Diskussion, weil sie den Vorwurf entkräftet, es werde „einfach alles generiert".
Häufige Fragen
Lässt sich generierter Code nicht automatisch erkennen?
Nur unzuverlässig. Die verfügbaren Erkennungsverfahren liefern Wahrscheinlichkeiten, keine Nachweise, und sie irren in beide Richtungen. Eine Entscheidung über Prüftiefe oder Lizenzfragen darauf zu stützen, wäre nicht belastbar.
Ist eine Selbsteinschätzung nicht zu ungenau?
Sie ist ungenauer als ein automatischer Vermerk und in der Praxis brauchbar, solange klar ist, dass sie nicht in eine Bewertung einfließt. Sobald jemand befürchtet, die Angabe könnte gegen ihn verwendet werden, wird sie wertlos — was wieder für die saubere Trennung von Änderung und Person spricht.
Welche Rolle spielt das in Kundenverträgen?
Eine wachsende. Zusicherungen zu Urheberrechten und zur Herkunft ausgelieferter Software finden sich zunehmend in Rahmenverträgen. Wer die Frage nicht beantworten kann, gibt entweder eine Zusicherung ohne Grundlage ab oder verliert Zeit in der Verhandlung.
Wie lange dauert eine Betriebsvereinbarung dazu?
Sehr unterschiedlich, aber deutlich kürzer, wenn die drei Zusagen von Anfang an technisch abgesichert und nicht nur versprochen sind. Der längste Teil ist meistens nicht die Verhandlung, sondern der Nachweis, dass eine personenbezogene Auswertung technisch gar nicht möglich ist.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
AI Engineering Review ansehen →
