Code-Review erfordert heute eine andere Haltung. Als der größte Teil des Codes in einem Pull Request noch von der Person stammte, die ihn eingereicht hat, bestand die Aufgabe der Reviewenden darin, Fehler zu finden und Wissen zu teilen. Wenn ein erheblicher Teil des Codes von einem Modell generiert wurde, müssen Reviewende außerdem prüfen, ob die Autorin oder der Autor tatsächlich versteht, was sie oder er da mergt.
Warum sich die Art des Problems verändert hat
KI-Modelle erzeugen Code, der syntaktisch sauber, gut formatiert und auf den ersten Blick oft plausibel wirkt. Die Oberfläche sieht fertig aus. Fehler, wenn sie vorhanden sind, stecken eher in der Logik, in Randfällen oder in Integrations-Annahmen als in offensichtlichen Syntaxfehlern. Das bedeutet: Die visuellen Signale, auf die Reviewende früher vertrauten, unordentliche Formatierung, ungewöhnliche Muster, offensichtliches Copy-Paste, sind weniger aussagekräftig. Etwas kann korrekt aussehen und trotzdem in wichtigen Punkten falsch sein.
Es gibt auch ein Mengenproblem. Engineers, die KI-Werkzeuge einsetzen, können schneller mehr Code produzieren. Pull Requests werden größer und kommen häufiger. 800 Zeilen Code zu reviewen, die eine Person über zwei Tage geschrieben hat, ist etwas anderes als 800 Zeilen zu reviewen, die ein Modell in zwanzig Minuten erzeugt hat, denn im zweiten Fall gibt es weniger Gewissheit, dass die Autorin oder der Autor den gesamten Code nachvollzogen hat.
Worauf Reviewende jetzt achten
Die praktische Veränderung besteht darin, dass Reviewende zunehmend das Verständnis der Autorin oder des Autors prüfen, nicht nur die Korrektheit des Codes. Nützliche Fragen während des Reviews sind heute:
- Kann die Autorin oder der Autor einen bestimmten Codeblock auf Nachfrage erklären?
- Spiegelt die Testabdeckung ein Verständnis der Grenzfälle wider, oder werden nur die Standardfälle abgedeckt?
- Gibt es Muster, die offenbar unverändert vom Modell übernommen wurden?
- Ist die Fehlerbehandlung für dieses System sinnvoll, oder handelt es sich um generischen Boilerplate-Code?
Dies ist keine Aussage, dass KI-generierter Code im Durchschnitt schlechter ist. Es ist die Aussage, dass das Risikoprofil anders ist und dass Review-Prozesse, die für von Menschen geschriebenen Code entwickelt wurden, die Fehlerbilder von modellgeneriertem Code nicht automatisch erkennen.
Weitere Hinweise dazu, worauf Sie bei Code achten sollten, den Sie nicht selbst geschrieben haben, finden Sie unter KI-generierten Code reviewen und Software testen, die Sie nicht entworfen haben.
Technische Schulden entstehen auf andere Weise
Bei menschlich geschriebenem Code baut sich technische Schuld in der Regel schrittweise auf. Unter Zeitdruck werden Abkürzungen genommen; die Person, die sie genommen hat, weiß im Allgemeinen, wo die Probleme stecken. Bei KI-generiertem Code, der ohne vollständiges Verständnis akzeptiert wurde, kann die Schuld strukturell einwandfrei wirken, während die zugrunde liegenden Annahmen falsch sind. Eine spätere Überarbeitung ist schwieriger, weil niemand im Team ein klares Bild davon hat, warum er so geschrieben wurde.
Das gilt besonders für Codebasen, in denen mehrere Engineers unabhängig voneinander KI-Tools nutzen und Code mergen, den die anderen nicht genau gelesen haben. In der Summe kann eine Codebasis entstehen, die sich schwer durchdringen lässt: Keine einzelne Datei muss schlecht sein, und trotzdem hat nie jemand ein stimmiges mentales Modell davon aufgebaut, wie alles zusammenpasst.
Was sich nicht verändert hat
Das Ziel des Reviews ist nach wie vor dasselbe: ein gemeinsames Verständnis davon, was sich in Produktion befindet, und die Gewissheit, dass es sich korrekt verhält. Die Mittel, um dieses Ziel zu erreichen, haben sich verschoben. Autoren zu bitten, die Logik mündlich durchzugehen, Erklärungen für nicht offensichtliche Designentscheidungen zu verlangen und auf die Testqualität bewusster zu achten, all das waren bereits vorher gute Praktiken und sind jetzt noch wichtiger.
Einige Teams haben darauf reagiert, indem sie auch auf der Review-Seite KI-Werkzeuge einsetzen und Modelle nutzen, um potenzielle Probleme vor dem menschlichen Review zu kennzeichnen. Das kann Rauschen reduzieren, beseitigt aber nicht die Notwendigkeit eines menschlichen Reviewers, der das System versteht.
Was wir prüfen
Beide Sitzungen unter how we vet sind hierfür unmittelbar relevant. Sitzung 1 stellt fest, ob ein Engineer ohne Unterstützung echte Probleme finden kann – durch strukturiertes Debugging und echtes technisches Verständnis des Stacks. Sitzung 2 prüft dieselben Instinkte unter anderen Bedingungen: ob sie halluzinierte APIs oder subtil fehlerhafte Logik in generiertem Output erkennen, bevor er ausgeliefert wird, und ob sie eine Änderung erklären können, die sie nicht selbst getippt haben. Engineers, die die Verifizierung von KI-Output als optional betrachten, machen aus dem Review eine Formalität statt etwas Nützliches.
Kurze Antworten
Ist KI-generierter Code schwieriger zu reviewen als menschlich geschriebener Code?
Er ist anders zu reviewen, nicht notwendigerweise aufwändiger im Umfang. Die Oberfläche ist oft sauber, was Logikfehler oder falsche Annahmen verschleiern kann. Die größte Herausforderung besteht darin, dass Reviewer nicht mehr davon ausgehen können, dass der Autor jede eingereichte Zeile vollständig versteht.
Bedeutet schnellere Code-Generierung mehr technische Schuld?
Das kann so sein, wenn die Review-Praktiken nicht Schritt halten. Wenn Code generiert und akzeptiert wird, ohne dass der Autor ihn nachvollzogen hat, häuft das Team Annahmen an, die niemand überprüft hat. Das erzeugt Schulden, die schwieriger zu finden und zu beheben sind als jene, die bewusst unter Zeitdruck aufgebaut wurden.
Sollten Teams KI-Werkzeuge in den Review-Prozess selbst integrieren?
Das kann bei oberflächlichen Prüfungen helfen, ersetzt aber keinen Reviewer, der das System versteht. Automatisiertes Review erkennt einige Probleme; es überprüft nicht, ob der Autor verstanden hat, was er gemergt hat, oder ob das Design zur übergeordneten Codebasis passt.
