KI-generierten Code reviewen: die 12-Punkte-Checkliste

Es gibt zwei Arten, einen Agenten-Diff zu reviewen. Die eine liest ihn. Die andere verhört ihn. Nur die zweite skaliert — das habe ich hier begründet und seither in jedem Projekt bestätigt bekommen. Was in diesem Post fehlt, ist die Version für den Moment, in dem der Diff vor dir liegt, das Standup in fünf Minuten beginnt und niemand Zeit für Philosophie hat.

Das hier ist diese Version. Zwölf Punkte, feste Reihenfolge, je eine Frage, die du dem Agenten direkt stellst. Wer die Reihenfolge einhält, ist nach fünf Minuten durch — oder hat einen Grund, den Diff zurückzugeben.

Warum eine Liste und kein Bauchgefühl

Bauchgefühl funktioniert bei menschlichem Code, weil menschlicher Code menschliche Fehler hat: ein vergessener Fall, eine Abkürzung unter Zeitdruck, ein Kommentar, der lügt. Man kennt die Muster.

KI-Code hat andere Muster. Er ist konventionskonform, gut benannt, vollständig kommentiert — und trotzdem falsch, an Stellen, an denen ein Mensch nicht falsch läge. Ein Agent erfindet keine Syntaxfehler. Er erfindet eine Abhängigkeit, die es nicht gibt, oder behandelt den Fehlerfall, indem er ihn verschluckt. Das sieht in einem Diff nicht nach Fehler aus. Es sieht nach Sorgfalt aus.

Das ist nicht nur mein Eindruck. Die Zahlen aus dem letzten Jahr zeigen in dieselbe Richtung:

Die letzte Zeile ist die wichtigste für dieses Thema: Das Gefühl, ein Diff sei in Ordnung, ist genau das Messinstrument, das bei KI-Code versagt. Gegen das Muster „sieht sorgfältig aus" hilft nur ein Verfahren, das die Optik ignoriert. Also: Liste.

Die 12 Punkte

Für jeden Punkt: Was du prüfst, und die Frage, die du dem Agenten in den Chat schreibst. Die Antworten kommen in Sekunden; deine Arbeit ist, sie zu prüfen, nicht zu produzieren.

1. Scope: Tut der Diff, was der Auftrag sagt — und nichts sonst?

Agenten lieben Drive-by-Refactorings. Ein Ticket „Export-Endpoint bauen" kommt zurück mit dem Endpoint, einem umbenannten Date-Helper und drei „aufgeräumten" Imports in Dateien, die niemand angefasst haben wollte. Jede dieser Änderungen ist ein eigenes Risiko ohne eigenes Review.

„Liste jede Datei im Diff auf und sag in einem Satz, warum das Ticket diese Änderung braucht. Alles, was nicht zwingend ist, kommt in einen separaten Diff."

2. Stille Annahmen: Welche Eingaben gelten als garantiert?

Der interessante Bug wohnt nicht im Code, sondern in dem, was der Code voraussetzt. null, leer, riesig, ungültig, doppelt — der Agent hat für jeden dieser Fälle eine Annahme getroffen und keine davon aufgeschrieben.

„Liste alle Annahmen über Eingaben und Zustand auf, die dieser Code trifft, und markiere die riskanteste. Was passiert bei null, leer, 10'000 Einträgen und ungültigem Format?"

3. Fehlerpfade: Was passiert, wenn der Aufruf scheitert?

Das häufigste Muster, das ich in Agenten-Code sehe: try um alles, catch mit Log-Zeile, Rückgabe eines leeren Defaults. Es fliegt nichts, es bricht nichts, und der Anwender bekommt eine leere Liste statt einer Fehlermeldung. Der Bug ist unsichtbar, bis jemand fragt, wo die Daten sind. CodeRabbit fand Lücken in Fehlerbehandlung und Exception-Pfaden in KI-PRs fast doppelt so oft wie in menschlichen.

„Zeig mir jeden catch-Block und jeden Default-Wert bei Fehlern. Für jeden: Wer erfährt vom Fehler, und wie?"

4. Tests: Beweist der Test das Verhalten — oder nur, dass es läuft?

Ein Test, der den Happy Path durchläuft und assertTrue(true) am Ende hat, ist Dokumentation, kein Beweis. Und ein Test, den derselbe Agent im selben Durchlauf geschrieben hat, prüft die Annahmen aus Punkt 2 gegen sich selbst.

Getrennter Schritt, idealerweise ein zweiter Agent, der nur lesen darf — so baust du ihn: „Schreib Tests, die das geforderte Verhalten beweisen, inklusive Fehlerfälle und Grenzen aus Punkt 2 und 3. Mock die Kernlogik nicht."

5. Duplikate: Gibt es das im Projekt schon?

Der Agent sieht den Ausschnitt, den er geladen hat. Du siehst das Projekt. Die dritte Implementierung von „Betrag formatieren" entsteht nicht aus Faulheit, sondern aus Nichtwissen — und sie divergiert ab dem ersten Bugfix. GitClear hat 211 Millionen geänderte Codezeilen ausgewertet: 2024 wurde erstmals mehr Code kopiert als verschoben, und der Anteil verschobener — also refaktorierter — Zeilen fiel von 25 % (2021) auf unter 10 %.

„Suche im Projekt nach bestehendem Code oder Mustern für diese Logik. Zeig mir die Fundstellen. Nutze sie, statt Neues zu bauen — oder begründe, warum nicht."

6. Schichten und Muster: Passt es ins System — oder nur in die Datei?

Ein Controller, der direkt die Datenbank fragt, weil das im Ausschnitt am kürzesten war. Ein zweites Event-System neben dem, das schon existiert. Ein drittes Muster für etwas, das schon zwei hat. Lokal richtig, systemisch falsch.

„Welche Schicht ändert dieser Diff, und mit welchen Schichten spricht der neue Code direkt? Nenne die Muster, die das Projekt für diese Art Aufgabe schon verwendet."

7. Abhängigkeiten: Existiert jedes neue Paket, wird es gepflegt, darf man es nutzen?

Erfundene Pakete sind seltener geworden, aber nicht verschwunden: Eine Studie auf der USENIX Security 2025 fand bei 16 Code-Modellen im Schnitt 5,2 % erfundene Paketnamen bei kommerziellen und 21,7 % bei Open-Source-Modellen — über 205'000 verschiedene Namen, die es nicht gibt. Angreifer registrieren solche Namen inzwischen gezielt („Slopsquatting"). Veraltete Pakete sind ohnehin häufiger. Und die Lizenzfrage stellt kein Agent von selbst. Jede neue Zeile in composer.json, package.json oder pom.xml ist ein Vertrag, den du gerade unterschreibst.

„Für jede neue Abhängigkeit: Registry-Link, letztes Release-Datum, Lizenz, und warum die Standardbibliothek oder eine bestehende Abhängigkeit nicht reicht."

8. Secrets und Validierung: Nichts hartcodiert, alles an der Grenze geprüft?

Der API-Key „nur zum Testen" im Diff. Der Request-Parameter, der ungeprüft in die Query wandert. Beides sieht in einer Demo nie jemand — und beides sieht in einem Diff harmlos aus, weil es kurz ist. Bei Veracode scheiterten KI-Modelle in 86 % der relevanten Fälle an Cross-Site-Scripting; bei Java lag die Durchfallquote für Sicherheit insgesamt bei 72 %.

„Prüfe diesen Diff auf hartcodierte Secrets, ungeprüfte Eingaben und Stellen, an denen Nutzerdaten in Queries, Shell-Befehle oder Templates gelangen. Nenne Zeilen und je einen Fix."

9. Datenfluss: Wo landen die Daten, wer kann sie lesen, geht die Migration zurück?

Für ein Schweizer Unternehmen keine Nebenfrage: Welche Daten verlassen das System, in welche Region, in welchen Dienst. Und jede Migration, die nur nach vorne geht, ist ein Deploy ohne Rückweg.

„Welche Daten schreibt oder sendet dieser Code wohin? Gibt es einen Aufruf an einen externen Dienst? Hat jede Migration ein funktionierendes down()?"

10. Blast-Radius: Was hängt sonst noch an dem, was hier geändert wird?

Eine geteilte Hilfsfunktion, eine Konfiguration, ein Schema — die Änderung ist zehn Zeilen, die Aufrufer sind vierzig. Der Agent hat die vierzig nicht angeschaut, weil sie nicht im Kontext waren.

„Liste alle Aufrufer der geänderten Funktionen, Konfigurationen und Tabellen auf. Für jeden: Verhält er sich nach dem Diff gleich? Wie sieht ein Rollback aus?"

11. Lesbarkeit in sechs Monaten: Kann ich jede nicht-triviale Zeile erklären?

Nicht „verstehe ich es ungefähr", sondern: Könnte ich es einem Kollegen erklären, ohne den Agenten zu fragen? Der Agent, der es geschrieben hat, erinnert sich in sechs Monaten an nichts. Lesbarkeitsprobleme traten bei CodeRabbit in KI-PRs mehr als dreimal so häufig auf — der grösste Abstand aller Kategorien. Du bist dann die einzige Person, die diesen Code kennt — oder auch nicht.

„Erkläre die drei am wenigsten offensichtlichen Stellen im Diff in je zwei Sätzen. Wenn eine Erklärung länger braucht, ist der Code zu clever — vereinfache ihn."

12. Beobachtbarkeit: Wenn es in Produktion bricht, wie erfahre ich es?

Der Fehler, der kommt, ist nicht der, den du beim Review gesehen hast. Logging mit Kontext, eine Metrik, ein Alarm — das ist der Unterschied zwischen „ein Kunde meldet sich nach drei Tagen" und „wir wussten es nach drei Minuten".

„Welche Log-Zeile oder Metrik zeigt mir, dass dieser Code in Produktion fehlschlägt — bevor ein Kunde es merkt? Ergänze sie, falls sie fehlt."

Durchlauf an einem typischen Diff

Nehmen wir einen Diff, wie er mir jede Woche über den Tisch geht: Ticket „CSV-Export für Rechnungen pro Kunde", Laravel-Projekt, Agent liefert 180 Zeilen in einem Durchlauf. Sieht sauber aus. Die Liste, im Schnelldurchlauf:

• Punkt 1 schlägt an: Neben dem Export-Controller hat der Agent einen Date-Helper umbenannt, der an elf Stellen verwendet wird. Raus damit, eigener Diff.
• Punkt 2 schlägt an: Der Export setzt voraus, dass jede Rechnung einen Kunden hat. Im System gibt es Entwürfe ohne Kunden. Bei denen wirft der Code einen Null-Zugriff — oder, schlimmer, siehe nächster Punkt.
• Punkt 3 schlägt an: Der ganze Export steckt in einem try/catch, das bei jedem Fehler eine leere Datei liefert. Der Anwender hätte eine leere CSV bekommen und den Fehler beim Buchhalter gesucht.
• Punkt 4 schlägt an: Ein Test, der prüft, dass der Endpoint 200 liefert. Kein Test mit null Rechnungen, keiner mit einem Entwurf, keiner mit 10'000 Zeilen.
• Punkt 7 ist sauber: league/csv, gepflegt, MIT, sinnvoll.
• Punkt 10 schlägt an: Der Export lädt alle Rechnungen in den Speicher. Bei den drei grössten Kunden sind das nicht 200 Zeilen, sondern 60'000 — und das Request-Timeout liegt bei 30 Sekunden.
• Die übrigen Punkte sind sauber.

Fünf Treffer, sieben Minuten. Keiner der fünf wäre beim Lesen aufgefallen, weil der Code an jeder dieser Stellen ordentlich aussieht. Der Diff ging mit den fünf Fragen zurück an den Agenten und kam vierzig Minuten später korrekt wieder — Streaming statt Speicher, explizite Fehler, sechs Tests statt einem.

Wie du die Liste einführst

Nicht als Dokument im Wiki. Als Skill oder als Review-Agent, der nur lesen darf und diese zwölf Fragen stellt, bevor ein Mensch den Diff sieht — dann bekommst du die Antworten zum Diff mitgeliefert und prüfst, statt zu sammeln. Wie das in zwanzig Minuten geht, steht im Subagents-Tutorial.

Und für den Fall, dass du gerade eine Codebase übernimmst, in der die Liste nie angewendet wurde: Dann ist nicht Review dein Problem, sondern Triage.

Was du diese Woche tun kannst

Nimm den nächsten Agenten-Diff und fahr die zwölf Punkte einmal in dieser Reihenfolge durch, mit Stoppuhr — nicht nach Gefühl, denn wie die METR-Studie zeigt, lag das Gefühl dort um rund 40 Prozentpunkte daneben. Zähl die Treffer. Wenn es null sind, ist entweder der Diff sehr klein oder du hast Punkt 2 und 3 zu schnell abgehakt. Wenn es drei oder mehr sind, weisst du jetzt, wo bei euch die Tech-Schuld entsteht — und dass sie nicht am Tempo liegt, sondern daran, dass niemand gefragt hat. Die Checkliste als Einseiter hängt bei mir neben der Tastatur; die letzten 20 Prozent waren schon immer der eigentliche Job.

Quellen

• Stack Overflow: Developer Survey 2025 — AI (2025)
• CodeRabbit: State of AI vs. Human Code Generation Report (17.12.2025)
• Veracode: 2025 GenAI Code Security Report (30.07.2025)
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10.07.2025) — 16 Entwickler, 246 Aufgaben; die Autoren warnen ausdrücklich vor Verallgemeinerung.
• GitClear: AI Copilot Code Quality 2025
• Spracklen et al.: We Have a Package for You! Package Hallucinations by Code Generating LLMs, USENIX Security 2025