Code nach Cursor, Claude Code und Codex prüfen

Ein Coding-Agent verkürzt die Zeit von der Aufgabe bis zum Diff, übernimmt aber nicht die Verantwortung für das Release. KI-geschriebener Code ist nicht gefährlich, weil er eine besondere maschinelle Fehlerkategorie hätte. Er erzeugt gewöhnliche Bugs schnell, über mehrere Dateien hinweg und mit überzeugenden Erklärungen. Deshalb sollte ein Review mit den Grenzen der Änderung und reproduzierbaren Signalen beginnen, nicht mit einem weiteren Chatbot.

Erkläre, warum jede geänderte Datei in den Diff gehört

Bitte den Agenten um eine kurze Zusammenfassung und vergleiche sie dann mit dem tatsächlichen Diff. Entferne beiläufige Formatierung, unerklärte Lockfile-Updates, Debug-Code und Änderungen an Nachbarmodulen, die die Aufgabe nicht braucht. Teile einen großen Diff nach Möglichkeit auf: Datenschema, Server, Oberfläche und Tests lassen sich als getrennte logische Einheiten leichter beurteilen.

Finde die neue Quelle der Wahrheit. Wo lebt der State jetzt, wer ruft die Funktion auf, und welche alten Pfade bleiben bestehen? Ein Agent fügt oft eine neue Schicht hinzu, ohne die frühere zu entfernen oder zu aktualisieren. Eine Suche nach Name, Route und Typ kann zwei konkurrierende Implementierungen sichtbar machen.

Lass Compiler und Tests vor einem KI-Reviewer sprechen

Führe Formatierung, Linting, Typprüfung, Unit-Tests und Integrationstests mit denselben Befehlen wie in CI aus. Wenn dem Projekt diese Prüfungen fehlen, ist das ein eigenes Risiko und kein Grund, sie durch ein Modell zu ersetzen. Ein deterministisches Werkzeug wiederholt eine Regel exakt; ein KI-Reviewer schätzt wahrscheinliche Probleme ein und kann etwas Einfaches übersehen.

Ein neuer Test sollte gegen den alten Code fehlschlagen und nach dem Fix bestehen. Ein Test, der in beiden Versionen grün ist, beweist womöglich nichts. Reproduziere bei einem Bugfix den ursprünglichen Fehler; decke bei einem Feature den Hauptpfad, Grenzfälle und den Ausfall einer Abhängigkeit ab.

Playwright validiert eine User Journey, nicht die Eleganz der Implementierung

Füge einen Browser-Test für einen kritischen Web-Flow hinzu oder aktualisiere ihn. Playwright-Projekte führen verschiedene Browser und Umgebungen aus, während der trace viewer Schritte, DOM-Zustand, Netzwerkaktivität und Screenshots für die Diagnose in CI bewahrt. Codegen ist ein nützlicher Entwurf, aber Locators und Erwartungen sollten auf stabiles, für Nutzer sichtbares Verhalten umgeschrieben werden.

Decke nicht jeden Setter mit E2E ab. Sichere die Journey ab, deren Ausfall teuer ist: Anmeldung, Zahlung, Objekterstellung, Veröffentlichung oder Rollenberechtigungen. API- und Unit-Tests können die günstigeren Zweige abdecken.

Migrationen und Hintergrundarbeit brauchen eine Rollback-Probe

Wenn ein Diff das Schema ändert, prüfe vorhandene Zeilen, Nullwerte, Indizes, Locks und Ausführungszeit. Führe die Migration gegen eine Kopie mit realistischem Volumen aus. Entscheide, ob der neue Code während eines Rolling Deploy mit dem alten Schema funktioniert und ob die Anwendung nach der Migration zurückgerollt werden kann.

Teste bei Queues und Webhooks Wiederholungen, Reihenfolge, Timeouts und teilweise Fertigstellung. Agenten schreiben bereitwillig einen Happy Path, bei dem ein Event genau einmal eintrifft. Die Produktion testet tendenziell das Gegenteil.

Berechtigungen und Datenpfade sind wichtiger als verdächtig aussehende Zeilen

Verfolge nicht vertrauenswürdige Eingaben bis zur Datenbank, zum Dateisystem, zur Shell, zu HTML und zu ausgehenden Requests. Überprüfe die Autorisierung auf dem Server, statt dich auf einen versteckten Button zu verlassen. Secrets dürfen nicht in ein Client-Bundle, Logs, eine Fehlerantwort oder den Kontext eines Modells gelangen.

Prüfe Abhängigkeiten und generierten Code. Eine neue Bibliothek erweitert die Supply-Chain-Oberfläche und die Bundle-Größe; ein ähnlich aussehendes Paket kann ein Tippfehler sein. Prüfe bei personenbezogenen Daten Minimierung, Aufbewahrung und ob Datensätze ohne Autorisierung an ein Modell gesendet werden.

Eine zweite KI funktioniert am besten als eng gebriefter Gegner

Gib den Diff nach den konventionellen Prüfungen an einen separaten Reviewer-Agenten. Setze eine präzise Aufgabe: Verletzungen von Invarianten, fehlende Tests, API-Inkompatibilität, Race Conditions oder Autorisierungs-Bypässe finden. Verlange Datei, Zeile und Fehlerszenario. „Review this code“ erzeugt sehr viel stilistisches Rauschen.

Akzeptiere keinen Befund, ohne ihn zu reproduzieren. Ein Modell kann einen Vertrag erfinden oder eine Projektregel übersehen. Relevante Produkte sind in AIDives Sammlung für KI-Code-Review aufgeführt, ausführungsorientierte Produkte in der Sammlung für KI-Tests.

Der Release-Review endet mit Beobachtung nach dem Deployment

Prüfe vor dem Merge die PR-Beschreibung, das verknüpfte Issue, Dokumentation, Flags, Metriken und den Rollback-Plan. Beobachte nach dem Release mehr als Serverfehler: Schritt-Conversion, Latenz, Queue-Tiefe, Ablehnungsraten und Business-Invarianten. Ein schneller Rollback ist während eines Incidents wertvoller als eine lange Debatte mit einem Agenten.

Die kurze Abfolge lautet: den Diff verstehen, ihn verkleinern, deterministische Prüfungen ausführen, die kritische Journey reproduzieren, Daten und Zugriff getrennt prüfen, KI als zweiten Reviewer nutzen und dann mit Beobachtung releasen. Generierungsgeschwindigkeit zählt nur, wenn das Team die Fähigkeit behält, Korrektheit zu beweisen.