Mehr KI-Code: Review, Freigabe und Merge neu ordnen

Im Juni 2025 forderte der CTO eines B2B-Softwareunternehmens per E-Mail, die Produktivität mit KI zu verdoppeln. Als Messlatte dienten gemergte Pull Requests pro Entwickler und Monat. Eine spätere Studie zählte 2,09-mal so viele erstellte PRs pro aktivem Entwickler. Das ist eine nahe verwandte, aber nicht identische Kennzahl. Im selben Zeitraum hat sich das PR-Aufkommen im Verhältnis zur Zahl der Reviewer ungefähr verdoppelt, und automatisierte Reviews haben die menschlichen überholt.

Die vom CTO gewählte Kennzahl zählt gemergte Änderungen. Ihren Nutzen und den Prüfaufwand bildet sie nicht ab. Wo sich diese Prüfarbeit staut, im Review, in der QA oder im Betrieb, muss jedes Team an seinem eigenen Ablauf messen. Eingreifen kann es am ehesten am Pull Request, weil sich dort in PR-basierten Abläufen Regeln vor dem Merge durchsetzen lassen.

Kurz gefasst: KI kann den Codeausstoß stark erhöhen. Review, QA und Betrieb wachsen nicht von selbst mit. Wer mehr KI-Code zuverlässig ausliefern will, stuft Änderungen nach Risiko ein, trennt Review, formale Freigabe und Merge, lässt automatische Freigaben nur für klar definierte, im Schattenbetrieb erprobte Änderungsklassen zu und misst Durchsatz und Stabilität gemeinsam.

Den breiteren Rahmen für die Einführung von Agenten beschreibt der Leitfaden zu Coding Agents im Entwicklerteam.

Der PR-Ausstoß stieg, die Prüfung verlagerte sich

Die Zahlen stammen aus einem Preprint vom 2. Juli 2026 von Forschern der Carnegie Mellon University, der Stanford University und einem unabhängigen Forscher. Das Unternehmen hat nur die Daten bereitgestellt. Ausgewertet wurden 802 Entwickler und 196.212 Pull Requests in 364 Repositories, von Januar 2024 bis April 2026. Pro aktivem Entwickler stieg die Zahl erstellter PRs von 21,2 vor der Vorgabe auf 44,3 im April 2026. Die Studie ist nicht randomisiert, die Autoren vergleichen gestaffelt Entwickler vor und nach ihrer KI-Einführung. Weil das Unternehmen ausgesprochen KI-freundlich ist, ohne Lizenzgrenzen und ohne Token-Budgets, werten sie ihre Ergebnisse eher als Obergrenze denn als Branchendurchschnitt.

Für diesen Artikel zählt vor allem, was mit dem Review passiert ist. Das PR-Volumen wuchs auf das 3,1-Fache, der Kreis der Reviewer nur auf das 1,5-Fache. Der Anteil der PRs mit mindestens einem menschlichen Review fiel von 89 auf 68 Prozent, der Anteil mit automatisiertem KI-Review stieg von etwa 19 auf etwa 84 Prozent. Gesunken ist vor allem der Anteil der PRs mit einem menschlichen Review-Kommentar, von etwa 39 auf etwa 21 Prozent. Freigaben ohne Kommentar blieben anteilig ungefähr konstant. Wie viel Aufmerksamkeit hinter einer einzelnen Freigabe stand, lässt sich daran nicht ablesen.

Schlechtere Merge- und Revert-Raten gingen mit dem höheren Durchsatz nicht einher. Die Autoren nennen beide Raten selbst grobe, kurzfristige Indikatoren, die Defekte, Incidents und Wartbarkeit nicht erfassen, und werten sie als Hinweis gegen einen akuten Qualitätseinbruch. Mehr KI-Code muss also nicht sofort schlechtere Ergebnisse mit sich bringen. Verändert hat sich vor allem, wer die dokumentierten Reviews abgibt. Ob damit dieselbe Prüftiefe erhalten blieb, ist eine andere Frage.

Doppelt so schnell schreiben spart im Beispiel 15 Prozent

Amdahls Gesetz, im CUDA Best Practices Guide von NVIDIA sauber hergeleitet, beschreibt den Gesamtgewinn, wenn nur ein Teil einer Arbeit schneller wird. Ein Rechenbeispiel, ausdrücklich als Annahme und nicht als Branchenwert: Das Schreiben von Code beansprucht 30 von 100 Stunden. Wird dieser Teil doppelt so schnell erledigt, sinkt die Gesamtzeit auf 85 Stunden, also um 15 Prozent. Die übrigen 70 Stunden für Spezifikation, Review, Tests, Integration und Betrieb bleiben, wie sie sind.

Die Grenze des Beispiels: Amdahl rechnet mit derselben Arbeitsmenge. Die Unternehmensstudie zeigt den anderen Effekt, nämlich mehr und größere Änderungen, die Review, QA und Betrieb zusätzlich bewältigen müssen. Wo dabei tatsächlich ein Engpass liegt, muss das Team messen.

Auf Systemebene stehen mehr Ausstoß und mehr Belastung nebeneinander

Eine breite Datengrundlage zum Verhalten ganzer Organisationen liefert Faros AI, ein Anbieter von Plattformen für Engineering-Kennzahlen. Die Ausgabe „The Speed Trap“ seines AI Engineering Report (Q3 2026) wertet die letzten zwölf Monate Telemetrie von rund 22.000 Entwicklern in 4.000 Teams aus. Sie betrachtet Organisationen, die KI schon breit nutzen und die Nutzung weiter vertiefen.

Alle folgenden Werte sind Veränderungen, keine Anteile. Faros meldet eine um 300,6 Prozent höhere Verweildauer in der QA. Die Zeit im Review bleibt laut Faros stark erhöht, eine Zahl nennt die Zusammenfassung dafür nicht. Die durchschnittliche PR-Größe liegt 71,8 Prozent höher. Für Pull Requests, die ganz ohne Review gemergt wurden, meldet Faros eine Zunahme um 76,3 Prozent. Das Verhältnis von Incidents zu Pull Requests liegt 14,5 Prozent höher, die monatliche Incident-Zahl 125,4 Prozent. Für den Betrieb zählen beide Perspektiven, dazu Schwere und Behebungsaufwand der Incidents.

Ursachen lassen sich daraus allein nicht ableiten. Auch den Befund zum agentischen Review kennzeichnet Faros als korrelativ: Teams, die intensiv mit Review-Agenten arbeiten, bekommen schneller ein erstes Review und haben eine niedrigere Change Failure Rate, ungeprüfte Merges nehmen aber auch dort zu. Faros empfiehlt deshalb zusätzlich klare Review-Anforderungen nach Risiko und Umfang.

Die Daten zeigen Belastung an mehreren Stellen. Welche davon den Durchsatz begrenzt, lässt sich aus prozentualen Veränderungen allein nicht bestimmen. Dafür braucht ein Team die tatsächlichen Durchlaufzeiten, Warteschlangen und verfügbaren Kapazitäten.

Ein methodischer Hinweis noch zu einer oft zitierten Studie, die eine andere Frage beantwortet. METR hat im Juli 2025 eine randomisierte Studie mit 16 erfahrenen Open-Source-Entwicklern veröffentlicht, die mit KI 19 Prozent länger brauchten statt der erwarteten 24 Prozent weniger. Gemessen wurde die Bearbeitungszeit einzelner Aufgaben, nicht der Teamdurchsatz. Eine Folgeerhebung lieferte Hinweise auf Beschleunigung, erlaubte wegen Auswahl- und Messproblemen aber keine belastbare Schätzung des Effekts. METR kündigte deshalb im Februar 2026 Änderungen am Studiendesign an.

Review, Freigabe und Merge sind drei getrennte Schritte

Was muss ein Team unterscheiden und festlegen, bevor es Änderungen automatisch freigeben lässt? Zuerst die Begriffe. Viele Teams sprechen vom „Review“ und meinen drei verschiedene Dinge. Wer sie vermischt, kann keine Regel für automatisierte Prüfung schreiben.

• Review ist die inhaltliche Prüfung einer Änderung mit dokumentiertem Ergebnis, durch einen Menschen oder ein Werkzeug.
• Formale Freigabe ist eine dokumentierte Zustimmung, die nach den Repository-Regeln als Freigabe zählt.
• Merge ist ein eigener Schritt mit eigener Verantwortung: Er bringt den geprüften Stand in den Zielbranch.

Die Werkzeuge trennen das längst. Laut GitHub-Dokumentation zählen Copilot-Reviews standardmäßig nicht als erforderliche Freigabe. Die Einschätzung im Übersichtskommentar, ob ein PR freigabereif wirkt, ist eben eine Einschätzung. Dass eine Copilot-Freigabe die Branch-Regel erfüllt wie die eines Kollegen, ist eine gesondert zu aktivierende Funktion, die in Repository, Organisation und Enterprise eingeschaltet sein muss und sich noch in der Public Preview befindet (Stand: Oktober 2026). Kommen nach einer solchen Freigabe neue Commits hinzu, wird sie aufgehoben.

Daraus folgt die Grundregel für jeden Freigabeprozess: Die Freigabe gilt nur für den geprüften Stand. Neue Änderungen müssen die vorgeschriebenen Prüfungen erneut durchlaufen.

Zalando zeigt die Trennung von Freigabe und Merge in der Praxis. Ein Bot gibt als risikoarm eingestufte PRs frei, über den Merge entscheidet danach der Autor.

Auch die Prüftiefe lässt sich steuern. Copilot bietet die Prüfstufen „Lite“ und „Balanced“. Seit dem 28. September 2026 ist Balanced die Voreinstellung. Ausdrücklich gewählte Lite-Einstellungen bleiben bestehen.

Dazu kommt ein Zwischenzustand, den man leicht übersieht. Fallen die Actions-Abläufe aus, auf denen die agentischen Fähigkeiten beruhen, entsteht laut Dokumentation trotzdem ein Review, nur eben mit eingeschränkten Fähigkeiten. Ein vorhandener Review-Kommentar genügt nicht. Der Lauf muss den vorgeschriebenen Stand mit dem erforderlichen Umfang und der vorgesehenen Prüftiefe abdecken. Fehlt dieser Nachweis, bleibt die automatische Freigabe gesperrt. GitHub schreibt selbst, Copilot finde nicht alle Probleme und solle durch menschliche Reviews ergänzt werden.

Was KI-Reviewer inhaltlich finden und was sie übersehen, steht im Beitrag „Wer prüft wen?“. Hier geht es um die Verfahrensfrage: wer welchen dieser drei Schritte verantwortet.

Risk Lanes: Die Einstufung folgt Regeln, nicht dem Bauchgefühl

Risk Lanes sind Spuren mit unterschiedlicher Prüftiefe. Zwei oder drei Spuren sind ein praktikabler Ausgangspunkt. Die Kriterien legen Menschen fest, die Einstufung des einzelnen PR übernehmen Autor oder Werkzeug.

Drei Spuren, je mit Review, Freigabe und Merge

In allen Spuren gelten die für den Service vorgeschriebenen automatischen Prüfungen. Die Spur bestimmt, welche zusätzliche Prüfung und Freigabe erforderlich ist.

In der niedrigen Spur kommt gegebenenfalls ein automatisierter Review hinzu. Eine automatische formale Freigabe gibt es dort nur für Änderungsklassen, die im Schattenbetrieb erprobt sind. Den Merge verantwortet der Autor.

In der Standardspur prüft ein menschlicher Reviewer, der KI-Review dient als Vorprüfung, und die formale Freigabe kommt vom Menschen.

In die kritische Spur gehören Authentifizierung, Zahlungen, Berechtigungen, regulierte Module und Datenmigrationen. Für die kritische Spur schlage ich vor: Eine fachkundige Person, die die Änderung nicht selbst eingereicht hat, prüft sie und erteilt auch die formale Freigabe. Den Merge verantwortet eine benannte Person. Die für den Service vorgeschriebenen automatischen Prüfungen bleiben Pflicht. Die PR-Limits sind kleiner, ein Agent darf nicht mergen. Welche Anforderungen in regulierten Häusern hinzukommen, beschreibt der Beitrag zu BaFin und MaRisk.

Pauschale Zuordnungen täuschen

Bequem wäre eine Zuordnung nach Repository oder Dateityp. Sie ist auch 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.

Abhängigkeiten sind der zweite blinde Fleck. Dateien wie package.json oder Lockfiles prüft Copilot laut Dokumentation gar nicht. Eine Änderung, die nur das Manifest anfasst, bekommt von diesem Werkzeug also keine Prüfung, und deshalb darf sie nicht in die niedrige Spur rutschen, bloß weil der automatische Review nichts gemeldet hat. Wie man Abhängigkeiten vor dem Merge prüft, steht im Beitrag zu SBOM und Cyber Resilience Act.

Zalando hat seine Regeln aus eigenen Produktionsvorfällen abgeleitet. Ein Tippfehler in der Konfiguration gilt dort als hohes Risiko, ein Bruch der Abwärtskompatibilität als mittleres, das einen weiteren Menschen verlangt, reine Dokumentation als niedriges. Rund ein Drittel der PRs wird als risikoarm automatisch freigegeben. Übertragbar ist das Vorgehen, nicht die Quote, denn das Regelwerk ist eng auf Zalandos eigenen Stack zugeschnitten. Bei automatisch freigegebenen PRs lag die Durchlaufzeit nach Zalandos Angaben 20 bis 40 Prozent unter dem Durchschnitt aller PRs. Ein Vorher-nachher-Vergleich ist das nicht, und risikoarme PRs dürften schon von sich aus kleiner und schneller sein.

Neu einstufen, wenn sich der Umfang ändert

Zalando stuft bei der Erstellung des PR ein und berichtet, ausdrücklich als anekdotisch, dass Entwickler ihre PRs kleiner und enger zuschneiden, um in die niedrige Spur zu kommen. Das ist der gewünschte Effekt, nur bleibt ein PR selten, wie er geöffnet wurde. Ein PR, der als Textänderung begann und inzwischen eine Berechtigungsprüfung anfasst, wechselt die Spur. Die Einstufung muss deshalb vor dem Merge erneut geprüft werden, sobald sich der Umfang geändert hat, und das folgt direkt aus der Grundregel: Eine Einstufung gilt wie eine Freigabe nur für den Stand, den sie bewertet hat.

Kleine PRs sind Voraussetzung für die niedrige Spur

Neben der Zeit für den Entwurf zählt, wie aufwendig sich die Änderung prüfen lässt. Faros meldet eine um 71,8 Prozent höhere durchschnittliche PR-Größe. Zalando beobachtet seit dem zweiten Quartal 2025 Wachstum in den Größenklassen von 500 bis 1.000 und von 1.000 bis 2.000 Zeilen. Teams mit Problemen vereinbaren dort feste Größenlimits, eine harte Durchsetzung per Pre-Commit-Hook ist laut Zalando weniger beliebt. Zalando beschreibt, dass sehr große agentengenerierte PRs Reviewer abschrecken und die Auslieferung bremsen, bis Teams ihre Arbeitsweise anpassen.

Auch die Zahl der Befunde pro PR spielt für den Prüfaufwand eine Rolle. CodeRabbit, selbst Anbieter eines KI-Review-Werkzeugs, hat im Dezember 2025 470 Open-Source-PRs ausgewertet. Die als KI-mitgeschrieben eingestuften PRs kamen nach der eigenen Taxonomie auf durchschnittlich 10,83 Befunde, die als menschlich eingestuften auf 6,45. Ob die Vergleichsgruppe tatsächlich ohne KI gearbeitet hatte, konnte CodeRabbit nicht sicherstellen. Das sind Review-Befunde, keine bestätigten Produktionsfehler, aber jeden davon muss jemand lesen und bewerten.

In der Stack-Overflow-Umfrage 2026, einer Selbstauskunft ohne repräsentative Stichprobe, sagen 48 Prozent der Antwortenden auf die Vertrauensfrage, sie vertrauen KI, wenn sie das Ergebnis leicht prüfen können. Auch für wichtige Arbeitsentscheidungen vertrauen ihr 6,6 Prozent. Für viele Antwortende ist Prüfbarkeit eine Voraussetzung für Vertrauen. Praktisch heißt das: Änderungen klein halten und verständlich beschreiben.

Mein Startbudget für Agenten liegt bei drei Dateien und etwa 80 geänderten Zeilen, wie in The Magic Words That Make AI Code Better beschrieben. Das ist eine Heuristik, keine Qualitätsgrenze. Die Änderung muss zusammenhängend, prüfbar und rücknehmbar sein, und die Tests gehören in denselben PR.

Eine randomisierte Studie von Anthropic vom Januar 2026, einem Anbieter von KI-Coding-Werkzeugen, betrifft den Autor, nicht den Reviewer. 52 überwiegend als Junior eingestufte Entwickler bauten mit einer ihnen unbekannten Python-Bibliothek zwei Features, eine Gruppe mit KI-Assistent, die andere ohne. Im Test direkt danach erreichte die KI-Gruppe 50 Prozent, die Vergleichsgruppe 67 Prozent.

Für mich folgt daraus eine praktische Regel: Wer eine Änderung einreicht, muss sie erklären können.

Eine PR-Vorlage für Agentenarbeit nennt deshalb das Ziel der Änderung, die betroffene Architekturentscheidung, nachprüfbare Akzeptanzkriterien, die Testergebnisse, Grenzen und bekannte Fehlerfälle sowie den Rücknahmeweg. Wie Architekturentscheidungen vorab in den Agentenkontext kommen, beschreibt der Beitrag zu Architecture Decision Records. Wer mehrere Agenten parallel losschickt, bekommt mehrere PRs gleichzeitig zur Abnahme, mehr dazu im Beitrag zu Background und Cloud Agents.

Wer die Regeln setzt und wer die Entscheidungen verantwortet

Architektur, Security und Service-Verantwortliche setzen die Regeln gemeinsam. Das Architekturteam sortiert aber nicht jede Änderung selbst ein. Sonst entsteht genau die Warteschlange, die die Spuren abbauen sollen. Jede der folgenden Entscheidungen braucht eine benannte Rolle:

Änderungen an Risikoregeln, Prüfanweisungen und Freigabekonfigurationen brauchen eine unabhängige menschliche Freigabe. Ein PR darf die Voraussetzungen für seine automatische Freigabe nicht selbst absenken. Das ist keine Pedanterie: Copilot liest Repository-Anweisungen, Agent-Anweisungen und Skills laut Dokumentation aus dem Änderungsbranch, nicht aus dem Zielbranch. Ein PR, der die Prüfanweisungen lockert, wird also schon nach den gelockerten Anweisungen geprüft.

Eine fehlgeschlagene Prüfung ist keine bestandene. Das klingt selbstverständlich, bei Copilot muss man es aber ausdrücklich regeln. Seit dem 8. Oktober 2026 kann eine Organisation festlegen, wie Copilot Code Review für Mitglieder mit Lizenz abgerechnet wird. In der Standardeinstellung läuft das über das Kontingent des einzelnen Mitglieds, und ist es erschöpft, schlägt der Review fehl. Alternativ rechnet die Organisation selbst ab. Wer einen automatisierten Review in eine Spur einbaut, braucht deshalb eine eindeutige Festlegung: Fehlt das vorgeschriebene Prüfergebnis, bleibt der Merge gesperrt oder der PR geht an einen menschlichen Reviewer. Ob ein fehlgeschlagener Review im PR als Fehlstatus erscheint oder still entfällt, beschreibt der Changelog nicht. Das sollte jedes Team in der eigenen Ruleset-Konfiguration ausprobieren, bevor es sich darauf verlässt (Stand: Oktober 2026).

Bleibt die Kapazität. Wenn der Ausstoß steigt, gehört Zeit für Review und QA in die Planung wie jede andere Arbeit. Wer sie dort nicht ausweist, findet sie später als Wartezeit in der Messung wieder.

Schattenbetrieb: Der Mensch ist Referenz, kein fehlerfreier Maßstab

Bevor eine Änderungsklasse ohne menschliche Freigabe durchläuft, prüft die Automatisierung eine Zeit lang parallel mit, ohne dass ihr Urteil zählt. Verglichen wird mit dem, was die menschlichen Reviewer entschieden haben. Fehlerfrei sind aber auch menschliche Reviewer nicht. Das Team prüft deshalb auch bekannte Fehlerfälle, Testergebnisse und später entdeckte Defekte.

Der Ablauf hat drei Schritte. Zuerst hält das Team fest, was die Automatik wissen muss: Servicegrenzen, Abhängigkeitsregeln, kritische Bestandteile und die Auslöser, bei denen immer ein Mensch übernimmt. Dann vergleicht es die Entscheidungen und untersucht jede mögliche falsche Freigabe ebenso wie jede möglicherweise unnötige Eskalation. Erst danach schaltet es frei, Änderungsklasse für Änderungsklasse und Repository für Repository.

Vor dem Start legt das Team fest, welche Ergebnisse für die automatische Freigabe ausreichen und wann sie wieder ausgesetzt wird. Wesentliche Änderungen am Review-System oder an den Risikoregeln erfordern eine erneute Erprobung. Auch nach der Freischaltung bleiben Stichproben und die Auswertung später entdeckter Fehler nötig.

Semgrep, Anbieter von KI-gestützter Code-Security, beschreibt dieses Vorgehen am 9. Oktober 2026 als laufenden Pilot auf den eigenen PRs. Fachleute markieren echte PRs als Testfälle, und der Agent läuft im Schattenbetrieb neben den menschlichen Reviewern. Gemessen werden falsche Freigaben, Abdeckung, Kosten und Geschwindigkeit. Ergebnisse gibt es noch keine, Semgrep kündigt sie für Anfang 2027 an. Dass künftig weniger als ein Prozent der PRs einen Menschen brauchen soll, hat Semgrep sich als Ziel gesetzt. Gemessen ist davon noch nichts.

Die Prüfmenge enthält bekannte Fehlerfälle und repräsentative korrekte Änderungen. Ein Teil davon bleibt bei der Anpassung der Prüfanweisungen unbenutzt und dient anschließend als unabhängiger Test. Wie man Prüfer selbst prüft, steht im Beitrag zum Verifier-Harness, und wie man ein Entscheidungsmodell vor dem Einsatz kalibriert, im Beitrag zu Entscheidungsmodellen im Code-Review.

Wartezeit und Prüfaufwand gehören getrennt gemessen

Ob es sich im Review, in der QA oder im Betrieb staut, zeigt erst eine Messung, die Durchsatz und Stabilität gemeinsam erfasst. DORA führt nach dem Seitenstand vom 5. Januar 2026 fünf Kennzahlen. Zum Durchsatz zählen Change Lead Time, Deployment Frequency und die Failed Deployment Recovery Time, also die Wiederherstellungszeit nach einem fehlgeschlagenen Deployment, die die frühere MTTR abgelöst hat. Zur Instabilität zählen Change Fail Rate und Deployment Rework Rate. Gedacht sind sie pro Service, nicht als Mischwert über Teams, und als Hebel nennt DORA kleinere Batches. DORA beschreibt damit die Auslieferungsleistung eines Services. Um mögliche Engpässe im Review zu finden, ergänzt das Team diese Kennzahlen um Durchlaufzeiten, aktive Prüfzeit und Prüf-Abdeckung, geordnet nach vier Fragen:

Bei PRs mit vorgeschriebenem menschlichem Review misst das Team die Zeit von der Review-Bereitschaft bis zur ersten menschlichen Prüfung. Automatisierte Reviews erfasst es getrennt. In der Zeit vom ersten Review bis zum Merge stecken auch Rückfragen und Nacharbeit, sie ist also mehr als Wartezeit. Noch offene PRs bleiben über ihr Alter sichtbar.

Soweit die Ursache bekannt ist, verknüpft das Team fehlgeschlagene Änderungen mit den betroffenen Deployments, PRs, Services und Risikospuren. Ungeklärte Zuordnungen bleiben ausdrücklich offen. Wartezeit ist nicht dasselbe wie Arbeit: Ein PR, der zwei Tage wartet, kann 20 Minuten aktiven Review gekostet haben. Zusätzliche fachkundige Reviewer können Wartezeiten verkürzen, wenn dort Kapazität fehlt. Ob zugleich der Prüfaufwand pro PR sinkt, muss das Team getrennt untersuchen.

Nach vier Wochen können sich erste Muster in Wartezeiten, Befunden und Nacharbeit zeigen. Welche Prüfungen sich reduzieren lassen, muss das Team gezielt erproben. Wenige entdeckte Fehler allein sind dafür kein Beleg. Für seltene, schwere Fehler reicht dieser Zeitraum nicht. Das vollständige Kennzahlenset beschreibt der Beitrag zu DORA-Metriken für Coding Agents, hier geht es nur um die Ergänzung für den Review.

Wer mehr Code bestellt, bestellt Prüfarbeit mit

Die Unternehmensstudie zeigt, wie stark der PR-Ausstoß wachsen kann. Ob daraus zuverlässige Lieferung wird, entscheidet sich an der Einstufung, an der Trennung von Review, Freigabe und Merge, am Schattenbetrieb und an der Messung, also an Arbeit, die in keiner Zählung gemergter PRs vorkommt.

Wer mehr Code bestellt, muss auch festlegen, wie dieser Code geprüft wird. Entscheidend ist nicht, ob jeder PR denselben Ablauf durchläuft. Entscheidend ist, ob jede Änderung die für ihr Risiko nötigen Nachweise erbringt, ob jemand die Entscheidung verantwortet und ob das Team merkt, wenn seine Regeln nicht mehr greifen.

In einem Erstcheck sehen wir uns vorhandene Kennzahlen und typische Pull Requests an. Daraus ergibt sich, welche Engpässe genauer untersucht werden sollten. Ob der Erstcheck für Ihr Team passt, klären wir vorab in einem 15-minütigen Vorgespräch. Sprechen Sie mich an.

Dieser Text führt meinen Beitrag vom April zum Review-Engpass bei KI-Code mit neuen Daten und ersten Freigabemodellen aus Betrieb und Pilot weiter.

Quellen

• He, Agarwal, Denisov-Blanch, Azaletskiy, Koyejo, Vasilescu: „AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise ‚2ב Mandate“, Preprint, arXiv 2607.01904v1, 2. Juli 2026, abgerufen am 12. Oktober 2026.
• NVIDIA: CUDA C++ Best Practices Guide, Abschnitt 4.1.3.1, docs.nvidia.com, abgerufen am 12. Oktober 2026.
• Faros AI: „The Speed Trap: 8 takeaways from Faros's latest AI engineering research“, Zusammenfassung zur Ausgabe Q3 2026 des AI Engineering Report, faros.ai, veröffentlicht am 18. September 2026, abgerufen am 12. Oktober 2026.
• Vitaly Gordon (Faros AI): „The most expensive number in our new AI Engineering report“, faros.ai, 9. Oktober 2026, abgerufen am 12. Oktober 2026.
• METR: „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, metr.org, 10. Juli 2025, abgerufen am 12. Oktober 2026.
• METR: „We are Changing our Developer Productivity Experiment Design“, metr.org, 24. Februar 2026, abgerufen am 12. Oktober 2026.
• CodeRabbit: „AI vs Human Code Generation Report“, coderabbit.ai, 17. Dezember 2025, abgerufen am 12. Oktober 2026.
• Stack Overflow Developer Survey 2026, KI-Daten (Antwortzahlen je Frage) und Methodik, abgerufen am 12. Oktober 2026.
• Anthropic: „How AI assistance impacts the formation of coding skills“, anthropic.com, 29. Januar 2026, abgerufen am 12. Oktober 2026.
• GitHub Docs: „About GitHub Copilot code review“, docs.github.com, abgerufen am 12. Oktober 2026.
• GitHub Changelog: „Copilot code review: API support and new default effort level“, github.blog, 2. Oktober 2026, abgerufen am 12. Oktober 2026.
• GitHub Changelog: „Copilot code review: New organization billing options and controls“, github.blog, 8. Oktober 2026, abgerufen am 12. Oktober 2026.
• Bartosz Ocytko (Zalando): „Agentic Engineering at Zalando: a snapshot“, engineering.zalando.com, 14. August 2026, abgerufen am 12. Oktober 2026.
• Daghan Altas (Semgrep): „AI Code Review and the End of Reviewing Every Change“, semgrep.dev, 9. Oktober 2026, abgerufen am 12. Oktober 2026.
• DORA: „DORA’s software delivery performance metrics“, dora.dev, Seitenstand 5. Januar 2026 (laut Seitenfuß), abgerufen am 12. Oktober 2026.

Stand: Oktober 2026.