Der Entwickler-Leitfaden zur Prüfung von KI-generiertem Code

Code-Review drehte sich schon immer darum, Fehler zu fangen, bevor sie in die Produktion gelangen. Aber wenn der Code von einem KI-Assistenten statt von einem menschlichen Kollegen geschrieben wurde, ändern sich die Dynamiken des Reviews grundlegend. Die Fehler, die die KI macht, unterscheiden sich von denen, die ein Mensch macht, und die Dinge, die du überprüfen musst, sind nicht dieselben, die du in einem Peer-Review prüfen würdest.

Dieser Leitfaden behandelt, was erfahrene Teams über das Prüfen von KI-generiertem Code gelernt haben. Er ist nach den Kategorien von Problemen geordnet, die KI-Modelle konsistent produzieren, damit du eine systematische Checkliste durchgehen kannst, anstatt dich auf eine Intuition zu verlassen, die für menschlich geschriebenen Code entwickelt wurde.

Warum KI-generierter Code andere Review-Kriterien braucht

Menschliche Entwickler machen Fehler, die sich um Müdigkeit, Ablenkung und Wissenslücken gruppieren – ein müder Entwickler übersieht einen Grenzfall, ein abgelenkter vergisst, einen Fehler zu behandeln, ein Juniormitarbeiter verwendet ein Anti-Pattern, weil er es nicht besser weiß. KI-Modelle machen Fehler, die sich um völlig andere Achsen gruppieren: Halluzination, Kontextblindheit und stilistische Inkonsistenz.

Ein Mensch, der eine Funktion schreibt, die keine Null-Eingaben behandelt, weiß es wahrscheinlich besser und hat es nur vergessen. Eine KI, die dieselbe Funktion schreibt, weiß wirklich nicht, ob Null in deiner Codebasis möglich ist, es sei denn, du hast es ihr explizit gesagt. Diese Unterscheidung ist wichtig, weil die Lösung unterschiedlich ist: Ein Mensch braucht eine Erinnerung, aber die KI braucht eine Einschränkung, die im Prompt kodiert oder im Review abgefangen wird.

Diesen Unterschied zu verstehen, ist die Grundlage eines effektiven KI-Code-Reviews. Du prüfst nicht, ob der Entwickler sorgfältig war. Du prüfst, ob die KI genug Kontext hatte, um korrekten Code zu produzieren, und ob ihre Ausgabe mit den impliziten Konventionen deiner Codebasis übereinstimmt, die sie nicht sehen konnte.

Checklisten-Punkt 1: Halluzinierte APIs und Importe

Das mit Abstand häufigste Problem in KI-generiertem Code ist die Verwendung von Bibliotheken, Funktionen oder APIs, die nicht existieren. KI-Modelle sind darauf trainiert, plausiblen Code zu produzieren, und sie generieren selbstbewusst Importe für Pakete, die nie veröffentlicht wurden, und rufen Methoden auf, die nie existiert haben. Das ist nicht böswillig – es ist das Modell, das zwischen realen Paketen, die es während des Trainings gesehen hat, interpoliert und eine Brücke erfindet, die vernünftig aussieht.

// KI-generierter Code, der plausibel aussieht, aber eine nicht existierende Funktion importiert
import { renderAsync } from 'react-dom'; // renderAsync existiert nicht
import { optimize } from 'lodash/fp/string'; // Dieser Pfad existiert in lodash nicht

// Was du tatsächlich brauchst
import { renderToString } from 'react-dom/server';

Die Lösung dafür ist einfach, aber wichtig: Überprüfe jeden Import und jeden API-Aufruf anhand der tatsächlichen Dokumentation. Geh nicht davon aus, dass die APIs korrekt sind, nur weil der Code kompiliert – einige halluzinierte Funktionen haben vernünftig aussehende Signaturen, die die TypeScript-Prüfung bestehen, aber zur Laufzeit fehlschlagen. Das Review sollte eine kurze Plausibilitätsprüfung für jeden Import beinhalten, den du nicht erkennst.

Checklisten-Punkt 2: Fehlende Fehlerbehandlung

KI-Modelle neigen dazu, den Happy Path zu generieren. Sie sind bemerkenswert gut darin, die Hauptlogik einer Funktion zu schreiben – die Schleife, die Transformation, den Rückgabewert – und bemerkenswert schlecht darin zu behandeln, was passiert, wenn etwas schiefgeht. Netzwerkanfragen fehlen Catch-Blöcke. Dateioperationen fehlt Fehlerbehandlung. Asynchrone Funktionen fehlen Ablehnungs-Handler.

Das liegt nicht daran, dass die KI keine Fehlerbehandlung schreiben kann. Wenn du explizit danach fragst, produziert die KI gründliche Try-Catch-Logik. Das Problem ist, dass das Standardverhalten des Modells darin besteht, die einfachste funktionierende Version zu schreiben, und Fehlerbehandlung ist nicht Teil dieser Voreinstellung. Jedes KI-generierte Code-Review sollte einen Durchgang beinhalten, der nur auf Fehlerpfade schaut.

• Jede asynchrone Funktion sollte einen Catch- oder Ablehnungs-Handler haben.
• Jeder externe API-Aufruf sollte Netzwerkfehler, Timeouts und unerwartete Antwortformate behandeln.
• Jede Datentransformation sollte null, undefined und unerwartete Typen behandeln.
• Jede Datei- oder Datenbankoperation sollte Berechtigungsfehler und fehlende Ressourcen behandeln.

Eine nützliche Technik ist, einen einfachen Test durchzuführen: Entferne die Try-Catch-Blöcke aus dem KI-generierten Code und prüfe, ob die verbleibende Logik noch Sinn ergibt. Wenn ja, hat die KI wahrscheinlich nicht tief über die Fehlerbehandlung nachgedacht. Wenn die Logik von der Fehlerbehandlung abhängt, um zu funktionieren, hat die KI sie richtig integriert.

Checklisten-Punkt 3: Stil- und Konventionsabweichungen

Jede Codebasis hat ungeschriebene Stilkonventionen. Das Team verwendet frühe Rückgaben, keine verschachtelten Ifs. Fehlermeldungen folgen einem bestimmten Format. Variablennamen verwenden ein bestimmtes Muster. KI-Modelle, die auf Millionen von öffentlichen Repositories trainiert wurden, generieren Code, der den statistischen Durchschnitt all dieser Repositories widerspiegelt, nicht die spezifischen Konventionen deiner Codebasis.

Das Ergebnis ist Code, der funktioniert, sich aber fremd anfühlt. Er verwendet eine andere Benennungskonvention, eine andere Modulstruktur oder ein anderes Fehlerbehandlungsmuster als der umgebende Code. Diese Art von Inkonsistenz summiert sich schnell – fünf KI-generierte Funktionen, die mit fünf verschiedenen impliziten Stilen geschrieben wurden, erzeugen eine Codebasis, die sich inkohärent anfühlt und schwerer zu warten ist.

Der beste Ansatz ist, Stilbeispiele in deine Prompts aufzunehmen. Füge eine repräsentative Funktion aus demselben Modul ein und sage verwende diesen Stil. Das gibt der KI eine konkrete Referenz, die ihre Trainingsvoreinstellung überschreibt. Überprüfe während des Reviews, ob der generierte Code von derselben Person geschrieben worden sein könnte, die das umgebende Modul geschrieben hat.

Checklisten-Punkt 4: Über-Engineering und unnötige Abstraktion

KI-Modelle haben eine starke Tendenz zur Abstraktion. Bei einem einfachen Problem generieren sie oft eine Klassenhierarchie, ein Interface, eine Factory und drei Hilfsfunktionen – wo eine einzelne Funktion ausgereicht hätte. Diese Tendenz kommt von den Trainingsdaten, die gut strukturierte Open-Source-Bibliotheken überrepräsentieren und einfache Skripte und Einzweckfunktionen unterrepräsentieren.

KI-Modelle neigen standardmäßig zu Über-Engineering. Dein Review sollte standardmäßig zu Einfachheit neigen. Jede Abstraktion, die die KI eingeführt hat, muss ihre Existenz gegenüber einer einfacheren Alternative rechtfertigen.

Frage dich beim Review: Braucht dieser Code eine Klasse, oder würde eine Funktion reichen? Wird dieses Interface von mehr als einer Implementierung verwendet? Würde die Extraktion dieser Hilfsfunktion genug Wiederholung einsparen, um die Indirektion zu rechtfertigen? Wenn die Antwort auf eine dieser Fragen Nein ist, hat die KI wahrscheinlich über-engineered, und die einfachere Version ist besser.

Checklisten-Punkt 5: Sicherheitslücken

KI-Modelle werden auf Code trainiert, der Sicherheitslücken enthält. Sie lernen Muster aus diesem Code, einschließlich der anfälligen. Während moderne Modelle besser darin sind, offensichtliche Probleme wie SQL-Injection zu vermeiden, produzieren sie immer noch Code mit subtilen Sicherheitsproblemen, die ein Prüfer erkennen muss.

• Prüfe auf hartcodierte Geheimnisse, API-Schlüssel oder Zugangsdaten im generierten Code.
• Stelle sicher, dass Benutzereingaben vor der Verwendung validiert und bereinigt werden.
• Prüfe, ob Authentifizierungs- und Autorisierungsprüfungen bei geschützten Operationen vorhanden sind.
• Stelle sicher, dass generierte SQL-Abfragen parametrisierte Anweisungen verwenden, keine Zeichenkettenverkettung.
• Überprüfe, dass Dateipfade nicht aus nicht vertrauenswürdigen Eingaben ohne Bereinigung konstruiert werden.

Ein sicherheitsfokussierter Review-Durchgang ist für KI-generierten Code, der sensible Daten oder Benutzereingaben verarbeitet, nicht verhandelbar. Die KI weiß nicht, welche Teile deines Systems sicherheitskritisch sind, es sei denn, du sagst es ihr. Führe im Zweifel ein statisches Analysewerkzeug über den generierten Code aus, bevor du ihn mergst.

Checklisten-Punkt 6: Konsistenz mit der bestehenden Architektur

KI-Modelle sehen jede Anfrage isoliert. Sie wissen nicht, dass dein Team letztes Vierteljahr beschlossen hat, React Query für das gesamte Data-Fetching zu verwenden, dass die API immer camelCase-Schlüssel zurückgibt oder dass das Projekt ein bestimmtes State-Management-Muster verwendet. Der Code, den sie generieren, wird intern konsistent sein, kann aber Architekturentscheidungen verletzen, die in der aktuellen Datei nicht sichtbar sind.

Hier bringt der menschliche Prüfer den meisten Mehrwert. Du kennst die Entscheidungen, die in euren ADRs dokumentiert sind, die Muster, die aus Teamdiskussionen hervorgegangen sind, und die Design-Einschränkungen, die in keiner einzelnen Datei festgehalten sind. Prüfe KI-generierten Code anhand dieser unsichtbaren Einschränkungen, nicht nur anhand von Korrektheit und Stil.

Einen nachhaltigen Review-Prozess aufbauen

Je mehr KI von deiner Codebasis generiert, desto mehr muss der Review-Prozess skalieren. Ein Team von vier Personen, das jede KI-generierte Zeile manuell prüft, wird ausbrennen. Der nachhaltige Ansatz kombiniert automatisierte Prüfungen mit fokussierter menschlicher Überprüfung.

Automatisierte Prüfungen sollten halluzinierte Importe, Stilverstöße, fehlende Fehlerbehandlung und häufige Sicherheitsprobleme abfangen, bevor ein Mensch den Code überhaupt zu sehen bekommt. Das reduziert das KI-spezifische Review auf eine kleinere Menge von Anliegen: architektonische Konsistenz, Design-Entscheidungen und die subtilen Probleme, die Linter nicht erkennen können.

Das Ziel ist nicht, menschliche Reviews von KI-generiertem Code zu eliminieren. Es geht darum, dieses Review so effizient wie möglich zu gestalten, indem Probleme herausgefiltert werden, die Werkzeuge automatisch abfangen können, und die menschliche Aufmerksamkeit für die Urteile reserviert wird, die nur Menschen fällen können. Mit dem richtigen Prozess wird das Prüfen von KI-generiertem Code schneller und zuverlässiger als das Prüfen von menschlich geschriebenem Code – weil die Fehler der KI vorhersehbarer sind.