Code Review für KI-Code: sechs Muster, die das klassische Review übersieht

Ein Review von KI-generiertem Code muss nach anderen Dingen suchen als ein klassisches Review. Tippfehler und Flüchtigkeiten produziert eine KI kaum. Sie produziert Code, der plausibel aussieht und an bestimmten Stellen systematisch etwas auslässt: Berechtigungsprüfungen, Fehlerbehandlung, den Abgleich mit bereits vorhandener Logik.

Warum funktioniert das klassische Code Review bei KI-Code schlechter?

Weil es auf eine Fehlerverteilung ausgelegt ist, die es so nicht mehr gibt. Menschlicher Code enthält typischerweise Unaufmerksamkeiten: vertauschte Variablen, vergessene Grenzfälle, unklare Benennungen. Diese Fehler sehen falsch aus, und genau darauf ist ein Reviewer trainiert.

KI-Code sieht richtig aus. Benennungen sind konsistent, die Struktur ist konventionell, Kommentare sind vorhanden. Das Auge findet keinen Haltepunkt. In der Stack Overflow Developer Survey 2025 nannten 66 Prozent der Befragten „fast richtig, aber nicht ganz" als ihre größte Frustration im Umgang mit KI-Werkzeugen — das ist exakt die Beschreibung einer Fehlerklasse, die durch Draufschauen nicht auffällt.

Hinzu kommt das Volumen. Ein Review über 800 generierte Zeilen bekommt nicht die Aufmerksamkeit von 80 handgeschriebenen. Ab einer gewissen Größe wird jedes Review zur Stichprobe, ohne dass jemand das entscheidet.

Worauf muss ich bei einem Review von KI-Code besonders achten?

Auf sechs Muster, die in generiertem Code überdurchschnittlich häufig auftreten.

• Fehlende Berechtigungsprüfung. Die Fachlogik stimmt, die Frage „darf dieser Nutzer das?" wurde nie gestellt. Fehlerhafte Zugriffskontrolle steht in den OWASP Top 10:2025 unverändert auf Platz eins.
• Verschluckte Fehler. Ein leerer Catch-Block, ein ignorierter Rückgabewert, ein Standardwert, der einen Fehlschlag als Erfolg tarnt. Seit 2025 eigene OWASP-Kategorie (A10).
• Neu erfundene Logik neben vorhandener. Das Modell kennt Ihre Hilfsfunktion nicht und schreibt eine zweite. Beide funktionieren, beide müssen künftig gepflegt werden.
• Unbemerkte neue Abhängigkeiten. Prüfen Sie die Paketdateien im Diff genauso aufmerksam wie den Quelltext.
• Tests, die den Code bestätigen statt ihn zu prüfen. Aus dem Ist-Verhalten abgeleitete Zusicherungen zementieren vorhandene Fehler — siehe Testabdeckung bei KI-Code.
• Zu breite Änderungen. Wenn nebenbei Dateien angefasst wurden, die zur Aufgabe nicht gehören, ist das kein Aufräumen, sondern ein ungeprüfter Nebeneffekt.

Wie sollte ein Review von KI-Code ablaufen?

In vier Schritten, wobei die ersten beiden maschinell laufen und der Mensch erst im dritten anfängt.

• Schritt 1 — Maschine räumt das Offensichtliche weg. Formatierung, statische Analyse, Sicherheitsregeln, Abhängigkeits- und Lizenzprüfung, Testlauf. Alles, was ein Werkzeug entscheiden kann, darf keinen Menschen kosten.
• Schritt 2 — Umfang prüfen. Passt der Diff zur Aufgabe? Zu breite Änderungen gehen zurück, bevor jemand sie liest. Diese Regel spart mehr Reviewzeit als jede andere.
• Schritt 3 — Mensch prüft die Absicht. Löst die Änderung das gestellte Problem? Passt sie zur Architektur? Existiert das schon woanders? Sind Berechtigungen und Fehlerfälle bedacht?
• Schritt 4 — Nachweis statt Zusage. Zur Freigabe gehört die Ausgabe des Testlaufs, nicht die Aussage, dass er lief.

Kann eine KI das Code Review übernehmen?

Als erste Instanz ja, als letzte nein — und zwar aus einem strukturellen Grund.

KI-gestützte Reviewer sind gut in dem, was sich am Code selbst erkennen lässt: Muster, Inkonsistenzen, offensichtliche Sicherheitsprobleme, fehlende Fehlerbehandlung. Sie sind unzuverlässig bei der einzigen Frage, die wirklich zählt: Ist das das richtige Verhalten? Diese Frage lässt sich nicht aus dem Code beantworten, sondern nur aus dem Wissen, wofür die Software da ist.

Dazu kommt ein Zirkelschluss, der leicht übersehen wird: Wenn dasselbe Modell erst schreibt und dann prüft, teilt es beide Male dieselben blinden Flecken. Ein zweites Modell hilft ein Stück, ersetzt aber die Person nicht, die das Fachproblem kennt.

Wie viel Zeit sollte ein Review kosten?

Weniger als heute, wenn Schritt 1 und 2 wirklich maschinell laufen. In der Stack Overflow Developer Survey 2025 gaben 45 Prozent der Befragten an, erhebliche Zeit mit dem Debuggen von KI-Code zu verlieren. Ein Teil davon ist Reviewzeit, die an der falschen Stelle ausgegeben wurde: Menschen prüfen Formatierung und Stil, während die Berechtigungslücke durchrutscht.

Die belastbare Faustregel lautet: Was ein Werkzeug entscheiden kann, entscheidet kein Mensch. Was nur ein Mensch entscheiden kann, entscheidet kein Werkzeug. Alles andere ist Verschwendung an der einen und Risiko an der anderen Stelle.

Häufige Fragen zum Code Review

Muss ich offenlegen, dass Code mit KI entstanden ist?

Eine allgemeine gesetzliche Pflicht dazu besteht nach heutigem Stand nicht. Für das Review ist die Information trotzdem nützlich: Sie steuert, wonach gesucht wird. Viele Teams lösen das über eine Kennzeichnung im Pull Request statt über eine Regel.

Wie gehe ich mit sehr großen generierten Änderungen um?

Zurückgeben und aufteilen lassen. Ein Diff, der zu groß zum Lesen ist, wird nicht sorgfältiger geprüft, weil er dringend ist — er wird nur oberflächlicher geprüft, ohne dass es jemand ausspricht.

Reicht ein Review durch eine Person?

Für die meisten Änderungen ja. Für Authentifizierung, Bezahlung, Schema-Änderungen und Deployment ist ein zweites Paar Augen die günstigere Versicherung.

Was, wenn niemand im Team den generierten Code versteht?

Dann ist das der Befund, nicht ein Hindernis für den Befund. Code, den niemand versteht, ist unabhängig von seiner Korrektheit nicht wartbar und sollte nicht zusammengeführt werden.

Ein Mensch, der Formatierung prüft, ist ein teuer eingekaufter Linter. Code Guardian zieht die maschinellen Prüfungen nach vorne — ein Audit direkt nach der Änderung, entlang fester Ebenen wie Logik, Redundanz und Sicherheit — damit im Review die Fragen übrig bleiben, für die man tatsächlich einen Menschen braucht.

Quellen

• Stack Overflow Developer Survey 2025, Abschnitt „AI" (66 Prozent „almost right", 45 Prozent Debugging-Zeitverlust).
• OWASP Top 10:2025, Kategorien A01 und A10.

Stand: 27. Juli 2026. Allgemeine fachliche Einordnung, keine Rechtsberatung.