Von einem KI-Agenten geschriebenen Code überprüfen

Ziel

Eine von einem Sprachmodell-Agenten oder mit dessen starker Mitwirkung geschriebene Änderung so überprüfen, dass die für generierten Code typischen Fehlerarten erkannt werden, während für alles Übrige der gewöhnliche Review-Massstab weiterhin gilt.

Voraussetzungen

Eine Änderungsbeschreibung, die festhält, was verlangt wurde, was der Agent getan hat und was er nicht geprüft hat; eine reviewende Person, die Code und Tests ausführen kann; die übliche Review-Checkliste des Teams.

Schritte

1. Zuerst die Absicht lesen: die Anfrage mit dem abgleichen, was der Diff tatsächlich tut. Ein häufig berichtetes Muster bei generierten Änderungen ist Scope Drift: nicht angeforderte Refactorings, umbenannte Bezeichner oder "Verbesserungen" an benachbartem Code. Verlangen, dass solche Zusätze vor dem Review des Rests abgetrennt werden.
2. Bestätigen, dass jede neue Abhängigkeit, API, jedes Flag und jede Funktion in den verwendeten Versionen tatsächlich existiert: den Import, den Registry-Eintrag oder die Dokumentation öffnen. Plausible, aber nicht existierende APIs sind eine häufig berichtete Fehlerart bei generiertem Code.
3. Testbehauptungen anhand von Belegen prüfen, nicht anhand des Satzes: den CI-Lauf aufsuchen. Die von der Änderung hinzugefügten Tests ausführen und den geprüften Code vorübergehend absichtlich kaputt machen, um zu bestätigen, dass die Tests scheitern können.
4. Die Tests vor der Implementierung lesen. Generierte Tests behaupten oft die aktuelle Ausgabe der Implementierung statt der Anforderung, mocken genau das, was geprüft werden soll, oder sichern die Assertion mit einer Bedingung ab, die nie zutrifft.
5. Nach still behandelten Fehlern suchen: weit gefasste except- oder catch-Blöcke, bei Fehlern zurückgegebene Default-Werte, unbegrenzte Wiederholungsversuche und Protokollierung anstelle von Weiterreichen.
6. Grenzen und sicherheitsrelevante Pfade mit der üblichen Sorgfalt behandeln: Eingabevalidierung, Pfadbehandlung, Aufbau von Shell- und SQL-Befehlen, Geheimnisse in Code oder Logs. Generierter Code liest sich flüssig, was zum Überfliegen verleitet; genau dort langsamer werden, wo er am selbstsichersten wirkt.
7. Prüfen, dass Kommentare und Docstrings den Code so beschreiben, wie er am Ende geworden ist, nicht wie er zuerst entworfen wurde; veraltete Kommentare sind nach iterativer Generierung häufig.
8. Im Review festhalten, welche Teile ausgeführt, genau gelesen oder nur überflogen wurden, damit die nächste lesende Person weiss, wohin die menschliche Aufmerksamkeit ging.

Erwartetes Ergebnis

Für generierten Code typische Mängel (erfundene APIs, tautologische Tests, Scope Creep, versteckte Fehlerbehandlung) werden beim Review erkannt, und der Review-Vermerk zeigt, was eine Person tatsächlich geprüft hat.

Grenzen und Prüfbasis

Dies ist ein vorgeschlagenes Protokoll; es wird kein Vergleich der Fehlerraten zwischen generierten und handgeschriebenen Änderungen behauptet. Die Schritte kosten zusätzliche Review-Zeit, und bei sehr kleinen Änderungen können die Schritte 2 bis 5 bereits genügen. Eine Änderung ohne Angabe, wie sie entstanden ist, sollte so geprüft werden, als wäre sie generiert.

Automatisieren vor dem Lesen

Die mechanischen Prüfungen ausführen, bevor eine Person die Änderung liest, und die Ergebnisse von der Autorenseite beifügen lassen. Ein Build mit dem Typprüfer oder Import-Resolver klärt, ob jede API und Abhängigkeit tatsächlich existiert (Schritt 2). Ein auf den Diff begrenzter Mutation-Testing-Lauf klärt, ob die neuen Tests scheitern können (Schritt 3), und ein fehlschlagender Testlauf von vor der Korrektur ist ein akzeptabler Beleg, wenn kein Mutation-Testing-Werkzeug verfügbar ist. Ein Linter, der leere oder blinde except- und catch-Blöcke markiert, deckt die offensichtliche Hälfte von Schritt 5 ab. Die Zeit der reviewenden Person geht dann in die Fragen, die Werkzeuge nicht beantworten können: ob der Diff der Anfrage entspricht, ob die Tests die Anforderung statt der Implementierung prüfen und ob die Grenzen behandelt sind.