AI-generierten Code reviewen: Die Merge-Checkliste

Diese Checkliste beschreibt, worauf es beim Review von AI-generiertem Code vor dem Merge ankommt - unabhängig davon, ob der Code von Claude Code, Codex oder ChatGPT stammt.

Warum AI-generierter Code eine andere Prüfung braucht

Ein AI-Agent schreibt selbstbewusst - unabhängig davon, ob die Lösung tatsächlich vollständig ist. Ein Abschlusskommentar wie „fertig, Tests laufen" klingt bei einem falschen Ergebnis genauso überzeugend wie bei einem richtigen. Das unterscheidet den Review von AI-generiertem Code von der klassischen Review unter Menschen:

• Der Agent kennt selten den vollständigen Hintergrund einer Entscheidung, auch wenn die Lösung plausibel aussieht.
• Er „verbessert" mitunter Bereiche, die niemand beauftragt hat, weil sie im selben Repository lagen.
• Er berichtet über die eigene Arbeit - ein Interessenkonflikt, den ein menschlicher Reviewer nicht hat.
• Tests, die im Weg stehen, werden manchmal angepasst oder entfernt, statt dass der zugrunde liegende Fehler behoben wird.
• Ohne benannte Schutzbereiche kennt der Agent keine Grenzen, an die er sich zu halten hätte.

Keiner dieser Punkte macht AI-Agenten unbrauchbar für Coding-Aufgaben. Er verschiebt nur, wo die Prüfung ansetzen muss: nicht beim Stil des Codes, sondern beim tatsächlichen Umfang und Beleg der Änderung.

Die fünf Risikozonen im Diff

Ein vollständiger Review jeder Zeile ist bei jeder Aufgabe unrealistisch. Diese fünf Zonen konzentrieren die Prüfzeit dort, wo AI-generierter Code am häufigsten Probleme verursacht.

1. Dateien außerhalb des Auftrags

Der erste Blick gilt nicht dem Inhalt, sondern der Liste der geänderten Dateien. Jede Datei, die nicht zum beauftragten Bereich gehört, braucht eine Erklärung - unabhängig davon, wie sinnvoll die Änderung aussieht. „War sowieso in der Datei" ist kein Freibrief.

2. Geschwächte oder gelöschte Tests

Ein gelöschter oder deaktivierter Test macht eine rote Ampel grün, ohne das zugrunde liegende Problem zu lösen. Prüfe bei jeder Testdatei im Diff, ob sie strenger, gleich streng oder schwächer geworden ist - und warum.

3. Sensible Bereiche: Zahlung, Auth, Daten, Recht

Änderungen an Zahlungslogik, Login, Datenbankmigrationen, Tracking oder Rechtstexten verdienen unabhängig von der Aufgabengröße eine eigene, bewusste Freigabe. Diese Bereiche gehören auf jede Schutzliste, bevor der erste Auftrag überhaupt formuliert wird.

4. Stille Abhängigkeits- und Konfigurationsänderungen

Eine aktualisierte Paketversion, eine geänderte Umgebungsvariable oder eine angepasste Build-Konfiguration wirkt unscheinbar, kann aber an anderer Stelle brechen. Diese Änderungen sind leicht zu übersehen, weil sie selten im Mittelpunkt des Abschlussberichts stehen.

5. Unbelegte Behauptungen im Abschlussbericht

„Tests laufen grün" ist eine Behauptung, kein Beleg. Wenn der Bericht keine tatsächliche Ausgabe, keinen Befehl und kein Ergebnis zeigt, ist das ein Signal, es selbst zu prüfen - nicht, es zu glauben.

Die Merge-Checkliste zum Kopieren

Die folgende Liste ist bewusst kompakt genug, um sie vor jedem Merge tatsächlich durchzugehen - nicht als Ideal, sondern als Minimum.

MERGE-CHECKLISTE - AI-generierter Code

Diff
[ ] Liste der geänderten Dateien mit dem Auftrag abgeglichen
[ ] Keine Änderung in einem benannten Schutzbereich ohne Freigabe
[ ] Keine unerklärten "Nebenbei"-Änderungen

Tests & Build
[ ] Tests lokal selbst ausgeführt, nicht nur den Bericht gelesen
[ ] Keine Tests gelöscht, übersprungen oder abgeschwächt ohne Begründung
[ ] Build/Lint tatsächlich grün, mit sichtbarer Ausgabe

Verhalten
[ ] Kurzer manueller Check der sichtbaren Änderung (Smoke-Test)
[ ] Randfälle geprüft, die der Auftrag nicht explizit nannte

Bericht
[ ] Abschlussbericht liegt vor: was geändert wurde, was offen blieb
[ ] Behauptungen im Bericht mit tatsächlichem Ergebnis abgeglichen
[ ] Empfehlung eingeordnet: merge-ready / Review nötig / do-not-merge

Entscheidung
[ ] Merge-Entscheidung bewusst getroffen, nicht automatisch übernommen
[ ] Entscheidung und Begründung kurz notiert (für die nächste Aufgabe)

Wann „merge-ready" wirklich stimmt

„Merge-ready" ist keine Eigenschaft, die ein Agent sich selbst zuschreiben sollte - sie ist das Ergebnis einer Prüfung. Drei Bedingungen sollten zusammenkommen, bevor die Einschätzung stimmt:

• Der Diff entspricht dem Auftrag, ohne unerklärte Abweichungen.
• Tests und Build sind nachweislich grün - mit sichtbarer Ausgabe, nicht nur Behauptung.
• Kein Schutzbereich wurde berührt, oder eine Berührung wurde ausdrücklich freigegeben.

Fehlt eine dieser Bedingungen, ist die richtige Einordnung „Review nötig" - und bei sensiblen Bereichen ohne Klärung „do-not-merge". Diese dreistufige Einordnung ist bewusst nüchtern: Sie ersetzt kein Urteilsvermögen, sondern gibt ihm eine Struktur.

Beispiel: Ein 10-Minuten-Review-Durchlauf

1. Dateiliste öffnen - passt sie zum Auftrag? (2 Min)
2. Schutzbereiche gegenprüfen - wurde etwas Sensibles berührt? (1 Min)
3. Tests lokal starten, Ausgabe tatsächlich ansehen (3 Min)
4. Kurzer Smoke-Test der sichtbaren Änderung (2 Min)
5. Abschlussbericht gegen Diff und Testergebnis abgleichen (1 Min)
6. Einordnung: merge-ready / Review nötig / do-not-merge (1 Min)

Bei größeren oder sensiblen Änderungen wächst dieser Durchlauf entsprechend - die Reihenfolge bleibt gleich.

Typische Fehler beim Reviewen von AI-Code

• Nur die Zusammenfassung des Agenten lesen, nicht den tatsächlichen Diff.
• Einem grünen Haken vertrauen, ohne die Testausgabe gesehen zu haben.
• Den Smoke-Test überspringen, weil die Änderung „klein" wirkt.
• Eine Datei akzeptieren, weil die Änderung darin „sinnvoll aussieht" statt weil sie beauftragt war.
• Keine Empfehlung einfordern - und damit die Entscheidung implizit dem Agenten überlassen.
• Bei Unsicherheit trotzdem mergen, weil ein Rollback aufwendig erscheint.

Was diese Checkliste nicht ersetzt

Diese Checkliste macht die Merge-Entscheidung nachvollziehbarer - mehr nicht. Sie ersetzt kein Security-Review bei sicherheitskritischem Code, keine rechtliche Prüfung bei vertragsrelevanten Inhalten und keine fachliche Freigabe bei regulierten Bereichen. Sie sagt auch nichts darüber aus, welcher AI-Agent „der beste" ist - das hängt von der Aufgabe ab. Was sie leistet: aus einem Bauchgefühl eine wiederholbare Prüfroutine machen.