KI-Code überprüfen: Absicht statt Diff-Analyse

Ingenieure bei Aviator haben ihren Code-Review-Prozess umstrukturiert, um eine vierfache Steigerung der KI-generierten Pull Requests zu bewältigen. Durch die Verlagerung des Fokus vom Lesen jeder einzelnen Codezeile hin zur Überprüfung der Absicht, der Akzeptanzkriterien und der Systeminvarianten konnte das Team die mediane Merge-Zeit von 2,1 Tagen auf 3,4 Stunden reduzieren. Dieser Ansatz behält die menschliche Aufsicht bei, automatisiert jedoch routinemäßige Prüfungen und ermöglicht es neun Ingenieuren, über 400 zusammengeführte PRs pro Woche zu verwalten.

Was passiert ist

Als sich der Entwicklungsworkflow von Aviator von menschengeschriebenem Code mit KI-Unterstützung zu KI-generiertem Code mit menschlicher Anleitung wandelte, stieg das Volumen der Änderungen erheblich an. Die wöchentlich zusammengeführten Pull Requests sprangen von etwa 100 auf mehr als 400, wobei die mediane PR-Größe 640 Zeilen erreichte. Dies überschritt die Schwelle von 400 Zeilen, ab der die Fehlererkennung typischerweise nachlässt. Traditionelle Review-Methoden skalierten nicht: Das Hinzufügen eines KI-Reviewers begrub kritische Designentscheidungen unter trivialen Kleinigkeiten, während die Einführung einer vierstündigen Review-SLA (Service Level Agreement) zu leeren Genehmigungen führte, da Ingenieure nur noch oberflächlich prüften, um Fristen einzuhalten.

Das Team erkannte, dass das Aufspüren von Fehlern nie das primäre Ziel des Code-Reviews war. Unter Berufung auf eine Microsoft-Studie aus dem Jahr 2013 stellten sie fest, dass nur 14 % der Review-Kommentare Defekte adressieren. Der Kernwert des Reviews liegt im Wissensaustausch und in der Aufrechterhaltung eines aktuellen mentalen Modells des Systems. Da KI-Agenten den Großteil des Codes schreiben, war diese Wissensübertragungsfunktion gefährdet. Anstatt zu versuchen, den Diff besser zu lesen – dieser zeigt zwar, was geändert wurde, aber nicht warum –, hörte das Team auf, den Diff überhaupt zu prüfen.

Wie es funktioniert

Der neue Workflow teilt die Aufgaben des Code-Reviews in verschiedene Stufen auf, die von unterschiedlichen Mechanismen bearbeitet werden. Erstens kreuzverhören sich Review-Agenten gegenseitig, bevor ein PR existiert, diskutieren Implementierungsdetails und dokumentieren Meinungsverschiedenheiten. Nur ungelöste Probleme, wie etwa Namenskonventionen, werden an Menschen eskaliert. Zweitens erfasst das System die Absicht und die Akzeptanzkriterien direkt aus der Coding-Sitzung. Jedes Mal, wenn ein Ingenieur einen Agenten korrigiert oder dessen Fragen beantwortet, werden diese Interaktionen zu verifizierbaren Kriterien. Die Absicht erklärt, warum eine Änderung vorgenommen wird, während die Akzeptanzkriterien definieren, wie sie sich verhalten soll.

Drittens kodifizierte das Team wiederkehrende Review-Kommentare in Systeminvarianten. Durch die Analyse eines Jahres an Review-Historie destillierten sie 11.400 Kommentare in 64 genehmigte Invarianten, wie beispielsweise die Anforderung von Audit-Log-Einträgen für Konfigurationsänderungen. Diese Invarianten werden mit Tools wie ast-grep in deterministische Regeln übersetzt, die in Sekunden neben probabilistischen Modellprüfungen laufen. Schließlich wird jedes Akzeptanzkriterium durch Nachweise belegt. Agenten starten Vorschauumgebungen, um benutzerähnliche Szenarien durchzuführen, und zeichnen Screenshots und Logs auf, um das Verhalten zu verifizieren. Dies liefert einen konkreten Beweis dafür, dass eine Funktion wie beabsichtigt funktioniert, anstatt nur einen CI-Check zu bestehen.

Wichtige Details

• Steigerung des Durchsatzes: Dieselben neun Ingenieure führen nun viermal so viele Pull Requests pro Woche zusammen, von ~100 auf >400.
• Geschwindigkeitsverbesserung: Die mediane Zeit bis zum Merge sank von 2,1 Tagen auf 3,4 Stunden.
• Qualitätsmetrik: Die Anzahl der Reverts pro 100 PRs ging um 40 % zurück, was auf eine höhere initiale Codequalität hindeutet.
• Review-Effizienz: Die Anzahl der menschlichen Kommentar-Threads pro PR fiel von 6,2 auf 1,3, wobei der Fokus nur auf hochrangigen Entscheidungen lag.
• Erstellung von Invarianten: 11.400 historische Kommentare wurden analysiert, um 64 genehmigte Invarianten und 212 Kandidatenregeln zu erstellen.
• Verifizierungsgeschwindigkeit: Neunzehn Schlüssel-Invarianten laufen deterministisch in 0,3 Sekunden und liefern schnelles Feedback ohne Modell-Latenz.

Warum das wichtig ist

Für Engineering-Teams, die KI-Coding-Agenten einführen, demonstriert diese Fallstudie, dass traditionelle Review-Engpässe gelöst werden können, indem man ändert, was Menschen evaluieren. Wenn PR-Größen die kognitiven Grenzen des Menschen für detaillierte Inspektionen überschreiten, wird das Verlassen auf Diffs ineffektiv. Durch die Automatisierung der Überprüfung von Regeln und Verhalten können sich Ingenieure auf architektonische Entscheidungen und das Systemverständnis konzentrieren. Dieser Wandel schützt den Wissensaustauschaspekt des Reviews, der für die langfristige Wartbarkeit entscheidend ist, während Maschinen die repetitive Validierung von Constraints übernehmen.

Der Ansatz hebt auch die Bedeutung hervor, die Absicht früh im Entwicklungszyklus zu erfassen. Wenn Akzeptanzkriterien aus Echtzeit-Interaktionen zwischen Ingenieuren und KI-Agenten abgeleitet werden, spiegeln sie die tatsächlichen Anforderungen genauer wider als nachträglich erstellte Tests. Dies stellt sicher, dass der Verifizierungsprozess das testet, was für die Geschäftslogik zählt, und nicht nur das, was leicht zu automatisieren ist. Teams, die KI-native Workflows aufbauen, sollten erwägen, die Durchsetzung von Regeln von der Entscheidungsfindung zu trennen, um Geschwindigkeit beizubehalten, ohne die Qualität zu opfern.

Was Sie tun können

• Überprüfen Sie Ihre Review-Kommentare: Kategorisieren Sie vergangene PR-Kommentare in Regeln, Entscheidungen und einmalige Fixes, um Kandidaten für die Automatisierung zu identifizieren.
• Definieren Sie Systeminvarianten: Extrahieren Sie wiederkehrende Constraints aus Ihrer Codebasis und kodieren Sie sie als deterministische Checks mit Tools wie ast-grep.
• Erfassen Sie die Absicht während des Codings: Speichern Sie den Dialog zwischen Ingenieuren und KI-Agenten, um automatisch Akzeptanzkriterien zu generieren.
• Implementieren Sie evidenzbasierte Verifizierung: Nutzen Sie automatisierte Agenten, um benutzerähnliche Szenarien in Vorschauumgebungen auszuführen und Logs als Nachweis aufzuzeichnen.
• Verlagern Sie den Fokus des menschlichen Reviews: Schulen Sie Reviewer darin, zeilenweise Diffs zu überspringen und stattdessen Absicht, Nachweise und ungelöste Designentscheidungen zu bewerten.
• Agenten-Debatte vor dem PR: Konfigurieren Sie KI-Agenten so, dass sie Implementierungsdetails diskutieren, bevor ein PR erstellt wird, um triviale Probleme automatisch zu lösen.