Am Ende ist es dein Code

TL;DR: AI kann Code schreiben, aber keine Verantwortung übernehmen. Solange ein Change nicht geprüft ist, behandle ich ihn wie einen fremden Pull Request. Wenn ich ihn akzeptiere, merge und ausliefere, ist seine Herkunft nebensächlich. Am Ende ist es mein Code.

Ein Feature beginnt nicht mit Code

Wenn ich heute mit AI-Agenten entwickle, beginnt die Arbeit nicht mit einem möglichst ausführlichen Prompt und der Bitte, einfach loszulegen.

Zuerst bespreche ich das Feature. Ich kläre das Problem, sammele Ideen und halte den relevanten Kontext fest. Regeln, die über eine einzelne Aufgabe hinausgehen, landen in den Agent Files. Dazu kommen nichtfunktionale Anforderungen: Architekturgrenzen, Sicherheit, Tests, Barrierefreiheit oder andere Erwartungen, die für jeden Change gelten sollen.

Gerade diese dauerhaften Leitplanken greifen Agenten erstaunlich verlässlich auf. Sie verkleinern den Lösungsraum und verhindern viele grobe Abweichungen, bevor die erste Zeile Code entsteht.

Danach wird das Feature in Slices zerlegt. Das geschieht nicht immer vollständig im Voraus. Manchmal zeigt sich erst während der Arbeit, dass eine Aufgabe zu groß ist oder mehrere Zuständigkeiten vermischt. Aber das Ziel bleibt gleich: kleine, logisch verständliche Änderungen mit möglichst wenig Überschneidung zu anderen Bereichen.

Denn Code zu erzeugen ist mit AI sehr leicht geworden. Ihn zuverlässig zu prüfen nicht.

Große Changes bleiben große Changes

AI verändert nicht die grundlegenden Regeln eines guten Pull Requests.

Wenn zu viele Dateien betroffen sind, mehrere Verantwortlichkeiten in einem Change landen oder die Komplexität schon beim Öffnen erschlägt, wird ein Review schwierig. Das gilt für den Code eines Agenten genauso wie für den eines Menschen.

Vielleicht gilt es bei AI sogar noch etwas stärker. Ein Agent ist geduldig und produziert in kurzer Zeit sehr viel. Was aus Sicht der Implementierung beeindruckend wirkt, kann aus Sicht des Reviews eine Zumutung sein.

Deshalb versuche ich nicht, möglichst große Arbeitspakete auf einmal generieren zu lassen. Ein Gesamtfeature darf umfangreich sein. Die einzelnen Änderungen müssen trotzdem so klein bleiben, dass ich sie mit eigener Kraft verstehen, ausprobieren und bewerten kann.

Ein Pull Request ist keine Transportbox für möglichst viel Code. Er ist eine prüfbare Behauptung: Diese begrenzte Änderung löst dieses konkrete Problem und erfüllt diese Erwartungen.

Zunächst ist der Code fremd

AI-generierten Code behandle ich zunächst wie einen fremden Pull Request.

Das bedeutet nicht, dass ich jede Zeile grundsätzlich für verdächtig halte. Durch den bekannten Kontext, die Agent Files und die vereinbarten Anforderungen erwarte ich keine vollkommen beliebige Lösung. Trotzdem habe ich den konkreten Code nicht selbst geschrieben. Ich muss mir erst ein Bild davon machen.

Meine Prüfung verläuft in mehreren Schritten:

1. Scope: Ist der Change so geschnitten wie erwartet oder wurden zusätzliche Zuständigkeiten hineingezogen?
2. Augenscheinliche Prüfung: Passt der Ansatz grundsätzlich? Fallen unnötige Komplexität, merkwürdige Abhängigkeiten oder offensichtliche Abweichungen auf?
3. Manueller Test: Funktioniert die Lösung aus Produkt- und Nutzungssicht?
4. Akzeptanzkriterien: Erfüllt die Implementierung das, was für das Feature vereinbart wurde?
5. Automatisierte Prüfungen: Laufen die relevanten Tests und Qualitätschecks erfolgreich durch?
6. Ergebnisse zusammenführen: Befunde werden korrigiert oder der Change wird zurückgegeben.

Das ist keine spektakulär neue Review-Methode für das AI-Zeitalter. Es ist im Wesentlichen das, was ein Pull Request schon immer verlangt hat: einen begrenzten Scope, nachvollziehbare Entscheidungen und überprüfbares Verhalten.

Wenn AI den AI-Code reviewt

Bei der Prüfung setze ich ebenfalls Agenten ein. Ein Review-Agent kann die Akzeptanzkriterien abgleichen, Tests ausführen und nach Stellen suchen, die mir beim ersten Blick entgangen sind.

Dabei bekommt er bewusst eine andere Rolle als während der Implementierung. Er soll nicht weiterbauen oder die bestehende Lösung verteidigen. Er darf kritisch, kleinkariert und ein wenig nörgelig sein – wie der Lead Developer, der zuverlässig noch einen Stein findet, den er in den Weg legen kann.

Ich habe dafür unterschiedliche Agenten und Modelle ausprobiert. In der Praxis kann auch derselbe Agent mit demselben Modell einen brauchbaren Review liefern, wenn der Prüfauftrag klar wechselt. Das ist keine Garantie für unabhängige Wahrheit. Es ist eine zusätzliche Perspektive, deren Nutzen sich am Ergebnis zeigen muss.

Wenn der Agent relevante Fragen stellt oder Abweichungen findet, hilft er. Wenn nicht, bleibt die Verantwortung trotzdem bei mir. Ein AI-Review ersetzt weder den manuellen Test noch meine Entscheidung, den Change anzunehmen.

Was muss ein Entwickler wirklich verstehen?

Interessant wird die Ownership-Frage, wenn ein anderer Entwickler mit AI arbeitet.

Ich übergebe lieber ein vollständiges Feature als eine kleinteilige Liste vorgefertigter Tasks. Wie ein Entwickler das Feature in Slices zerlegt und welche Werkzeuge er dafür verwendet, ist zunächst seine Angelegenheit. Wenn er meinen Kontext, einen Lösungsansatz und die Akzeptanzkriterien in einen Agenten gibt, ist das für mich vollkommen in Ordnung.

Für das Review ist es sogar weitgehend egal, ob der eingereichte Code manuell, mit Autocomplete oder durch einen Agenten entstanden ist.

Nicht egal wäre diese Antwort:

Keine Ahnung, was das ist. Das hat die AI gemacht.

Damit hätte sich ein Entwickler als Owner seines eigenen Beitrags weitgehend disqualifiziert. „Die AI war es“ ist keine technische Begründung.

Das bedeutet allerdings nicht, dass jede relevante Zeile auswendig erklärt werden muss. Ich bin dabei eher laissez-faire. Teile einer Lösung dürfen wie eine Blackbox funktionieren, wenn ihr Vertrag klar ist, sie die Anforderungen erfüllen und ihr Verhalten zuverlässig überprüfbar ist. Bei unklaren Stellen kann eine zusätzliche Erklärrunde mit einem Agenten helfen.

Entscheidend ist nicht lückenloses Detailwissen. Ein Entwickler muss genug verstanden und geprüft haben, um den Beitrag guten Gewissens zu vertreten.

Verantwortung entsteht bei der Annahme

Bei einem menschlichen Entwickler vertraue ich darauf, dass er die Zerlegung und Umsetzung verantwortet. Bei der direkten Arbeit mit einem Agenten muss ich selbst früher eingreifen. Ich bin beim Brainstorming dabei, prüfe die vorgeschlagenen Slices und korrigiere Fehlentscheidungen, bevor daraus ein großer Change wird.

In beiden Fällen läuft es aber auf denselben Punkt hinaus: Jemand nimmt den Code an.

Wenn ich den Scope geprüft, den Code analysiert, die Lösung getestet und die Ergebnisse der weiteren Checks eingeordnet habe, kann ich entscheiden, ob der Change Teil der Codebasis wird. Mit dem Merge übernehme ich diese Entscheidung.

Ab diesem Moment zieht das Argument nicht mehr, die AI habe den Code geschrieben. Wenn später ein Fehler auftritt, ist die Herkunft keine Entschuldigung. Ich habe den Change akzeptiert und ausgeliefert.

Die Urheberschaft einzelner Zeilen und die Ownership für ein System sind nicht dasselbe. Moderne Software entsteht schon lange mit Frameworks, Bibliotheken, Codegeneratoren, Suchmaschinen, Kolleginnen und Kollegen – und inzwischen eben auch mit AI-Agenten.

Wie der Code geschrieben wurde, ist für die Verantwortung zweitrangig.

Wer ihn prüft, annimmt und herausgibt, muss für ihn einstehen.

Am Ende ist es dein Code.