KI-Code-Review ist der neue Engpass: Umgang mit einer Flut agentengeschriebener PRs

KI-generierte Pull Requests sind billig herzustellen und teuer zu reviewen, und dieses Ungleichgewicht hat den Engpass in der Softwareentwicklung vom Schreiben des Codes zum Lesen verschoben. Agentengeschriebene PRs sind größer, warten länger auf einen Reviewer und werden seltener gemergt als PRs von Hand. Mehr Agents machen die Queue länger, nicht kürzer.

Dieser Beitrag schaut, was die Daten zeigen, warum das Review zum Engpass wurde und was zu ändern ist: PR-Größenbudgets, gestapelte Pull Requests, KI-Code-Review als erster Durchgang, Agents, die auf ihre eigenen Review-Kommentare antworten, und eine klare Regel für die Verantwortung. Am Ende steht eine Policy-Vorlage, die ein Team übernehmen kann.

Was sagen die Daten über KI-generierte Pull Requests?

Zwei große Datensätze sagen dasselbe: KI-gestützte Pull Requests sind größer, und mehr davon bleiben unreviewt oder werden nie gemergt. Die individuelle Leistung steigt; die Auslieferung auf Teamebene folgt nicht.

LinearBs Analyse von 8,1 Millionen Pull Requests (Mai 2026) über 4.800 Teams in 42 Ländern ist die detaillierteste. Faros AIs AI Productivity Paradox Report (Juli 2025), basierend auf mehr als 10.000 Entwicklern in 1.255 Teams, fand ein Jahr zuvor dieselbe Form.

Lies das als Signale, nicht als Gesetze. Beide sind Herstellerstudien über ihre eigenen Kunden, und „AI-assisted“ wird in jeder Studie anders klassifiziert. Ein Detail sticht bei den LinearB-Zahlen heraus: Sobald sich tatsächlich ein Reviewer an einen KI-generierten PR macht, ist das Review nicht langsamer. Explodiert ist die Wartezeit, bevor ihn jemand aufnimmt. Reviewer meiden große, unbekannte Diffs.

Warum das Code-Review zum Engpass wurde

Review ist der Engpass, weil einen Diff zu erzeugen inzwischen Minuten kostet, ihn zu verstehen einen Menschen aber noch immer genauso viel Aufmerksamkeit kostet wie früher. Jede Zeile, die ein Agent schreibt, ist eine Zeile, die jemand lesen muss, und die Lesezeit wächst mit der Größe und mit der Unvertrautheit des Codes.

Googles Engineering Practices setzen die Zielgröße einer Änderung dort an, wo „100 Zeilen meist eine vernünftige Größe für einen CL sind und 1000 Zeilen meist zu groß“, und nennen den Grund in einem Satz: „Es ist für einen Reviewer leichter, mehrere Male fünf Minuten für kleine CLs zu finden, als einen Block von 30 Minuten für einen großen CL freizuhalten.“ Ein Agent, der in zehn Minuten einen 600-zeiligen PR produziert, hat gerade einen 30-Minuten-Block im Tag eines anderen eingeplant.

PR-Größenbudgets und gestapelte Pull Requests

Die wirksamste Gegenmaßnahme ist, Agents kleinere Pull Requests produzieren zu lassen und sie zu stapeln, wenn eine Änderung für einen einzelnen zu groß ist. Die Größe ist die eine Variable, die du vollständig kontrollierst, denn der Agent teilt die Arbeit genau so fein, wie du es ihm sagst.

Ein Größenbudget ist eine Zeile in den Agenten-Regeln plus ein CI-Check: Beispielsweise jeden PR oberhalb einiger hundert geänderter Zeilen fehlschlagen lassen oder labeln, mit Ausnahme von Lockfiles und generiertem Code. Googles Leitfaden listet die Aufteilungsstrategien auf, die funktionieren: abhängige Änderungen stapeln, nach Dateien aufteilen, die verschiedene Reviewer brauchen, horizontal nach Schicht oder vertikal nach Feature aufteilen und Refactorings „in einem separaten CL von Feature-Änderungen oder Bugfixes“ halten.

Gestapelte Pull Requests machen das praktisch. GitHub hat gestapelte PRs am 30. Juli 2026 in die öffentliche Vorschau gebracht: „eine geordnete Reihe von Pull Requests, die jeweils fokussierte Schichten deiner Änderung darstellen“, wobei jeder PR auf den darunter liegenden zielt. Reviewer sehen eine Stack-Karte und reviewen immer den Diff einer Schicht. Ein Merge des obersten fertigen PRs holt ihn und jede darunterliegende, noch nicht gemergte Schicht in einem Vorgang; ein Merge einer tieferen Schicht lässt die oberen offen und rebased sie automatisch. Die CLI kommt als Erweiterung, und GitHub erwähnt einen gh-stack-Skill für Coding-Agenten:

gh extension install github/gh-stack

Für Agents ändert Stacking die Anweisung von „implementiere das Feature“ zu „implementiere das Feature als Stack: zuerst das Schema, dann der Service, dann die UI, je ein PR, jeder für sich grün“. Das ist leichter zu reviewen und leichter zurückzunehmen.

KI-Review als erster Durchgang, Menschen für die Absicht

Lass einen KI-Reviewer und die deterministischen Checks den ersten Durchgang machen, damit der menschliche Reviewer seine Aufmerksamkeit nur für Absicht, Design und Risiko braucht. Lass den KI-Durchgang den menschlichen nicht ersetzen.

Die Werkzeuge unterstützen beide Verwendungen, die Entscheidung liegt also bei dir. GitHubs Copilot code review docs sagen, dass Reviews über Rulesets automatisch ausgelöst werden können, dass Copilots Approval-Bewertung standardmäßig nicht auf die erforderlichen Approvals angerechnet wird und dass Copilot bei aktivierten „Copilot approvals“ „eine genehmigende Review einreichen kann, die die Required-Approval-Regel deines Repositories erfüllt“. Dieselbe Seite warnt: „Copilot ist nicht garantiert, alle Probleme oder Fehler in einem Pull Request zu finden.“ Meine Empfehlung: Lass KI-Approvals für alles aus, was in Produktion geht.

Der erste Durchgang funktioniert am besten, wenn er geschichtet ist: zuerst deterministische Sensoren (Tests, Typen, Linter, Mutationstests auf dem Diff, wie in Harness Engineering beschrieben), dann ein KI-Review für semantische Probleme, dann der Mensch. Wenn ein Mensch den PR öffnet, sollten die offenen Fragen „ist das die richtige Änderung?“ und „was könnte das brechen?“ sein, nicht „hast du die Tests gelaufen?“.

Die Schleife schließen: Agents, die auf Review-Kommentare antworten

Wenn ein Mensch doch kommentiert, sollte der Agent, der den PR geschrieben hat, die Folgearbeit machen: jeden Kommentar beheben, den Fix belegen und im Thread antworten. Der zweite Durchgang des Reviewers dauert dann Minuten.

Mein Review-Schleifen-Skill funktioniert so. Er sammelt alle Review-Kommentare des PRs über die GitHub API ein, behebt sie und markiert jeden Thread als behoben, teilweise, offen oder nicht zutreffend. Er lässt Tests und statische Analyse erneut laufen und wiederholt das. Nach drei Runden ohne Fortschritt hört er auf und übergibt an mich, weil ein vierter Versuch beim selben Kommentar selten besser wird. Am Ende antwortet er auf jeden Thread und nennt den Commit, der ihn erledigt hat, damit der Reviewer jede Antwort gegen einen konkreten Diff prüfen kann. Der Skill ist ausführlicher in meinem Beitrag über den Workflow meiner Coding-Agent-Skills beschrieben, und die Abbruchlogik ist ein allgemeines Muster, das in der erklärten Agentenschleife behandelt wird.

Wenn der erste KI-Durchgang viele Findings produziert, triagiere sie, bevor der Agent mit dem Beheben anfängt. Ein typisierter Classifier, der jedes Finding als „jetzt beheben“, „Backlog“ oder „braucht einen Menschen“ labelt, ist billiger und konsistenter, als ein allgemeines Modell zu fragen, „was ist wichtig“; dieser Ansatz ist in typisierten Entscheidungen für Routing und Triage beschrieben.

Abwägung: was diese Regeln kosten

Jede Regel hier kauft Review-Geschwindigkeit mit etwas anderem, und manche Teams sollten nicht alle einführen. Kenne den Preis, bevor du die Policy schreibst.

• Größenbudgets kosten Overhead. Mehr PRs bedeuten mehr CI-Läufe und mehr Kontextwechsel. Für eine einmalige Migration, die ein Codemod erzeugt, ist ein großer PR mit klarer Beschreibung leichter zu reviewen als zwanzig kleine.
• Stacks brauchen Tool-Disziplin. Ein Stack, den niemand rebased, verfällt schnell. GitHubs gestapelte PRs sind Stand September 2026 in öffentlicher Vorschau, prüfe also, was deine Merge-Queue unterstützt, bevor du dich darauf verlässt.
• KI-Review erzeugt Rauschen. Ein Reviewer-Bot mit vielen geringwertigen Kommentaren bringt die Leute dazu, ihn zu ignorieren. Stimme seine Anweisungen so ab, dass die meisten Kommentare zu einer Änderung führen, oder schalte ihn ab.
• Menschliches Review skaliert nicht linear. Wenn Agenten die Leistung verdreifachen, verdreifachen Reviewer nicht. Irgendwann lautet die richtige Antwort: weniger PRs. Erzeuge weniger und gib Agenten-Zeit stattdessen für Tests und Aufräumen aus, nicht für neue Features.

Eine Team-Policy für agentengeschriebene Pull Requests

Eine schriftliche Policy nimmt beiden Seiten das Rätselraten: den Reviewern und den Agents. Packe sie in den Contribution Guide und in die Regeldateien der Agents, damit dieselben Regeln gelten, wer oder was den PR auch öffnet.

1. Ein benannter Mensch besitzt jeden PR. Wer den Agenten um die Änderung gebeten hat, ist dafür verantwortlich, reviewt ihn zuerst und steht nach dem Merge dafür ein.
2. Größenbudget: PRs über der vereinbarten Zeilenzahl werden aufgeteilt oder gestapelt; Refactorings kommen in einen eigenen PR.
3. Nachweise in der Beschreibung: was gelaufen wurde, mit exakten Ergebnissen, und was nicht gelaufen wurde und warum.
4. Zuerst das deterministische Gate: Tests, Typen, Linter und Mutationstests auf dem Diff müssen grün sein, bevor das Review angefordert wird.
5. KI-Review ist beratend. Es kommentiert; es liefert keine erforderliche Freigabe.
6. Der Agent beantwortet seine Kommentare, mit einem Commit pro Thread, und stoppt nach drei Runden ohne Fortschritt.
7. Menschen geben alles Öffentliche oder Unumkehrbare frei: Merges in Produktions-Branches, Migrationen, Deployments.

Die PR-Vorlage, die meine Agents ausfüllen, hat fünf feste Abschnitte:

## Ticket
Link to the issue. No ticket, no PR.

## Description
What changed and why, in two or three sentences.

## Testing
Commands run and exact results. Anything not run, and why.

## How to test
Steps a reviewer can follow to see the change working.

## Deployment notes
Migrations, config, feature flags, rollback. "None" if none.

Wenn du herausfindest, wie Coding-Agenten in den Review-Prozess deines Teams passen, schau dir AI Engineering an.

Quellen

1. LinearB: What 8 million pull requests reveal about engineering productivity (Mai 2026)
2. Faros AI: The AI Productivity Paradox report (Juli 2025)
3. Google Engineering Practices: Small CLs
4. GitHub Changelog: Stacked pull requests are now in public preview (Juli 2026)
5. GitHub Docs: Copilot code review