KI-generierten Code reviewen: eine praktische Checkliste vor dem Merge

Code von einem Assistenten kompiliert meist, liest sich gut und tut ungefähr das, worum Sie gebeten haben. Genau deshalb winkt man ihn so leicht durch. Die Fehler sind selten Syntaxfehler. Es sind Entscheidungen, die das Modell stillschweigend getroffen hat: eine Abhängigkeit, von der es annahm, dass sie existiert, eine Berechtigungsprüfung an der falschen Stelle, ein Fehler, den es ignorieren wollte.

Das ist die Checkliste, die wir beim Review KI-gestützter Änderungen verwenden. Es geht nicht darum, ob der Code elegant ist. Es geht um die Handvoll Probleme, aus denen Incidents werden.

Warum KI-Code ein anderes Review braucht

Wenn ein Kollege Code schreibt, können Sie den Teilen, die er nicht erwähnt hat, meist vertrauen. Er kannte die Codebasis, hat die Änderung lokal getestet und hätte Bescheid gesagt, wenn etwas unfertig wäre. Ein Modell hat nichts von diesem Kontext, sofern Sie ihn nicht mitgegeben haben, und es neigt dazu, Lücken mit etwas Plausiblem zu füllen statt mit einer Rückfrage. Das Review verschiebt sich deshalb von „Ist das gut geschrieben?“ zu „Was hat es angenommen?“.

1. Abhängigkeiten

Prüfen Sie jedes Paket, das die Änderung hinzufügt. Existiert es in der Registry? Ist es das Paket, das die offizielle Dokumentation empfiehlt, oder eines mit ähnlichem Namen? Wurde es letzte Woche veröffentlicht? Modelle erfinden manchmal Paketnamen, und einige dieser Namen werden von Angreifern registriert. Unser Leitfaden zu Slopsquatting zeigt, wie Sie ein Paket in einer Minute prüfen.

Achten Sie auch auf Versionen. Eine Version, die auf etwas gepinnt ist, das nie veröffentlicht wurde, bricht bei der nächsten frischen Installation, und eine nicht gepinnte Abhängigkeit bedeutet, dass der Code, den Sie reviewt haben, nicht der Code ist, der läuft.

2. Secrets und öffentliche Variablen

Durchsuchen Sie den Diff nach Schlüsseln, Tokens und Passwörtern, auch in Testdateien und Beispielen. Sehen Sie sich dann Umgebungsvariablen mit öffentlichen Präfixen wie VITE_, NEXT_PUBLIC_ oder EXPO_PUBLIC_ an. Alles mit diesen Präfixen wird beim Build in das Browser-Bundle kopiert. Ein Assistent benennt ein Secret womöglich in eines davon um, damit eine Funktion im Browser läuft. Dieser Leitfaden geht die Variante dieses Fehlers mit LLM-API-Schlüsseln durch.

3. Wo der Zugriff geprüft wird

Suchen Sie die Zeile, die entscheidet, ob der aktuelle Nutzer das tun darf. Steht sie in einer React-Komponente, einem Route Guard oder einem versteckten Button, ist sie eine UX-Funktion, keine Sicherheit. Jeder kann Ihre API direkt aufrufen. Die Prüfung muss auf dem Server stattfinden, bei jedem Request, bezogen auf die Ressource, auf die zugegriffen wird: nicht nur „Ist dieser Nutzer angemeldet?“, sondern „Gehört diese Rechnung diesem Nutzer?“.

Achten Sie auf neue API-Routen ganz ohne Auth-Middleware und auf Backends wie Supabase oder Firebase, bei denen die Datenbank aus dem Browser erreichbar ist. Dort sind die Regeln der Datenbank selbst der Schutz. Eine Supabase-Tabelle ohne Row Level Security steht jedem offen, der Ihren öffentlichen Anon-Key hat.

4. Unvertrauenswürdige Eingaben

Verfolgen Sie Nutzereingaben von ihrem Eintrittspunkt bis zu ihrer Verwendung. Per String zusammengesetztes SQL, aus Request-Feldern gebaute Shell-Befehle, Dateipfade aus Query-Parametern, aus Nutzerinhalten gerendertes HTML und im Auftrag eines Nutzers abgerufene URLs sind die klassischen Muster für Injection, Path Traversal, XSS und SSRF. Assistenten erzeugen sie nach wie vor, vor allem wenn der umgebende Code bereits etwas Ähnliches tut.

// Looks harmless, is an injectiondb.query(`SELECT * FROM users WHERE email = '${req.query.email}'`); // Parameterizeddb.query('SELECT * FROM users WHERE email = $1', [req.query.email]);

5. Unfertiger Code

Lange Generierungen brechen manchmal vorzeitig ab. Durchsuchen Sie die Änderung nach Platzhaltern: TODO, „implement later“, „rest of the code here“, Funktionen, die fest codierte Beispieldaten zurückgeben, Mock-Zugangsdaten und Dateien mit Namen wie utils copy.ts. Suchen Sie auch nach pauschalen Unterdrückungen wie // @ts-ignore, eslint-disable am Anfang einer Datei oder any, um den Typchecker ruhigzustellen. Sie verbergen oft genau das Problem, das das Modell nicht lösen konnte.

6. Fehlerbehandlung

Ein catch-Block, der loggt und weitermacht oder alles abfängt und ein leeres Ergebnis zurückgibt, macht aus einem lauten Fehler stillen Datenverlust. Fragen Sie, was passieren soll, wenn dieser Aufruf fehlschlägt, und ob der Code das tut. Seien Sie misstrauisch bei Retries ohne Limit und bei Fehlern, die in Erfolgsantworten umgewandelt werden.

7. Tests

Generierte Tests sollten Sie Zeile für Zeile lesen. Häufige Probleme: Tests, die nie etwas prüfen, Tests, die genau die Funktion mocken, die sie testen sollen, Assertions, die nur prüfen, ob eine Funktion aufgerufen wurde, und zurückgelassene .only oder .skip. Eine grüne Testsuite ist kein Beleg, solange Sie nicht wissen, dass sie fehlschlagen kann. Machen Sie den Code einmal absichtlich kaputt und schauen Sie, ob ein Test es bemerkt.

8. Timeouts und blockierende Aufrufe

Ausgehende HTTP-Aufrufe ohne Timeout sind ein Produktions-Incident, der nur auf eine langsame Abhängigkeit wartet. Viele verbreitete Clients warten standardmäßig unbegrenzt, darunter Pythons requests und Gos http.DefaultClient. In Node.js blockieren synchrone Dateioperationen oder Passwort-Hashing in einem Request-Handler jeden anderen Request in diesem Prozess. Das zeigt sich bei lokalen Tests selten, weil Ihr Laptop und Ihre Abhängigkeiten schnell und unbelastet sind.

9. Datenzugriff

Suchen Sie nach Abfragen in Schleifen (das N+1-Problem), Listen-Endpunkten, die alle Zeilen ohne Paginierung zurückgeben, und Datenbank-Clients, die bei jedem Request neu erstellt statt gemeinsam genutzt werden. Prüfen Sie auch Migrationen sorgfältig: Ein Schema-Sync, der beim Start läuft, oder eine Migration, die eine Tabelle löscht und neu anlegt, kann beim nächsten Deployment Produktionsdaten löschen.

10. LLM-Funktionen

Wenn die Änderung ein Modell aufruft, behandeln Sie dessen Ausgabe als unvertrauenswürdige Eingabe. Sie darf nie ausgeführt, in SQL eingefügt oder als rohes HTML gerendert werden. Prüfen Sie, dass der API-Schlüssel auf dem Server bleibt, dass die Route, die das Modell aufruft, einen angemeldeten Nutzer voraussetzt und ein Rate Limit hat und dass die Länge der Ausgabe begrenzt ist. Wenn ein Agent Tools hat, prüfen Sie, was diese Tools tun können und ob Text aus Dokumenten oder Webseiten sie steuern kann.

Zur Routine machen

Zehn Prüfungen pro Pull Request sind von Hand eine Menge, und der Sinn einer Checkliste ist, dass Sie sich nicht mehr auf Ihr Gedächtnis verlassen. Die meisten dieser Punkte lassen sich zumindest teilweise automatisieren. So bleibt Ihre Aufmerksamkeit für das, was Tools schlecht können, etwa ob die Änderung das tut, was das Produkt tatsächlich braucht.

vetkit fasst diese Prüfungen in Suites zusammen: Sicherheit (Secrets, verwundbare Abhängigkeiten, Schwachstellen im Code, Infrastrukturkonfiguration), Codequalität, Nachhaltigkeit, KI-Code-Risiken (erfundene Pakete, unfertiger Code, Fallstricke von App-Plattformen, LLM- und Agent-Sicherheit) und Produktionsreife (Timeouts, blockierende Aufrufe, Datenbanknutzung, betriebliche Grundlagen). Es liest Ihren Code, ohne ihn zu installieren, zu bauen oder auszuführen, und meldet Befunde mit Datei, Zeile und einem Lösungsvorschlag. Wie jede statische Analyse kann es Dinge übersehen und sich irren; es unterstützt ein Review also, statt es zu ersetzen.