Das Review von KI-generiertem Code folgt denselben Grundsätzen wie das Review von beliebigem Code, doch bestimmte Fehlerarten treten häufiger auf und erfordern gezielte Aufmerksamkeit. Selbstsicher wirkende, plausible Fehler sind häufiger; die Aufgabe des Reviewers besteht darin, dort zu verlangsamen, wo menschliche Reviewer instinktiv schneller werden.
Warum KI-generierter Code leichter zu genehmigen wirkt
KI-generierter Code ist in der Regel gut formatiert, konsistent benannt und mit Inline-Kommentaren versehen. Diese äußerliche Qualität kann die Aufmerksamkeit des Reviewers verringern. Der Code wirkt, als hätte ihn jemand Kompetentes geschrieben, was Druck erzeugt, schnell zu genehmigen. Diesem Druck als Erstes zu widerstehen ist entscheidend.
Das eigentliche Problem besteht darin, dass ein Sprachmodell auf Plausibilität optimiert, nicht auf Korrektheit. Es hat kein Interesse am Ergebnis. Es kann den Code vor dem Vorschlagen nicht ausführen und weiß nicht, was letzte Woche Dienstag in Ihrer Codebasis geändert wurde.
Was sich beim Review ändert
Weniger Annahmen über die Absicht treffen. Wenn ein Kollege eine Funktion schreibt, können Sie ihn fragen, warum er eine bestimmte Entscheidung getroffen hat. KI-generierter Code hat keinen Autor, den man befragen könnte. Ist die Absicht nicht aus dem Code und seinem Kontext ersichtlich, ist das eine Lücke, die vor der Genehmigung zu schließen ist, nicht danach.
Prüfen Sie die Nahtstellen. KI-Tools arbeiten mit einem Kontextfenster. Sie sehen nur das, was ihnen übergeben wurde, nichts weiter. Fehler häufen sich an den Übergängen: dort, wo der generierte Code auf den Rest des Systems trifft, wo Typen angenommen statt importiert werden, wo ein API-Aufruf den Trainingsdaten des Modells entspricht, nicht aber der Version, die tatsächlich im Einsatz ist. Weitere Informationen zu dieser Einschränkung finden Sie unter Was ist ein Kontextfenster.
Betrachten Sie Tests mit besonderer Skepsis. Modelle generieren Tests, die gegen den soeben geschriebenen Code bestehen. Das ist nicht dasselbe wie Tests, die eine Regression erkennen würden. Prüfen Sie, ob die Tests das Verhalten abdecken, das Ihnen wichtig ist, oder ob sie lediglich bestätigen, dass die Funktion irgendetwas zurückgibt.
Achten Sie auf halluzinierte Abhängigkeiten. Modelle referenzieren mitunter Bibliotheken, Methoden oder Konfigurationsschlüssel, die nicht existieren oder in einer anderen Version vorliegen als der von Ihnen verwendeten. Eine kurze Prüfung von Imports und Abhängigkeitsversionen ist aufwandsarm. Das Problem erst in der Produktion zu entdecken, ist es nicht.
Lesen Sie die Fehlerbehandlung sorgfältig. KI-generierte Fehlerbehandlung ist häufig generisch: stille Catches, nackte except-Blöcke, Fehler, die in einer Logzeile verschwinden, die niemand überwacht. Diese bestehen eine oberflächliche Prüfung, weil sie wie Fehlerbehandlung aussehen. Lesen Sie jeden Fall und fragen Sie sich, was tatsächlich passiert, wenn dieser Pfad durchlaufen wird.
Was sich nicht ändert
Die Standard-Review-Checkliste gilt weiterhin: Korrektheit, Sicherheit, Performance, Lesbarkeit, Testabdeckung, Passung zur bestehenden Architektur. KI-Generierung macht diese Aspekte nicht weniger relevant. Sie verändert, wo sich Fehler typischerweise verbergen, nicht ob sie existieren.
Das Sicherheits-Review sollte insbesondere nicht abgekürzt werden. Prompt Injection ist eine Risikokategorie, die spezifisch für KI-gestützte Systeme ist, doch der breitere Katalog an Bedenken, Injection, unsichere Standardkonfigurationen, fehlerhafte Zugriffskontrollen, gilt für KI-generierten Code ebenso wie für jeden anderen.
Praktische Gewohnheiten
- Lesen Sie den Diff als Code, nicht als Zusammenfassung. Widerstehen Sie dem Drang zu überfliegen, nur weil er ordentlich aussieht.
- Ist ein Block lang, unterteilen Sie das Review in Durchgänge: einen für die Logik, einen für die Fehlerbehandlung, einen für die Tests.
- Wenn etwas cleverer wirkt als nötig, lohnt sich ein zweiter Blick. Modelle produzieren manchmal überkomplizierte Lösungen.
- Dokumentieren Sie, wo KI-generierter Code zu Problemen geführt hat. Muster zeigen sich schnell und helfen dabei, beim nächsten Mal gezielter zu prüfen.
Einen umfassenderen Überblick darüber, wie sich Code-Review-Praktiken verändern, bietet Was hat sich am Code Review geändert.
Was wir prüfen
Die Prüfung von AI-generiertem Code gehört zu den Fähigkeiten, die wir im Auswahlverfahren direkt bewerten. Im AI-native Assessment wird die Prüfung von AI-Output gesondert bewertet: Erkennt der Engineer erfundene APIs, subtil falsche Logik oder Sicherheitslücken im generierten Code, bevor er live geht? Dass der Code kompiliert, genügt dafür nicht als Maßstab. Die Risikoeinschätzung fließt in beide Assessments ein, denn Agenten liefern eine Textänderung und eine Zahlungsmigration gleich schnell und mit gleicher Sicherheit. Wie beide Assessments ablaufen, steht unter So prüfen wir.
Kurze Antworten
Unterscheidet sich das Review von KI-generiertem Code grundlegend vom Review von menschlich geschriebenem Code?
Die Grundsätze sind dieselben, doch die Fehlerbilder verlagern sich. KI-generierter Code wirkt oft sauberer als er ist, Fehler konzentrieren sich an Kontextgrenzen, und Tests bestätigen häufig nur das, was das Modell gerade geschrieben hat, anstatt künftige Regressionen abzufangen.
Sollte KI-generierter Code in einem Pull Request als solcher gekennzeichnet werden?
Viele Teams empfinden dies als sinnvoll, da es Reviewer dazu veranlasst, die spezifisch relevanten Prüfungen anzuwenden. Es hilft auch dabei, nachzuverfolgen, wo Probleme ihren Ursprung haben. Einen allgemeinen Standard gibt es noch nicht, aber Transparenz verbessert die Review-Qualität in der Regel.
Wie prüft man KI-generierte Tests wirksam?
Prüfen Sie, ob jeder Test das Verhalten abdeckt, das die Codebasis tatsächlich schützen soll, nicht nur ob er besteht. Modelle schreiben Tests, die ihre eigene Ausgabe bestätigen. Fragen Sie, welche Regression der Test erkennen würde, nicht nur ob er derzeit besteht.
