Wie prüft man KI-generierten Code im Code-Review?

Coding-Agenten bringen mehr Code, und Reviews dauern länger

Diese vier Zahlen stammen aus einer einzigen Studie. Zwei Forscher der Harvard University haben mit den Daten einer Plattform für Engineering-Analytik 718 Unternehmen von Januar 2021 bis März 2026 beobachtet (Fassung der Studie vom August 2026). Ein Coding-Agent ist ein Tool, das eine Aufgabe übernimmt, Code über mehrere Dateien hinweg schreibt, die Tests ausführt und so lange weitermacht, bis die Arbeit erledigt ist. In den Unternehmen, die auf solche Tools umgestiegen sind, stieg die Zahl der hinzugefügten Codezeilen um 30 %, die der Commits um 20 % und die der Pull Requests um 23 %.

Die erledigte Arbeit wuchs nicht im selben Tempo: Bei den abgeschlossenen Tickets gab es nur einen kleinen Anstieg, und der ist statistisch nicht signifikant. Woran das liegt, zeigt dieselbe Studie. Die Zeit vom Öffnen eines Pull Requests bis zum Merge stieg um 49 %, der Anteil der Pull Requests, bei denen Änderungen angefordert wurden, hat sich fast verdoppelt, und die Zahl der Review-Kommentare pro Pull Request stieg um 35 %. Das Fazit der Autoren: Der Engpass ist das Code-Review.

Andere Messungen zeigen in dieselbe Richtung. Im Bericht 2026 von LinearB (mehr als 8,1 Millionen Pull Requests) warten KI-generierte Pull Requests 4,6-mal länger, bis jemand mit dem Review beginnt, werden dann aber doppelt so schnell geprüft. In einer Umfrage von Sonar unter mehr als 1.100 Entwicklern vertrauen 96 % der Befragten nicht voll darauf, dass KI-generierter Code korrekt ist; 48 % sagen, dass sie ihn vor dem Commit immer prüfen.

Wir entwickeln diffox, ein Tool, das Pull Requests prüft. Die Liste unten ist aus dieser Arbeit und aus den Regeln unseres eigenen Repositorys entstanden; Sie können sie auch ohne Tool von Hand anwenden.

KI-generierter Code klingt in jeder Zeile gleich sicher

Wenn Sie den Code eines Kollegen prüfen, kennen Sie den Autor: Sie ahnen, was er gut kann und wo er sich beeilt hat, und wo Sie unsicher sind, fragen Sie nach. Ist der Autor ein Sprachmodell, gibt es nichts davon.

So beschreibt eine Studie, die JetBrains Research im Oktober 2026 veröffentlicht hat, das Problem. Das Modell präsentiert jede Zeile, die es erzeugt, mit derselben Sicherheit; nichts zeigt an, dass die Authentifizierungslogik leicht war und die Datenbankmigration schwer. Jede Zeile zu lesen, skaliert nicht, wenn die Änderungen der Agenten immer größer werden. Laut den Forschern geht es nicht darum, den Diff zu lesen, sondern um Vertrauenskalibrierung: den Aufwand für das Review im Verhältnis zum Risiko jedes Abschnitts zu verteilen. Die Studie stützt sich auf vier Workshops mit 17 Praktikern und eine Umfrage unter 43 Softwareentwicklern.

Auch die gewohnten Warnzeichen fallen aus. In Code, den ein Mensch geschrieben hat, sagt Ihnen eine unordentliche Funktion oder ein halb fertiger Kommentar: „Hier genau hinsehen.“ KI-generierter Code kompiliert meist, hat saubere Namen und bringt Kommentar und Test gleich mit. In der Umfrage von Sonar nennen 53 % der Entwickler genau das unter den negativen Folgen von KI für die technischen Schulden: Code, der richtig aussieht, aber nicht verlässlich ist.

Wie sollte eine Code-Review-Checkliste aussehen?

Die Liste schlägt eine Reihenfolge vor. Die ersten beiden Fragen beantworten Sie zum Teil schon, bevor Sie den Code lesen, und sie sagen Ihnen, wo Sie hinschauen sollen; die dritte prüft die Belege; die letzten beiden verlangen jeweils einen eigenen Lesedurchgang. In dieselbe Richtung geht die JetBrains-Studie: erst der Überblick, dann die Dateien, zuletzt die Zeilen.

Die Liste wurde für diesen Beitrag zusammengestellt. Sie stützt sich auf den Leitfaden “Review AI-generated code” von GitHub, den Code-Review-Leitfaden von Google und die Regeln, die wir in unserem eigenen Repository anwenden.

Beschreibung, Kommentare und Dateiliste lesen Sie vor dem Code

Für die erste Frage lesen Sie die Beschreibung des Pull Requests wie eine Liste von Behauptungen. Steht dort „Wiederholt eine fehlgeschlagene Anfrage dreimal“, suchen Sie im Diff die drei Versuche. Kommentare lesen Sie genauso: Ein Kommentar beschreibt vielleicht, was der Code tun soll, und nicht, was er tut. Ein Beispiel:

def fetch_prices(symbols):
    """Holt die Preise; wiederholt bei Netzwerkfehlern dreimal."""
    try:
        return client.get_prices(symbols)
    except Exception:
        return []

Diese Funktion kompiliert und besteht den Test, der den Normalfall prüft. Sie hat zwei Probleme. Der Docstring spricht von drei Versuchen, der Code versucht es einmal. Und der Fehler wird verschluckt: Selbst wenn der Dienst ausgefallen ist, bekommt der Aufrufer eine leere Liste und liest daraus „keine Preise“.

Für die zweite Frage sehen Sie sich die Dateiliste an, bevor Sie den Code lesen. Soll die Änderung einem Endpunkt ein Feld hinzufügen, muss die Beschreibung erklären, warum sich ein Modul geändert hat, das damit nichts zu tun hat. Lesen Sie dann die gelöschten Zeilen: Eine neue Zeile fällt auf, eine gelöschte Validierung oder Logzeile nicht. Prüfen Sie bei jedem entfernten Verhalten, ob sich noch irgendwo etwas darauf verlässt.

Der dritte Prüfpunkt ist der Weg, den ein Fehler nimmt. In unserem eigenen Repository gilt die Regel: Ein abgefangener Fehler muss den Aufrufer erreichen. Ein breites except, ein Ausweichpfad, der einen Standardwert zurückgibt, oder ein ignorierter Rückgabewert behebt den Fehler nicht; er macht ihn unsichtbar.

Ein Test, der besteht, prüft nicht unbedingt etwas

Ein Coding-Agent führt die Tests selbst aus und macht weiter, bis sie bestehen. Bei einem Pull Request von einem Agenten ist „Die Tests sind grün“ deshalb eine Voraussetzung und für sich allein kein Beleg. Der Code-Review-Leitfaden von Google fragt dasselbe: Schlagen die Tests wirklich fehl, wenn der Code kaputt ist? Ein Beispiel:

def test_discount_is_applied():
    order = make_order(total=100)
    apply_discount(order, code="WELCOME10")
    assert order is not None

Dieser Test besteht auch dann, wenn der Rabatt gar nicht angewendet wird. Sein Name spricht vom Rabatt, seine Assertion prüft nur, dass die Bestellung existiert. Die Korrektur ist eine Zeile: assert order.total == 90.

Der erste Prüfpunkt heißt Mutationsprüfung: Sie nehmen die Korrektur zurück und sehen, dass der Test fehlschlägt. Beim zweiten hilft eine Unterscheidung: Eine Suche ist keine Assertion. Ein Test, der sagt „Die Fehlermeldung steht nicht in der Ausgabe“, besteht auch, wenn die Meldung nie erzeugt wurde; er braucht ein Gegenbeispiel, das zeigt, dass die Suche überhaupt etwas finden kann.

Testdaten gehören zum selben Problem. Ein ausgedachtes Beispiel prüft, wie sich der Autor die Daten vorstellt. Nehmen Sie das Beispiel aus einem echten Datensatz, oder gleichen Sie es mit einem echten Datensatz ab.

Code, der kompiliert, prüfen Sie trotzdem eigens auf Sicherheit

Laut dem Bericht von Veracode vom Juli 2026 kompiliert Code, der ohne Sicherheitshinweise im Prompt erzeugt wurde, fast immer; die Quote bestandener Sicherheitstests liegt über mehr als 100 Modelle hinweg aber im Schnitt bei 56 %. Die Quote hängt von der Sprache ab: 63 % bei Python, 30 % bei Java. Der Bericht testet die Modelle pur, nicht einen Agenten mit Werkzeugen, Schutzmechanismen oder menschlichem Review drumherum. Das Ergebnis ist trotzdem eindeutig: Sicherheit braucht einen eigenen Lesedurchgang.

Achten Sie dabei auf drei Stellen. Erreichen externe Eingaben ungefiltert eine Abfrage, einen Shell-Befehl oder einen Dateipfad? Hat der neue Endpunkt dieselbe Berechtigungsprüfung wie die Endpunkte daneben, und stehen Zugangsdaten im Code oder im Log? Zum Schluss sehen Sie sich jede neue Abhängigkeit einzeln an.

Eine Studie, die für die USENIX Security 2025 angenommen wurde, hat 576.000 Codebeispiele von 16 Modellen untersucht. Bei kommerziellen Modellen gab es im Schnitt mindestens 5,2 % der vorgeschlagenen Pakete gar nicht, bei Open-Source-Modellen 21,7 %. Deshalb empfiehlt der Leitfaden von GitHub, bei einer vorgeschlagenen Abhängigkeit zu prüfen, ob es sie gibt, ob sie noch gepflegt wird und welche Lizenz sie hat.

Der Maßstab für das Review sind die Regeln, die im Repository stehen

Die fünfte Frage lautet nicht, ob der Code richtig ist, sondern ob er in dieses Repository gehört. Stehen Ihre Regeln in einer Datei (AGENTS.md, CLAUDE.md oder CONTRIBUTING.md), lassen Sie diese Datei während des Reviews offen und gleichen die Änderung mit ihr ab.

Der erste der beiden anderen Prüfpunkte gilt doppeltem Code: Vielleicht wurde eine neue Hilfsfunktion geschrieben, obwohl es im Repository schon eine gibt, die dasselbe tut. In der Umfrage von Sonar zählen 40 % der Entwickler auch unnötigen und doppelten Code zu den negativen Folgen. Sehen Sie eine neue Hilfsfunktion, suchen Sie im Repository nach einer, die dasselbe tut.

Beim zweiten geht es darum, dass beide Hälften eines Vorgangs aus demselben Wert stammen. Prüft eine Funktion die Gültigkeit anhand einer Liste und führt den Vorgang dann mit einer anderen aus, oder liest sie die Uhrzeit an zwei Stellen zweimal, sieht jede Hälfte für sich richtig aus; der Fehler steckt in der Beziehung zwischen ihnen. Unsere eigene Regel: Der Wert wird einmal ermittelt, und beide Hälften bekommen genau diesen Wert.

Mit kleinen Pull Requests und Blick aufs Risiko lässt sich die Liste anwenden

Fünfzehn Prüfpunkte auf einen Pull Request mit tausend Zeilen anzuwenden, ist mühsam. Der Leitfaden von Google hält etwa 100 Zeilen für angemessen und 1.000 Zeilen meist für zu groß; der Reviewer darf eine Änderung allein wegen ihrer Größe ablehnen. Die Harvard-Studie fand nach der Einführung von Coding-Agenten keine signifikante Änderung der Pull-Request-Größe; der Ausgangswert lag im Schnitt bei etwa 1.168 hinzugefügten Zeilen pro Pull Request. Vom Agenten kleine Pull Requests zu verlangen, die genau eine Sache erledigen, ist der erste Schritt des Reviews.

Auch in einem kleinen Pull Request verdient nicht jede Datei dieselbe Aufmerksamkeit. Die JetBrains-Studie schlägt vor, die Dateien nach Risiko einzuteilen, bevor Sie eine einzige Zeile lesen.

Einen Teil der Liste können Sie einem Tool überlassen, einen anderen nicht:

• Überlassen Sie es dem Tool. Build, Tests, Linter, statische Analyse, Suche nach Zugangsdaten, Prüfung von Abhängigkeiten und Lizenzen.
• Das Tool weist darauf hin, Sie entscheiden. Widerspruch zwischen Kommentar und Code, verschluckter Fehler, leerer Test, Zeile gegen die Regeldatei. Ob das Gefundene wirklich ein Fehler ist, entscheidet, wer den Kontext kennt.
• Das bleibt bei Ihnen. Ob die Änderung das richtige Problem löst, ob der Entwurf zum Repository passt, und die Entscheidung über den Merge.

diffox steht auf der zweiten dieser drei Stufen. Es lässt den Pull Request von spezialisierten Agenten lesen, von denen jeder nach genau einer Sache sucht; vier Punkte der Liste erscheinen in den Kommentaren unter den Namen von vier Agenten: Broken Promise Agent für einen Kommentar, der sagt, was der Code nicht tut, Silent Failure Agent für einen verschluckten Fehler, Empty Test Agent für einen Test, der besteht, egal was der Code tut, und House Rules Agent für eine Zeile, die gegen Ihre Regeldatei verstößt. diffox blockiert keinen Merge; die Entscheidung über den Merge trifft Ihr Team (wie es funktioniert, erklärt ein eigener Beitrag).