Code Review für KI-generierten Code: Worauf es ankommt

Warum klassisches Code Review bei KI-generiertem Code nicht ausreicht

Ein klassisches Code Review geht meist davon aus, dass der Autor verstanden hat, was er geschrieben hat, und dass ein Reviewer prüft, ob diese Absicht korrekt umgesetzt wurde. Bei Code, der überwiegend von einem Sprachmodell erzeugt wurde, gilt diese Annahme nicht mehr automatisch: Der Mensch, der den Code eingecheckt hat, kann die einzelnen Zeilen akzeptiert haben, ohne jede Verzweigung im Detail nachvollzogen zu haben. Ein Review, das nur prüft, ob der Code funktioniert und dem Stil entspricht, übersieht deshalb genau die Fragen, die bei generiertem Code am wichtigsten sind.

Was ein klassisches Review typischerweise übersieht

Plausibel wirkender, aber falscher Code

Ein Sprachmodell erzeugt Code, der syntaktisch korrekt ist und sich liest, als wüsste der Autor genau, was er tut – auch dann, wenn die zugrunde liegende Logik an einer Stelle falsch ist. Diese Plausibilität ist tückisch, weil ein Reviewer, der schnell über den Code fliegt, genau an den Stellen keinen Widerspruch spürt, an denen er ihn eigentlich bräuchte.

Erfundene Funktionsaufrufe und Abhängigkeiten

Modelle greifen gelegentlich auf Funktionen, Parameter oder Bibliotheken zurück, die so nicht existieren oder sich anders verhalten als angenommen. Ein Review, das nur die Lesbarkeit prüft, findet solche Fehler oft erst, wenn der Code beim Ausführen tatsächlich bricht – oder gar nicht, wenn der fehlerhafte Pfad selten durchlaufen wird.

Übernommene, aber unpassende Muster

Ein Modell orientiert sich an Mustern aus großen Mengen an Trainingscode. Ein Muster, das in einem anderen Kontext sinnvoll war, kann im eigenen Projekt unpassend oder unsicher sein, etwa bei der Handhabung von Nutzereingaben oder Zugriffsrechten. Diese Übertragung fällt in einem Review nicht auf, wenn nur auf offensichtliche Fehler geachtet wird.

Fehlendes Verständnis beim menschlichen Reviewer

Wer selbst am wenigsten in den Code investiert hat, prüft ihn oft auch am wenigsten kritisch. Ein Reviewer, der weiß, dass der Code von einem Modell stammt, kann verleitet sein, dem generierten Ergebnis mehr Vertrauen entgegenzubringen, als es einem menschlichen Kollegen entgegengebracht würde – ein Effekt, der sich nur durch bewusste Gegensteuerung vermeiden lässt.

Was ein angepasstes Review stattdessen prüft

• Ob die Logik tatsächlich das tut, was sie soll, statt nur, ob sie fehlerfrei durchläuft
• Ob verwendete Funktionen, Parameter und Bibliotheken tatsächlich existieren und das erwartete Verhalten zeigen
• Ob übernommene Muster zum eigenen Sicherheits- und Datenmodell passen
• Ob Randfälle und Fehlerpfade bedacht wurden, nicht nur der Hauptpfad
• Ob der einreichende Mensch den Code im Zweifel erklären kann, statt ihn nur akzeptiert zu haben

Diese Fragen unterscheiden sich von einem klassischen Stil-Review vor allem im Grad des Misstrauens: Wo ein von einem erfahrenen Kollegen geschriebener Code einen Vertrauensvorschuss bekommt, verdient generierter Code eine bewusst kritischere Lesart – unabhängig davon, wie überzeugend er auf den ersten Blick wirkt. Der Beitrag zu Risiken beim Vibe Coding beschreibt, welche Muster dabei besonders häufig auftreten, und die ausführliche Anleitung zum Review generierten Codes liefert eine konkrete Vorgehensweise dafür.

Was das für den Review-Prozess bedeutet

Wer Vibe Coding oder ähnliche KI-gestützte Arbeitsweisen im Team einsetzt, sollte den Review-Prozess entsprechend anpassen, statt die bestehende Checkliste unverändert weiterzuführen. Das bedeutet nicht zwangsläufig mehr Aufwand pro Zeile, sondern gezielteren Aufwand an den Stellen, an denen generierter Code typischerweise seine Schwächen zeigt.