Mehr KI-Code, mehr Prüfarbeit: Was sich am Pull Request ändern muss

Stellen Sie sich eine neue Kollegin vor, die unglaublich schnell arbeitet. Jeder Pull Request ist in zwei Minuten fertig, und müde wird sie nie.

Sie würden sie einstellen. Am ersten Tag würden Sie ihr trotzdem keinen Zugriff auf die Zahlungsinfrastruktur geben, und ihre 50-Dateien-PRs würden Sie auch in Woche zwei nicht durchwinken, ohne genau hinzusehen.

Mit KI-Agenten statt Menschen passiert in vielen Engineering-Teams genau das. Die Velocity-Dashboards sehen besser aus denn je. Gleichzeitig wachsen die Wartezeiten in der QA und die Zahl der Incidents. Beides gleichzeitig ernst zu nehmen fällt schwer.

KI hat einen Teil der Arbeit beschleunigt, nämlich das Schreiben von Code. Prüfung, Freigabe und Betrieb wachsen nicht automatisch mit. Ob es danach im Review staut, in der QA oder erst im Betrieb, muss jedes Team an seinem eigenen Ablauf messen. Der Pull Request ist der Kontrollpunkt, an dem es am ehesten eingreifen kann.

Kurz gefasst: KI beschleunigt die Codeproduktion, Review, QA und Betrieb wachsen nicht von selbst mit. Wer mehr KI-Code zuverlässig ausliefern will, staffelt Prüfung und Freigabe nach Risiko, lässt automatisierte Reviews erst nach einem Vergleich mit menschlichen Entscheidungen allein freigeben und misst Durchsatz, Fehler sowie Nacharbeit gemeinsam. Kleine, verständliche Änderungen und klare Verantwortung zählen dabei mehr als PR-Zahlen.

Wer den Review-Engpass im Kontext der gesamten Agent-Einführung sehen will, findet im Überblick zu Coding Agents im Entwicklerteam den breiteren Rahmen.

Mehr Arbeit erreicht die Produktion, die Prüfung hält nicht Schritt

Eine breite Datengrundlage zum Systemverhalten liefert die Telemetrie von Faros AI. Der Bericht „The Speed Trap“ (Ausgabe Q3 2026) wertet zwölf Monate von rund 22.000 Entwicklern in 4.000 Teams aus, allesamt in Organisationen, die KI schon intensiv nutzen.

Laut der Zusammenfassung vom 18. September 2026 steigt die Deployment-Frequenz, und der Aufgabendurchsatz bleibt hoch. Faros nennt die Pipeline „unblocked, but leaky“, also frei, aber undicht. Die undichten Stellen sind deutlich: Die Verweildauer in der QA liegt 300,6 Prozent höher, laut Faros die stärkste Verschlechterung unter den großen Fluss- und Effizienzkennzahlen, und auch die Zeit im Review bleibt stark erhöht. Die durchschnittliche PR-Größe liegt 71,8 Prozent höher. Das Verhältnis von Incidents zu Pull Requests steigt um 14,5 Prozent, die monatliche Zahl der Incidents dagegen um 125,4 Prozent. Die erste Kennzahl setzt Incidents ins Verhältnis zur Zahl der Änderungen, die zweite beschreibt, was im Betrieb insgesamt ankommt, und für die Betriebsverantwortlichen zählt im Grunde genommen die zweite.

Der Vorgängerbericht Acceleration Whiplash vom April 2026 hat anders gemessen: Er vergleicht über zwei Jahre innerhalb jeder Organisation die Phasen niedrigster und höchster KI-Nutzung. In den Phasen hoher Nutzung lag die mediane Zeit im Review 441,5 Prozent höher, und 31,3 Prozent mehr Pull Requests wurden gemergt, ohne dass ein Mensch oder ein Werkzeug sie geprüft hatte. Beide Berichte zeigen Zusammenhänge, keine Ursachen.

Eine Beobachtungsstudie aus einem einzelnen Unternehmen zeigt dieselbe Verschiebung aus der Nähe. Der Preprint arXiv:2607.01904 vom 2. Juli 2026 verfolgt 802 Entwickler und 196.212 Pull Requests eines mittelgroßen B2B-Softwareunternehmens von Januar 2024 bis April 2026. Nach einer unternehmensweiten KI-Vorgabe stieg der Durchsatz pro Kopf auf das 2,09-Fache, und die Last pro Reviewer hat sich ungefähr verdoppelt. Der Anteil der PRs mit einem automatisierten Review stieg von etwa 19 auf 84 Prozent, der Anteil mit einem menschlich geschriebenen Review-Kommentar fiel von etwa 39 auf 21 Prozent. Merge- und Revert-Raten blieben stabil, die Autoren nennen diese Raten allerdings selbst grobe, kurzfristige Qualitätsindikatoren. Welchen Beitrag die automatisierten Reviews dazu geleistet haben, bleibt offen.

Im Alltag sieht das unspektakulär aus. Pull Requests mit Agentenarbeit warten auf Reviewer, die in Meetings sitzen, ein Ticket liegt seit Tagen in der QA, und die Nachbesprechung eines Incidents aus der Vorwoche steht noch aus. Der Code ist geschrieben, die Entscheidung bleibt liegen.

Individuelle Geschwindigkeit ist eine andere Frage als Teamleistung

Eine der meistzitierten Zahlen dieser Debatte kam im Juli 2025 vom Forschungsinstitut METR. 16 erfahrene Open-Source-Maintainer arbeiteten an 246 Aufgaben in ihren eigenen, reifen Repositories, und für jede Aufgabe wurde zufällig festgelegt, ob KI-Unterstützung erlaubt war. Erledigt war eine Aufgabe erst, wenn der Entwickler überzeugt war, dass sie den Review besteht, einschließlich Stil, Tests und Dokumentation. Die Entwickler schätzten sich mit KI rund 20 Prozent schneller ein, gemessen waren sie 19 Prozent langsamer. Das Ergebnis ist eine Momentaufnahme der Werkzeuge von Anfang 2025, METR hat das Studiendesign inzwischen umgestellt.

Für die Teamleistung ist die Frage, ob ein einzelner Entwickler eine Aufgabe mit KI schneller erledigt, zu eng gefasst. Die Faros-Zahlen oben beantworten eine andere: was passiert, wenn viele Entwickler gleichzeitig schneller Code erzeugen, als Review, QA und Betrieb ihn aufnehmen können.

Schnelleres Schreiben verkürzt nur einen Abschnitt

Gene Amdahl hat das Prinzip schon 1967 beschrieben: Wird nur ein Teil einer Arbeit schneller, begrenzen die unveränderten Teile den Gesamtgewinn.

Ein Rechenbeispiel, kein Branchenwert: Angenommen, das Schreiben von Code beansprucht 30 von insgesamt 100 Stunden. Wird dieser Teil doppelt so schnell erledigt, sinkt die Gesamtzeit auf 85 Stunden. Das sind 15 Prozent weniger Zeit, denn die übrigen 70 Stunden für Spezifikation, Review, Tests, Integration und Betrieb bleiben, wie sie sind.

Die Rechnung setzt eine gleichbleibende Arbeitsmenge voraus. Mit KI kommt ein zweiter Effekt hinzu: Es entsteht mehr Arbeit. Bei mehr und größeren Pull Requests müssen Review, QA und Betrieb zusätzlich mehr Volumen bewältigen.

Wie sich Engpässe in Entwicklungsteams verschieben, wenn ein Abschnitt schneller wird, hat Frank Westphal in Wenn sich der Engpass verschiebt schon für eine frühere Generation deutscher Teams beschrieben. Die Lektion wird regelmäßig wiederentdeckt.

Vertrauen hängt an der Prüfbarkeit

Zum Volumen kommt die Frage, wie viel Arbeit jeder einzelne PR im Review macht.

CodeRabbit, selbst Anbieter eines KI-Review-Werkzeugs, hat im Dezember 2025 470 Pull Requests ausgewertet, 320 davon mit KI mitgeschrieben und 150 rein menschlich. Mit der eigenen Fehlertaxonomie fand das Werkzeug in den KI-mitgeschriebenen PRs im Schnitt 10,83 Review-Befunde, in den menschlichen 6,45. Das sind Befunde eines Review-Werkzeugs, keine bestätigten Produktionsfehler. Für die Review-Last zählt die Zahl trotzdem, denn jeden Befund muss jemand lesen und entscheiden.

Vertrauen in KI-Ausgaben ist oft an ihre Prüfbarkeit gebunden. In der am 6. Oktober 2026 veröffentlichten Stack-Overflow-Umfrage 2026 wählen 48 Prozent der Antwortenden die Aussage, dass sie KI vertrauen, wenn sie das Ergebnis leicht überprüfen können. Nur 6,6 Prozent vertrauen ihr für viele Aufgaben einschließlich wichtiger Arbeitsentscheidungen. Gleichzeitig nutzen 40,5 Prozent KI schon für die gemeinsame Kategorie aus Code-Reviews, Pull Requests und Designentscheidungen. Die Umfrage beschreibt Nutzung und Einstellungen, keine gemessene Review-Qualität.

Fast richtig ist teuer. Ein Vorschlag, der plausibel aussieht und an einer Stelle danebenliegt, zwingt den Reviewer, die Domänenlogik selbst nachzubauen, also genau die Arbeit, die ihm der Vorschlag hätte abnehmen sollen.

Anthropic, selbst Anbieter von KI-Coding-Werkzeugen, hat im Januar 2026 in einer randomisierten Studie untersucht, wie KI-Unterstützung den Aufbau neuer Programmierkenntnisse beeinflusst. 52 überwiegend als Junior eingestufte Entwickler sollten die ihnen unbekannte Python-Bibliothek Trio lernen, die eine Gruppe mit KI-Unterstützung, die andere ohne. Im anschließenden Verständnistest erreichte die KI-Gruppe im Schnitt 50 Prozent, die Vergleichsgruppe 67 Prozent. In der Auswertung der Bildschirmaufzeichnungen gingen manche Nutzungsmuster mit deutlich besseren Ergebnissen einher als andere, nur waren diese Muster nicht randomisiert und die Gruppen mit zwei bis sieben Personen klein.

Beim Erlernen einer unbekannten Technik reicht es also nicht, funktionierenden Code zu erzeugen. Der Autor muss die Änderung, ihre Grenzen und ihre Fehlerfälle auch erklären können, sonst fehlt im Review das Gegenüber, das weiß, was es abgegeben hat. Warum erfahrene Entwickler deshalb skeptisch bleiben, beschreibt der Beitrag zur Senior-Skepsis.

Behandeln Sie KI-generierten Code also wie den Pull Request einer sehr schnellen Kollegin, der Sie noch nicht vertrauen: freundlich, aber gründlich. Vertrauensvorschuss ja, die Prüfung bleibt Pflicht.

Was Werkzeuge im Review übernehmen können

Eine zusätzliche Lizenz ersetzt keine klare Verantwortung. Aber geeignete Werkzeuge können Teile der Prüfung übernehmen. Entscheidend ist, welche Änderungen sie prüfen dürfen, welche Nachweise sie liefern müssen und wann ein Mensch entscheidet. Zwei aktuelle Beispiele (Stand: 12. Oktober 2026) zeigen, wohin die Anbieter gehen.

GitHub hat Copilot Code Review am 18. September 2026 überarbeitet. Der Übersichtskommentar zeigt seither unter anderem die verwendete Prüftiefe. Seit dem 2. Oktober lässt sich ein solcher Review auch über die REST- und die GraphQL-API anfordern, mit Prüftiefe je Anfrage. Damit wird der automatisierte Review zu einem Pipeline-Schritt, den ein Team gezielt für bestimmte Änderungsklassen auslösen kann. Eine formale Freigabe ist er standardmäßig nicht: Dass ein Copilot-Review die vorgeschriebene Zahl an Freigaben erfüllt, ist eine eigene, gesondert einzuschaltende Funktion, die sich noch in der Public Preview befindet. Review, Freigabe und Merge bleiben also drei getrennte Schritte.

Cursor setzt später an. Laut der Ankündigung vom 23. September 2026 schreibt Rollouts vor dem Merge einen Überwachungsplan mit den erkannten Risiken und den erwarteten Effekten der Änderung. Nach dem Deployment vergleicht es die Signale aus diesem Plan mit dem Stand vor dem Deployment. Bei einer Regression nennt es die verdächtige Änderung und, je nach Konfiguration, pausiert einen schrittweisen Rollout oder bereitet einen Revert-PR vor, der auf Freigabe wartet.

Beides sind verfügbare Funktionen, kein Wirksamkeitsnachweis. Ob ein Team damit schneller oder sicherer liefert, zeigt erst die eigene Messung.

Was Sie jetzt ändern können

Der erste Schritt ist eine Inventur: Wo stapeln sich PRs, und wo wartet Arbeit in der QA? Wer reviewt? Wie groß sind die Änderungen, und welche berühren kritische Pfade? Aus den Antworten ergeben sich die folgenden Korrekturen.

Vor dem Agentenlauf klären, was im PR stehen muss

Die Entlastung des Reviews beginnt, bevor der Agent die erste Zeile schreibt. Ein PR, der Ziel und Grenzen nicht nennt, zwingt den Reviewer, beides aus dem Diff zu rekonstruieren. Eine PR-Vorlage für Agentenarbeit braucht fünf Felder: das Ziel der Änderung, die betroffene Architekturentscheidung, nachprüfbare Akzeptanzkriterien, die Testergebnisse und den Rücknahmeweg. Wie Architekturentscheidungen so in den Agentenkontext gelangen, dass der Agent sie vor dem Schreiben kennt, beschreibt der Beitrag zu Architecture Decision Records.

Mit Background Agents verschärft sich das, denn wer mehrere Agenten parallel losschickt, bekommt mehrere PRs gleichzeitig zur Abnahme. Sobald sich die Abnahme staut, hilft weniger gleichzeitig offene Arbeit mehr als ein weiterer Agent. Was vor dem Freischalten solcher Agenten zu klären ist, steht im Beitrag zu Background und Cloud Agents.

Review-Kapazität gehört in die Planung

Wenn der Code-Ausstoß steigt, gehört Kapazität für Review und QA in die Planung wie jede andere Arbeit. Ein Teil des KI-generierten Codes ist risikoarm und darf durch automatische Gates laufen. Ein anderer Teil berührt kritische Systeme und braucht benannte Reviewer. Welche Änderung in welche Kategorie fällt, ist eine Architekturentscheidung, und in vielen Organisationen fällt sie heute implizit und unter Zeitdruck.

Risk Lanes als prüfbare Freigaberegel

Zwei oder drei Spuren reichen. Risikoarme Änderungen laufen durch statische Analyse, Typprüfung, Tests und gegebenenfalls einen automatisierten Review, mit minimaler menschlicher Beteiligung. Kritische Pfade (Auth, Zahlung, regulierte Module) bekommen benannte Reviewer, kleinere PR-Limits und keinen agentengesteuerten Merge. Für regulierte Branchen gelten zusätzliche Anforderungen, die der Beitrag zu BaFin und MaRisk beschreibt.

Pauschale Zuordnungen sind dabei gefährlich. Interne Werkzeuge und Tests sind nicht automatisch risikoarm: Ein Admin-Tool mit Produktionsrechten gehört eher in die kritische Spur als manches Kunden-Feature.

Zalando hat am 14. August 2026 ein konkretes Modell für risikobasierte Freigaben beschrieben. Ein Bot stuft jeden Pull Request nach seinem Auslieferungsrisiko als niedrig, mittel oder hoch ein und genehmigt die als risikoarm eingestuften, rund ein Drittel des Aufkommens. Der Autor entscheidet anschließend selbst über den Merge. Die Regeln wurden aus eigenen Produktionsvorfällen abgeleitet und sind eng auf den eigenen Tech-Stack, die Deployment-Manifeste und Konfigurationsdateien zugeschnitten. Übertragbar ist deshalb vor allem das Vorgehen, nicht die Freigabequote. Die 20 bis 40 Prozent kürzere PR-Durchlaufzeit, die Zalando nennt, ist eine eigene Angabe ohne Kontrollgruppe.

Das Architekturteam legt die Regeln fest, sortiert aber nicht jede Änderung selbst ein. Sonst entsteht genau die Warteschlange, die die Spuren abbauen sollen. Der Ablauf hat vier Schritte:

1. Architektur, Security und die Service-Verantwortlichen legen gemeinsam Kriterien und Ausnahmen für jede Spur fest.
2. Autor oder Werkzeug stufen die Änderung nach diesen Regeln ein. Unklare Fälle gehen an eine benannte verantwortliche Person.
3. Vor dem Merge wird die Einstufung erneut geprüft, sobald sich der Umfang geändert hat. Ein PR, der als Textänderung begann und inzwischen eine Berechtigungsprüfung anfasst, wechselt die Spur. Die Freigabe gilt nur für den geprüften Stand, neue Änderungen durchlaufen die vorgeschriebenen Prüfungen erneut.
4. Bevor eine Änderungsklasse ohne menschliche Freigabe durchgeht, läuft die Automatisierung eine Zeit lang mit, und das Team vergleicht ihre Vorschläge mit den menschlichen Entscheidungen. Die menschlichen Entscheidungen sind dabei eine Referenz, aber kein fehlerfreier Maßstab, deshalb gehören bekannte Fehlerfälle, Testergebnisse und später entdeckte Defekte mit in den Vergleich.

Genau diesen vierten Schritt beschreibt Semgrep am 9. Oktober 2026 als laufenden Pilot. Fachleute markieren echte PRs als Testfälle, der Agent prüft im Schattenbetrieb neben den menschlichen Reviewern, und gemessen werden falsche Freigaben, Abdeckung, Kosten und Geschwindigkeit. Wo die Ergebnisse halten, wird er Repository für Repository eingeschaltet, und jedes Repository legt seine Risikostufe selbst fest. Ergebnisse will Semgrep Anfang 2027 veröffentlichen.

Eine Regel fehlt in vielen Freigabeprozessen: Ein fehlgeschlagener automatischer Review ist kein bestandener. Seit dem 8. Oktober 2026 bietet GitHub für Copilot Code Review zwei Abrechnungsoptionen an. Wird über das Kontingent des einzelnen Mitglieds abgerechnet, schlägt der Review fehl, sobald dieses Kontingent ausgeschöpft ist. Wer automatisierte Reviews in eine Spur einbaut, braucht deshalb eine eindeutige Festlegung: Fehlt das vorgeschriebene Prüfergebnis, bleibt der Merge gesperrt oder geht an einen menschlichen Reviewer.

Kleine PRs, besonders für Agenten

Laut Speed Trap ist die durchschnittliche PR-Größe um 71,8 Prozent gestiegen. Große PRs verlängern den Review und senken zugleich die Chance, dass jemand wirklich jede Zeile liest.

Mein Startbudget für Agenten ist bewusst klein: drei Dateien und etwa 80 geänderte Zeilen, wie ich es in The Magic Words That Make AI Code Better beschrieben habe. Das ist eine Heuristik, keine Qualitätsgrenze. Entscheidend bleibt, dass die Änderung zusammenhängend, prüfbar und rücknehmbar ist. Tests gehören zur Änderung und werden nicht ausgelagert, nur damit der PR unter dem Limit bleibt.

Durchsatz und Stabilität gemeinsam messen

DORA zählt die Deployment-Frequenz zu den Durchsatzkennzahlen, neben der Durchlaufzeit von Änderungen und der Wiederherstellungszeit nach einem fehlgeschlagenen Deployment (Failed Deployment Recovery Time), die die frühere MTTR abgelöst hat. Dazu kommen zwei Stabilitätskennzahlen, Change Failure Rate und Deployment Rework Rate. Ein Team braucht beide Seiten. Für KI-gestützte Entwicklung lohnt sich ein kleines Messmodell mit vier Fragen:

Hängen Sie jede fehlgeschlagene Änderung an den auslösenden PR, den betroffenen Service und die Review-Spur. Nach vier Wochen gibt das erste Hinweise darauf, welche Art von KI-Änderung zu viel Prüfung bekommt und welche zu wenig. Für seltene, schwere Fehler reicht dieser Zeitraum nicht. Und Wartezeit ist nicht dasselbe wie aktive Arbeitszeit der Reviewer: Ein PR, der zwei Tage wartet, hat vielleicht 20 Minuten Review gekostet.

Schnell ist nicht gleich produktiv

Wer Velocity-Dashboards grün meldet, während die Wartezeit in der QA und die Zahl der Incidents steigen, misst nur die einfache Hälfte der Pipeline.

Die sehr schnelle Kollegin bleibt im Team. Sie bekommt einen kleineren Änderungsumfang, benannte Reviewer auf den kritischen Pfaden und Werkzeuge, die ihre Arbeit vorprüfen, deren Urteil aber erst nach einem Vergleich mit menschlichen Entscheidungen zählt. Bevor ihr Code ins Zahlungssystem fließt, sieht trotzdem ein Mensch hin, der weiß, was er freigibt. So führt man Menschen, und inzwischen eben auch Werkzeuge.

Wenn Sie den Engpass in Ihrer Organisation vermessen wollen, bevor er sich in der Incident-Kurve selbst vermisst: In einer 60-minütigen Bestandsaufnahme sehen wir uns Ihre vorhandenen Kennzahlen und typische Pull Requests an. Daraus ergibt sich, welche Engpässe eine genauere Untersuchung lohnen. Sprechen Sie mich an.

Häufige Fragen

Verschwindet der Review-Engpass, wenn ein Team mehr Reviewer einsetzt?

Das hängt davon ab, wo die Arbeit wartet. Liegen PRs vor allem in der Warteschlange vor dem ersten Review und kennen die zusätzlichen Reviewer die betroffenen Systeme, verkürzt mehr Kapazität die Wartezeit spürbar. Wächst die Codeproduktion dagegen schneller als jede realistische Aufstockung oder staut es eigentlich in QA oder Betrieb, erhöhen zusätzliche Reviewer vor allem die Kosten. Dann helfen Risk Lanes, kleinere PRs und weniger gleichzeitig offene Arbeit mehr.

Können automatisierte Code-Reviews den menschlichen Review ersetzen?

Für klar definierte Änderungsklassen können sie Teile davon übernehmen, etwa bekannte Fehlermuster oder risikoarme Änderungen nach festen Regeln. Ob das im eigenen Team funktioniert, zeigt ein Vergleich im Schattenbetrieb: automatische Vorschläge laufen neben menschlichen Entscheidungen, und das Team zählt falsche Freigaben. Auf kritischen Pfaden entscheidet weiterhin eine benannte Person. Ein fehlgeschlagener oder fehlender Prüflauf darf nie als bestanden gelten.

Sind diese Zahlen auf deutsche Engineering-Teams übertragbar?

Als Anlass zur Prüfung im eigenen Team ja, als Vorhersage nicht. Faros wertet Telemetrie von Organisationen aus, die Engineering-Metriken systematisch erheben, und die Berichte zeigen Zusammenhänge, keine Kausalität. Der Mechanismus ist aber nicht regional: Die Codeproduktion wird schneller, während Review, QA und Betriebsverantwortung oft gleich bleiben.

Quellen

• Faros AI: The Speed Trap · AI Engineering Report Q3 2026 (Berichtsausgabe Q3 2026, ohne Veröffentlichungsdatum, abgerufen 12.10.2026)
• Faros AI: The Speed Trap · Takeaways (18. September 2026)
• Faros AI: Acceleration Whiplash · Takeaways (12. April 2026)
• arXiv: Preprint 2607.01904, Beobachtungsstudie in einem Unternehmen (2. Juli 2026)
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Juli 2025)
• METR: We are Changing our Developer Productivity Experiment Design (Februar 2026)
• CodeRabbit: State of AI vs. Human Code Generation Report (17. Dezember 2025)
• Stack Overflow: The results of the 2026 Developer Survey are here (6. Oktober 2026)
• Stack Overflow: Developer Survey 2026 · AI, Datenseite (abgerufen 12.10.2026)
• Anthropic: AI Assistance and Coding Skills (29. Januar 2026)
• GitHub Changelog: Copilot code review: an improved review experience (18. September 2026)
• GitHub Changelog: Copilot code review: API support and new default effort level (2. Oktober 2026)
• GitHub Docs: About GitHub Copilot code review (abgerufen 12.10.2026)
• GitHub Changelog: Copilot code review: new organization billing options and controls (8. Oktober 2026)
• Cursor: Rollouts and Security Reviewer (23. September 2026)
• Zalando Engineering: Agentic Engineering at Zalando: A Snapshot (14. August 2026)
• Semgrep: The end is nigh for code review (9. Oktober 2026)
• DORA: DORA Metrics Guide (abgerufen 12.10.2026)
• Frank Westphal: Wenn sich der Engpass verschiebt