Review-Checkliste für KI-generierte Pull Requests

Sobald ein Team ernsthaft mit Agenten arbeitet, verschiebt sich der Engpass. Geschrieben ist der Code schnell, geprüft ist er es nicht. Pull Requests werden größer und zahlreicher, und die Reviewer stehen vor der Frage, worauf sie bei Code achten sollen, den niemand Zeile für Zeile selbst getippt hat.

Zwei aktuelle Berichte zeigen, wie deutlich sich das Volumen verändert. Anthropic schreibt, dass die Zahl der täglich gemergten Änderungen im eigenen Monorepo von rund 2.500 im Mai 2026 auf über 30.000 im September gestiegen ist. Spotify meldet laut InfoQ, dass sich die monatlich gemergten Änderungen im Jahresvergleich von etwa 8.100 auf 17.000 mehr als verdoppelt haben. Beide Berichte enden bei derselben Frage: Wie bleibt die Prüfung mit diesem Tempo Schritt?

Was KI-Pull-Requests anders macht

Bemerkenswert an Anthropics Bericht ist eine nüchterne Beobachtung: Die beteiligten Ingenieure halten Claude beim Schreiben von Code inzwischen für besser als sich selbst. Ihre wichtigste Aufgabe sei trotzdem oft gewesen, „nein” zu sagen. Agenten hätten zentrale Systemgrenzen verletzt, um ein Muster zu bedienen, das es so nie hätte geben dürfen. Ein Beispiel: Mehrere Systeme versuchten, den Merge-Zeitpunkt einer Änderung durch lineares Lesen des Commit-Logs zu ermitteln, statt das dafür vorgesehene Review-Tool zu fragen.

Der zweite Befund betrifft automatisierte Gegenprüfungen. Adversariale Reviews durch weitere Agenten seien sehr wirksam, aber manchmal kurzsichtig. In einem Fall führte ein übervorsichtiges Review dazu, dass Claude einem anderen internen Dienst misstraute und überflüssige Validierung und Komplexität einbaute. Menschen mussten gegensteuern. Das Team prüft weiterhin jede Änderung, achtet dabei aber vor allem auf die Absicht und nicht mehr auf jede einzelne Zeile.

In der Reddit-Diskussion zu diesem Bericht ergänzen Entwickler eigene Erfahrungen: ein Coding-Agent, der Prüfschritte umging, und ein QA-Agent, der Tests als bestanden meldete, die es noch gar nicht gab. Ein anderer Kommentar beschreibt die eigentliche Gefahr: Eine falsche Designentscheidung, die einmal durchrutscht, wird zum Hausstil, den spätere Sessions übernehmen und auf weitere Dienste übertragen.

Die Checkliste

Aus diesen Befunden lässt sich eine Checkliste ableiten, die bewusst auf die typischen Schwächen von Agenten-Code zielt:

Absicht: Passt die Änderung zum Ticket? Gibt es eine kurze Beschreibung, was und warum geändert wurde, die ein Mensch bestätigt hat?
Systemgrenzen: Nutzt der Code die vorgesehenen Schnittstellen, oder baut er einen Umweg um einen bestehenden Dienst herum?
Ausgetrickste Checks: Wurden Tests übersprungen, abgeschwächt oder gelöscht, Linter-Regeln deaktiviert oder Assertions so umgeschrieben, dass sie immer grün sind?
Echte Tests: Existieren die Tests, auf die sich die Beschreibung beruft, und prüfen sie das neue Verhalten statt nur den Aufruf?
Übereifer: Kommen Validierungen, Abstraktionen oder Fehlerbehandlung hinzu, die kein reales Problem lösen, sondern hypothetische?
Abhängigkeiten: Sind neue oder aktualisierte Pakete beabsichtigt und begründet?
Größe: Lässt sich der Diff in einem Durchgang verstehen, oder gehört er in mehrere Pull Requests?
Muster: Würden Sie wollen, dass diese Lösung kopiert wird? Agenten übernehmen, was im Code steht.
Rollout: Ist klar, wie die Änderung zurückgerollt wird, und wer sie überwacht?

Punkt 9 wirkt banal, ist aber durch Spotify gut belegt. Dort bestand ein automatisiertes Dependency-Upgrade alle vorhandenen Prüfungen und fiel trotzdem in Produktion aus. Spotify reagiert mit stärkeren Schutzmechanismen, mehr Rollback-Kapazität und damit, dass automatisierte Änderungen in die Arbeitszeiten der zuständigen Teams gelegt werden.

Automatisches Review als Vorfilter

Ein Agent, der den Pull Request zuerst prüft, entlastet Reviewer, ersetzt sie aber nicht. Ein Diskussionsteilnehmer beschreibt ein Setup, bei dem mehrere Review-Agenten den Diff bewusst ohne Vorabkontext prüfen, damit sie nicht die Sichtweise des schreibenden Agenten übernehmen. Die Funde landen gesammelt bei einem Menschen, der über Beheben oder Nicht-Beheben entscheidet. Dass der Hauptagent die Kontextregel gelegentlich bricht, gehört ebenfalls zu dieser Schilderung.

Anthropic geht einen Schritt weiter und lässt das eigene Review-Tool zwischen harmlosen Änderungen, etwa reinen Kommentaren, und heiklen Logikänderungen unterscheiden. So konzentriert sich menschliche Aufmerksamkeit auf die folgenreichen Stellen. Für die meisten Teams ist die einfachere Variante realistisch: Pfade oder Änderungsarten festlegen, bei denen immer ein zweiter Mensch draufschaut.

Was das für Ihr Entwicklerteam bedeutet

Wenn Agenten das Tempo erhöhen, müssen Tests, Review und Monitoring mitwachsen. Spotify fand nach eigenen Angaben keinen wesentlichen direkten Beitrag von KI-Code zu Vorfällen, stellte aber fest, dass das Änderungsvolumen einige Prüfmechanismen überholt hat, während Pull-Request-Größe und Codekomplexität steigen. Auch die DORA-Forschung von Google aus dem Jahr 2025, auf die InfoQ verweist, verbindet KI-Einsatz mit höherem Durchsatz, fand aber zugleich einen negativen Zusammenhang mit der Stabilität der Auslieferung. Als hilfreich nennt sie automatisierte Tests, Versionskontrolle und schnelle Feedbackschleifen.

Für Teams heißt das: Die Checkliste gehört als Datei ins Repository, etwa in die Pull-Request-Vorlage, und wird gepflegt wie Code. Sie funktioniert nur zusammen mit einer gemeinsamen Arbeitsweise, wie sie im Beitrag Claude Code im Team beschrieben ist. Für sicherheitsrelevante Aspekte, etwa Änderungen, die durch manipulierte Issues angestoßen wurden, lohnt der Blick auf Prompt Injection im Entwickleralltag. Den geplanten Review-Baustein finden Sie in der Modulübersicht.

Eine Checkliste ersetzt kein Urteilsvermögen, aber sie macht sichtbar, wo ein Mensch „nein” sagen muss.

Sie möchten eine Review-Checkliste, die zu Ihrem Code und Ihren Tools passt, gemeinsam erarbeiten und als Commit im Repository haben? Inhouse-Training anfragen.