Generierten Code prüfen, ohne alles neu zu schreiben

Prüf zuerst die Abhängigkeiten, nicht die Logik

Modelle erzeugen gelegentlich Importe für Pakete, die es unter diesem Namen nicht gibt oder nie gab. Beim Lesen wirkt der Name plausibel, weil er dem Muster echter Pakete folgt. Genau dieses Muster wird ausgenutzt: Wer den halluzinierten Namen in einer öffentlichen Registry anlegt, bekommt Installationen von allen, die den Vorschlag ungeprüft übernommen haben. Der erste Blick im Review gilt deshalb der Importliste, nicht der Funktion.

Die Prüfung selbst ist schnell erledigt. Gibt es das Paket, seit wann, wie viele Veröffentlichungen hat es, wer pflegt es, passt es zu dem, was hier gebraucht wird. Wenn ein neues Paket im Diff auftaucht, das nur eine einzige Hilfsfunktion beisteuert, ist meist die bessere Frage, ob diese zwanzig Zeilen nicht direkt ins Projekt gehören.

Dasselbe gilt für Versionen. Modelle greifen auf Muster aus ihrem Trainingsmaterial zurück, und das kann eine Bibliotheksversion sein, die inzwischen bekannte Schwachstellen hat oder deren Aufrufform sich geändert hat. Ein Abgleich der Abhängigkeiten gegen eine Schwachstellendatenbank gehört als Pflichtschritt in die Pipeline, nicht in den Kopf der Person, die reviewt.

Der Erfolgspfad stimmt fast immer, die Fehlerpfade nicht

Generierter Code beschreibt zuverlässig, was passieren soll, wenn alles gut geht. Was passiert, wenn die Antwort leer ist, die Verbindung abbricht, ein Feld null enthält oder die Datei größer ist als erwartet, bleibt oft unbeantwortet oder wird mit einem pauschalen Abfangen aller Ausnahmen erschlagen, das den Fehler verschluckt. Lies im Review zuerst die Stellen, an denen etwas schiefgehen kann, und erst danach die eigentliche Logik.

Der zweite Blick gilt den Randfällen der Daten: leere Liste, ein einzelnes Element, Sonderzeichen, Zeitzonen, Zahlenformate. Hier liefern Modelle plausible, aber ungeprüfte Annahmen. Wenn im Diff eine Annahme steckt, die nirgends abgesichert ist, gehört an diese Stelle entweder eine Prüfung oder ein Test.

Tests, die nichts beweisen

Wenn dasselbe Modell Code und Tests erzeugt, prüfen die Tests häufig die Implementierung statt die Anforderung. Sie bestätigen, dass die Funktion das tut, was in ihr steht, und laufen deshalb zuverlässig grün, auch wenn die Anforderung von Anfang an falsch verstanden wurde. Das ist gefährlicher als gar kein Test, weil eine grüne Pipeline Sicherheit suggeriert.

Der Ausweg ist unspektakulär, aber wirksam. Formulier die erwarteten Ergebnisse aus der fachlichen Anforderung heraus, bevor du dir Tests erzeugen lässt, und prüf im Review jeden Testfall gegen die Anforderung, nicht gegen den Code. Ein Testfall, der bei falscher Logik nicht rot werden kann, ist keiner.

Werkzeuge zuerst, Menschen danach

Alles, was eine Maschine finden kann, soll eine Maschine finden, bevor ein Mensch den Diff öffnet. Das sind Formatierung und Linterregeln, statische Codeanalyse auf bekannte Schwachstellenmuster, der Abgleich der Abhängigkeiten, eine Suche nach Zugangsdaten im Diff und die Typprüfung. Laufen diese Schritte verpflichtend vor dem Review, kommt der Mensch mit voller Aufmerksamkeit an die Stellen, die Urteilsvermögen verlangen.

Für Zugangsdaten lohnt der eigene Schritt besonders. Beispielwerte aus dem Prompt landen erstaunlich oft als echte Zeichenkette im Code, weil sie im Vorschlag schon eingesetzt waren. Ein Scanner auf Muster von Schlüsseln und Token im Diff kostet kaum etwas und verhindert den peinlichsten Fall.

Wer den Pull Request eröffnet, verantwortet den Code

Die wichtigste Regel ist organisatorisch, nicht technisch. Der Ursprung des Codes ändert die Verantwortung nicht. Wer einen Vorschlag übernimmt, muss ihn erklären können, Zeile für Zeile, so wie er selbst geschriebenen Code erklären würde. „Das hat das Modell so gemacht“ ist im Review keine gültige Antwort.

Hilfreich ist, im Pull Request zu vermerken, welche Teile generiert wurden. Nicht zur Kontrolle, sondern weil das Review dann gezielt auf die typischen Schwächen schauen kann. Teams, die damit offen umgehen, prüfen schneller und finden mehr als Teams, in denen niemand darüber spricht.

Halte den Diff klein. Ein Vorschlag über vierhundert Zeilen wird nicht ernsthaft gelesen, egal wer ihn geschrieben hat. Bei generiertem Code fällt das stärker ins Gewicht, weil die Menge, die in kurzer Zeit entsteht, die verfügbare Prüfkapazität schnell übersteigt.