Code Ownership in Zeiten von LLM

Wer verantwortet den Code, wenn ihn niemand geschrieben hat?

Martina scrollt durch den Code, bleibt stehen und scrollt wieder zurück. Dann noch einmal. Der Code ist funktional, aber schwer zu lesen. Es gibt verschachtelte Logik, wenig sprechende Namen und kaum Hinweise darauf, warum bestimmte Entscheidungen getroffen wurden. Fachlich bewegt sich die Implementierung an einer Grenze, die man zumindest diskutieren sollte.

Irgendwann stellt sie die naheliegende Frage: „Wer hat das hier eigentlich geschrieben?“

Ein kurzer Moment der Stille. Die Anwesenden schauen sich an. Niemand meldet sich. Nicht aus Desinteresse, sondern weil sich niemand zuständig fühlt. Der Code liegt schon seit ein paar Wochen im System. Er funktioniert. Irgendwie.

„Dirk, stammt der Code nicht von dir?“, wirft Bernd ein.

Nach kurzer Überlegung antwortet Dirk: „Stimmt. Große Teile davon habe ich mit ChatGPT gepromptet und dann kurz angepasst. Es sah plausibel aus.“

Damit ist die Frage beantwortet. Und gleichzeitig ist sie es nicht. Denn die eigentliche Unsicherheit bleibt: Wer trägt hier die Verantwortung für Struktur, fachliche Korrektheit und langfristige Wartbarkeit?

Dirk hat den Code nicht im klassischen Sinne geschrieben. Das LLM hat ihn generiert. Der Code wurde freigegeben. Aber niemand kann heute klar sagen, wer für seine Struktur, fachliche Korrektheit und Wartbarkeit geradesteht.

Genau hier beginnt das Thema „Code Ownership in Zeiten von LLM“. Nicht als neue Theorie, nicht als Zukunftsvision, sondern als ganz praktische Frage im Entwicklungsalltag.

Was sollte Code Ownership ursprünglich leisten?

Code Ownership ist kein Selbstzweck. Das Konzept entstand aus einem praktischen Bedarf: Es sollte Verantwortung in komplexen Softwaresystemen sichtbar und handhabbar machen.

Dabei ging es nie primär darum, festzuhalten, wer welchen Code geschrieben hat. Entscheidend war etwas anderes:

• Wer ist ansprechbar, wenn Fragen auftauchen?
• Wer fühlt sich zuständig, wenn sich Anforderungen ändern?
• Wer steht dafür ein, wenn Fehler auftreten oder sich Entscheidungen im Nachhinein als falsch erweisen?

In klassischen Entwicklungsumgebungen war diese Zuordnung vergleichsweise klar. Code entstand überwiegend manuell. Entwickler oder Teams investierten Zeit, Verständnis und gedankliche Arbeit in ihre Lösungen. In der Regel hatte derjenige, der den Code schrieb, ihn auch verstanden. Verantwortung ergab sich fast automatisch aus der Entstehungsgeschichte.

Die verschiedenen Modelle von Code Ownership setzten genau hier an.

Strong Code Ownership machte die Verantwortung explizit. Bestimmte Personen waren Gatekeeper für klar abgegrenzte Bereiche. Das reduzierte Unsicherheit und erleichterte Entscheidungen, solange die Anzahl der Änderungen überschaubar blieb.

Weak Code Ownership lockerte diese Struktur. Änderungen waren einfacher möglich, ohne dass die Verantwortung vollständig aufgelöst wurde. Die Verantwortung blieb bestehen, auch wenn nicht jede Änderung selbst umgesetzt wurde.

Collective Code Ownership ging noch einen Schritt weiter. Die Verantwortung wurde bewusst geteilt. Die zugrunde liegende Annahme war, dass gemeinsames Arbeiten, Reviews und Austausch ausreichendes Verständnis schaffen, um Qualität und Wartbarkeit zu sichern.

Allen Modellen war eines gemeinsam: Ownership war eng an menschliche Arbeit gekoppelt. An Zeitaufwand, kognitive Anstrengung und das Ringen um tragfähige Lösungen. Genau deshalb funktionierten diese Modelle lange Zeit gut genug. Nicht perfekt, aber stabil.

Der Engpass war klar: Code zu schreiben war aufwendig, Änderungen kosteten Zeit, Komplexität entstand langsam. Verantwortung ließ sich über Nähe zum Code und zur Entscheidung vergleichsweise zuverlässig zuordnen. Doch diese Grundannahme gerät heute ins Wanken, weil neue Möglichkeiten die bisherigen Zusammenhänge verändern.

Welche neuen Möglichkeiten ergeben sich, wenn diese Grundannahmen aufgelöst werden?

Die neuen Möglichkeiten, von denen heute häufig die Rede ist, sind keine Zukunftstechnologie, sondern längst Teil des Entwicklungsalltags. Große Sprachmodelle unterstützen beim Schreiben, Umstrukturieren, Erklären und Ergänzen von Code. Dadurch verschieben sie Annahmen, auf denen Code Ownership bislang beruhte.

Zunächst verändert sich, wie Code entsteht. Während früher jede Zeile bewusst formuliert wurde, entstehen heute größere Codeblöcke in kurzer Zeit. Entwickler beschreiben ein Ziel oder einen Kontext. Das LLM liefert einen Vorschlag. Der menschliche Anteil liegt dabei häufig weniger im Schreiben selbst als im Auswählen, Anpassen und Akzeptieren.

Damit löst sich eine zentrale Kopplung auf. Schreiben und Verstehen fallen nicht mehr automatisch zusammen. Ein Entwickler kann Code übernehmen, der auf den ersten Blick plausibel wirkt, ohne ihn vollständig durchdrungen zu haben. Die Geschwindigkeit, mit der Lösungen entstehen, übertrifft die Zeit, die nötig wäre, um sie vollständig zu verstehen.

Hinzu kommt, dass Änderungen günstiger werden. Komplexer oder fremder Code lässt sich schneller anpassen. Refactorings oder Alternativen sind rasch erzeugt. Dadurch steigt die Änderungsfrequenz und damit auch die Anzahl der Entscheidungen, die getroffen werden müssen, oft ohne als solche wahrgenommen zu werden.

Gleichzeitig entsteht eine neue Form von Scheinsicherheit. Der Code wirkt konsistent, gut strukturiert und nachvollziehbar. Doch Erklärbarkeit ersetzt kein Verantwortungsbewusstsein. Die Fähigkeit eines LLM, eine Begründung zu liefern, sagt nichts darüber aus, ob diese im fachlichen Kontext trägt.

Dadurch verändert sich auch die Rolle von Reviews. Sie dienen weniger der Absicherung handwerklicher Fehler und werden stärker zu Orten, an denen Verantwortung entsteht. Wer einen Vorschlag eines LLM akzeptiert oder freigibt, trifft eine Entscheidung und übernimmt Verantwortung, auch wenn der Code nicht selbst geschrieben wurde.

Genau hier zeigt sich, warum die bisherigen Modelle von Code Ownership unter Druck geraten. Sie setzen voraus, dass Nähe zum Code durch das Schreiben entsteht. LLM entkoppeln diese Nähe jedoch vom Entstehungsprozess. Die Frage ist daher nicht, ob Code Ownership noch gebraucht wird. Die Frage ist, wo sie unter diesen Bedingungen sinnvoll verankert werden kann.

Von Code Ownership zu Decision Ownership

Wenn sich Schreiben und Verstehen entkoppeln, verliert Code Ownership einen Teil ihrer bisherigen Tragfähigkeit. Nicht, weil Verantwortung überflüssig wird, sondern weil sie an der falschen Stelle verortet ist.

In einer Welt, in der Code zunehmend vorgeschlagen statt geschrieben wird, entsteht Verantwortung nicht mehr primär beim Erzeugen von Code. Sie entsteht dort, wo entschieden wird.

Decision Ownership beschreibt genau diesen Punkt. Wer entscheidet, dass ein Vorschlag akzeptabel ist, übernimmt Verantwortung für seine Wirkung. Unabhängig davon, ob der Code manuell geschrieben, gemeinsam erarbeitet oder durch ein LLM erzeugt wurde. Das verschiebt den Fokus. Weg von der Frage, wer den Code erstellt hat. Hin zur Frage, wer ihn fachlich, technisch und organisatorisch verantwortet.

Decision Ownership bedeutet nicht, dass jede Entscheidung formalisiert oder dokumentiert werden muss. Es bedeutet, dass klar ist, wer für bestimmte Arten von Entscheidungen geradesteht. Zum Beispiel für

• die fachliche Korrektheit einer Implementierung,
• die Einhaltung architektonischer Leitplanken und
• die Auswirkungen auf Wartbarkeit, Sicherheit oder Betrieb.

In klassischen Ownership-Modellen waren diese Entscheidungen oft implizit an den Code-Eigentümer gekoppelt. Wer schrieb, entschied. Wer entschied, verstand. Diese Kopplung existiert so nicht mehr.

Mit LLM verschiebt sich der Schwerpunkt. Entscheidungen werden häufiger, kleinteiliger und schneller getroffen. Viele davon passieren beiläufig. Ein Vorschlag wird übernommen, weil er plausibel wirkt. Ein Refactoring wird akzeptiert, weil es sauber aussieht. Genau hier entsteht Decision Ownership, auch wenn sie selten explizit benannt wird.

Wichtig ist dabei eine klare Abgrenzung: Das LLM liefert Vorschläge, es trifft keine Entscheidungen, es trägt keine Verantwortung. Verantwortung entsteht ausschließlich dort, wo Menschen entscheiden, etwas zu übernehmen, freizugeben oder produktiv zu setzen.

Praktisch heißt das für Teams:

• Ownership sollte nicht mehr primär an Dateien, Module oder Verzeichnisse gekoppelt sein.
• Ownership sollte an Entscheidungsstellen sichtbar werden, etwa in Reviews, Freigaben oder Architekturentscheidungen.
• Ownership entsteht durch Akzeptanz, nicht durch Autorschaft.

Decision Ownership ersetzt Code Ownership nicht vollständig. Sie ergänzt und verschiebt sie. Code bleibt relevant. Aber der eigentliche Hebel für Qualität, Wartbarkeit und Risiko liegt zunehmend in den Entscheidungen rund um den Code. Je leichter Code entsteht, desto wichtiger wird die Frage, wer bereit ist, für seine Konsequenzen einzustehen.

Abbildung: Decision Ownership ergänzt Code Ownership

Fazit

Verantwortung lässt sich nicht generieren.

Code entsteht heute schneller, leichter und scheinbar mühelos. Genau das macht ihn trügerisch. Je einfacher Lösungen produziert werden können, desto weniger ist am Code selbst noch erkennbar, wie viel Verständnis, Abwägung und Verantwortung tatsächlich darin steckt.

Code Ownership war lange ein praktikables Mittel, um Verantwortung sichtbar zu machen. Nicht, weil Besitz wichtig war, sondern weil Nähe entstand. Nähe zum Problem, zur Lösung und zu ihren Konsequenzen. Diese Nähe lässt sich heute nicht mehr zuverlässig aus der Entstehung des Codes ableiten.

LLM verschieben den Ort, an dem Verantwortung entsteht. Nicht weg vom Menschen, sondern weg vom Schreiben. Verantwortung entsteht dort, wo entschieden wird, dass etwas gut genug ist. Dass es fachlich trägt und in Betrieb gehen darf.

Das lässt sich nicht automatisieren, nicht delegieren und auch nicht an ein Werkzeug auslagern.

Teams, die Code Ownership weiterhin wirksam leben wollen, müssen sich dieser Verschiebung stellen. Nicht mit neuen Regeln, Rollen oder Prozessen, sondern mit Klarheit. Klarheit darüber, wer Entscheidungen trifft und wer für ihre Folgen geradesteht. Denn je leichter Code entsteht, desto schwerer wiegt jede Entscheidung darüber, ihn zu akzeptieren. Und genau dort beginnt Verantwortung. Auch die von Dirk.

Hinweise:

Hier finden Sie weitere Informationen zu Code Ownership.

Hier können Sie sich unseren kostenlosen Code Ownership Guide herunterladen.

Hier finden Sie eine Einschätzung zu den Code Ownership Arten von Martin Fowler, einem der Autoren und Erstunterzeichner des Agilen Manifests.

Extreme Programming verwendet als Methode inzwischen den Begriff „Shared Code“. Felix Stein propagiert zudem in einer vierteiligen Beitragsserie ein Continuous Code Ownership, da es nicht ausreicht, sich nur im Zuge von anstehenden Modifizierungen mit dem Code zu beschäftigen, da es in der Praxis oftmals mehrere Jahre dauern kann, bis ein bestimmtes Stück Code angefasst wird.

Suchen Sie nach einem Team für Ihre Softwareentwicklung oder -modernisierung? Dann laden Sie sich den t2informatik Steckbrief herunter.

Wollen Sie als Multiplikatorin oder Meinungsführer über Code Ownership in Zeiten von LLM diskutieren? Dann teilen Sie diesen Beitrag in Ihren Netzwerken.

Michael Schenkel hat weitere Beiträge im t2informatik Blog veröffentlicht, u. a.: