KI-Code: Review wird zum Engpass

Warum mehr Code weniger Auslieferung bedeutet

KI-Werkzeuge werden mit der Zahl der geschriebenen Zeilen verkauft. Ein Entwicklungsteam wird an der Zahl der ausgelieferten Änderungen gemessen. Zwischen beiden liegt ein Schritt, der in den letzten zwei Jahren keine zusätzliche Kapazität bekommen hat: die Freigabe.

Der Weg dorthin läuft über den Pull Request, also einen Änderungsvorschlag, den eine zweite Person prüfen und freigeben muss. LinearB hat für den Benchmarks-Report 2026 über 8 Millionen solcher Änderungen aus mehr als 4.800 Organisationen ausgewertet. Zwei Befunde beschreiben das Problem fast vollständig. KI-gestützte Änderungen sind bei den größeren Vorschlägen rund zweieinhalbmal so umfangreich wie Änderungen ohne KI, gut 400 gegenüber 157 Zeilen. Und sie warten etwa fünfmal so lang darauf, dass überhaupt jemand mit dem Prüfen beginnt, gut 1.000 Minuten gegenüber rund 200 (LinearB, Dev Interrupted). Bei Änderungen, die ein Agent selbstständig erstellt hat, nennt LinearB den Faktor 5,3.

Beide Effekte verstärken sich. Wer bisher 157 Zeilen lesen musste, bekommt jetzt das Zweieinhalbfache und bekommt es später. Die Arbeit vor der Übernahme wächst mit der Menge und die Zeit bis zum Beginn dieser Arbeit wächst ebenfalls. Das ist eine Warteschlange, die von allein nicht mehr kürzer wird.

Der dritte Befund macht daraus eine Bilanz. LinearB misst den Anteil der Änderungen, die innerhalb von 30 Tagen übernommen werden. Bei KI-gestützten Änderungen sind es 32,7 Prozent, bei Änderungen ohne KI 84,5 Prozent. Zwei von drei KI-gestützten Vorschlägen erreichen also innerhalb eines Monats nicht die Produktion. Der Aufwand für ihre Erzeugung ist trotzdem angefallen, der Aufwand für ihre Prüfung ebenfalls und der Autor hat den Zusammenhang inzwischen vergessen.

Der Kern in einem Satz

Wer die Schreibkapazität verdoppelt und die Freigabekapazität unverändert lässt, bekommt keine schnellere Auslieferung, sondern eine längere Warteschlange und mehr ungeprüfte Änderungen in Produktion.

Wo die Zeit tatsächlich verloren geht

Der AI Engineering Report 2026 von Faros AI misst nicht die Größe der Änderungen, sondern die Dauer der Schritte dazwischen. Grundlage sind zwei Jahre Daten von rund 22.000 Entwicklern in mehr als 4.000 Teams. Verglichen werden je Organisation die Phasen mit der niedrigsten und der höchsten KI-Nutzung.

Die mediane Zeit, die eine Änderung im Review verbringt, steigt dabei um mehr als 440 Prozent. Der Engpass ist also nicht nur, dass niemand anfängt. Das Prüfen selbst dauert länger, weil größere und dichter gepackte Änderungen mehr Zusammenhang verlangen, den die Prüfenden nicht mehr aus dem Schreiben mitbringen.

Der Durchsatz steigt dabei wirklich. Faros misst mehr abgeschlossene Aufgaben je Entwickler, aber auch größere Änderungen, die über deutlich mehr Stellen im Code verteilt sind. Genau diese Streuung macht ein Review teuer. Sie zerstört die Annahme, dass sich eine Änderung an einer Stelle prüfen lässt.

Die Warteschlange wird nicht abgearbeitet, sie wird umgangen

Eine Warteschlange, die schneller wächst, als sie abgearbeitet wird, hat zwei Ausgänge. Entweder die Auslieferung stoppt oder die Prüfung entfällt. In der Praxis passiert das Zweite, weil es niemand entscheidet und deshalb auch niemand verantwortet.

Faros zählt diesen Ausgang direkt: Der Anteil der Änderungen, die ohne jede Prüfung übernommen werden, steigt um 31,3 Prozent. Der Preis dafür steht in derselben Auswertung. Die Zahl der Störungen je übernommener Änderung steigt um 243 Prozent. Die Wahrscheinlichkeit, dass eine einzelne Änderung eine Störung auslöst, hat sich also mehr als verdreifacht.

Warum Churn die ehrlichste Kennzahl ist

Die aussagekräftigste Zahl im Faros-Bericht ist keine Fehlerzahl. Es ist der Code-Churn, also der Anteil des übernommenen Codes, der kurz darauf wieder gelöscht wird. Er steigt um 861 Prozent.

Diese Kennzahl enthält keine Bewertung. Ein Bug-Ticket setzt voraus, dass jemand den Fehler gefunden und gemeldet hat. Eine Störung setzt voraus, dass etwas sichtbar ausgefallen ist. Churn setzt nichts voraus. Er zählt, wie viel von dem, was freigegeben wurde, wieder zurückgenommen werden musste. Ein Anstieg um fast das Zehnfache bedeutet, dass ein erheblicher Teil der zusätzlichen Ausgabe nie Bestand geworden ist. Die Arbeit wurde zweimal bezahlt, einmal beim Schreiben und Prüfen und einmal beim Entfernen.

Warum Review als Prüfinstrument schlechter greift als früher

Die naheliegende Reaktion lautet, mehr Menschen ins Review zu stellen. Das hilft nur, wenn Review die Fehler findet, die tatsächlich entstehen. Genau hier werden die Daten unbequem.

Veracode testet seit 2023, wie sicher generierter Code ist und veröffentlicht die Ergebnisse im Frühjahrsbericht 2026, inzwischen mit über 150 Modellen und 80 Aufgaben. Der Anteil des Codes, der überhaupt läuft, ist in diesem Zeitraum auf über 95 Prozent gestiegen. Der Anteil des Codes, der sicher ist, liegt seit zwei Jahren bei etwa 55 Prozent. In 45 Prozent der Fälle wird also eine bekannte Schwachstelle eingebaut. Nach Sprache schwankt das stark, Python 62 Prozent, Java nur 29 Prozent. Nach Art der Schwachstelle fällt es noch weiter auseinander. SQL-Injection wird in 82 Prozent der Fälle vermieden, Cross-Site-Scripting nur in 15 Prozent und Log Injection in 13 Prozent.

Diese Verteilung ist die eigentliche Nachricht. Die Fehlerklassen, die Modelle gut vermeiden, sind die mit eindeutigen Mustern. Die Klassen, die sie schlecht vermeiden, hängen vom Zusammenhang ab. Und genau diese sind auch für menschliche Prüfende die schwersten, weil sie den Aufrufpfad betreffen und nicht die einzelne Zeile.

Die Sicherheitsforschung von Apiiro zeigt dieselbe Verschiebung an echten Codebeständen großer Unternehmen. KI-gestützte Entwickler erzeugen dort drei- bis viermal so viele Änderungen und die monatlichen Sicherheitsbefunde stiegen zwischen Dezember 2024 und Juni 2025 von rund 1.000 auf über 10.000. Interessanter als die Menge ist die Art:

Fehlerklasse	Veränderung
Syntaxfehler	minus 76 Prozent
Logikfehler	minus rund 60 Prozent
Fehler im Aufbau des Systems	plus 153 Prozent
Wege zur Rechteausweitung	plus 322 Prozent

Das klassische Review ist auf die obere Hälfte dieser Tabelle ausgelegt. Ein Mensch, der einen Diff liest, findet Tippfehler, falsche Vergleiche und vergessene Prüfungen. Genau diese Fehler verschwinden. Was zunimmt, sind Fehler im Zusammenspiel, die im Diff gar nicht sichtbar sind. Mehr Augen auf denselben Diff helfen hier kaum. Was hilft, sind Prüfungen, die den Zusammenhang kennen und das sind zuerst automatisierte Prüfungen im Rahmen einer belastbaren Sicherheitsarchitektur.

Drei Vorfälle, bei denen die Freigabe fehlte, nicht der Code

Die bekanntesten Zwischenfälle der letzten Monate sind keine falsch generierten Zeilen. Es sind Lücken in der Freigabe.

Im Juli 2025 löschte ein Replit-Agent während eines ausdrücklich verhängten Änderungsstopps die Produktionsdatenbank eines Gründers und legte anschließend erfundene Datensätze an (The Register). Der Änderungsstopp war formuliert, aber nirgends erzwungen.

Im August 2025 wurden zwei Schwachstellen in der Cursor IDE veröffentlicht, CVE-2025-54135 und CVE-2025-54136. Die eine erlaubte es, über eingeschleuste Anweisungen eine Konfiguration zu schreiben und auszuführen, bevor der Nutzer zustimmen konnte. Die andere nutzte aus, dass eine einmal freigegebene Konfiguration später unbemerkt gegen Schadbefehle getauscht werden konnte (Tenable). Beides sind Lücken in Prüfung und Zustimmung, keine Fehler beim Erzeugen von Code.

Im Mai 2025 traf es Projekte, die mit Lovable erzeugt wurden. Unter CVE-2025-48757 wurde beschrieben, dass fehlende Zugriffsregeln Datenbanktabellen für jeden lesbar und beschreibbar machten. Ein Sicherheitsforscher fand das in einem erheblichen Teil der untersuchten Projekte (securityonline.info). Auch das ist kein Syntaxproblem. Es ist eine Voreinstellung, die niemand geprüft hat.

Was gegen den Stau tatsächlich wirkt

Die Gegenmaßnahmen sind unspektakulär. Sie verlagern Prüfarbeit von menschlicher Aufmerksamkeit zu Regeln, die unabhängig vom Termindruck gelten.

Prüfgatter, die nicht verhandelbar sind

Ein Gatter ist nur dann eines, wenn es blockiert. Alles, was als Warnung erscheint, wird unter Last ignoriert. Die drei Prüfungen, die sich am zuverlässigsten automatisieren lassen, sind Größenbegrenzung, statische Sicherheitsanalyse und Prüfung der eingebundenen Pakete. Die Größenbegrenzung passt in wenige Zeilen:

ZEILEN=$(git diff --numstat "origin/$BASE...HEAD" | awk '{s+=$1+$2} END {print s+0}')
test "$ZEILEN" -le 400 || { echo "Über 400 Zeilen. Aufteilen oder Ausnahme dokumentieren."; exit 1; }

Die Grenze von 400 Zeilen orientiert sich an den großen KI-gestützten Änderungen aus dem LinearB-Datensatz. Sie ist kein Naturgesetz, sondern eine Festlegung mit klarem Zweck. Sie zwingt große Änderungen zurück in die Größenordnung, in der Änderungen ohne KI ohnehin liegen. Entscheidend ist die Ausnahmeregel. Sie muss existieren, sie muss dokumentiert werden und sie muss auswertbar sein. Ein Gatter, das man ohne Spur umgehen kann, ist eine Warnung.

Prüftiefe nach Risiko statt gleichmäßiger Aufmerksamkeit

Der teuerste Fehler im Umgang mit der Warteschlange ist, alle Änderungen gleich zu behandeln. Bei doppeltem Volumen bedeutet gleiche Behandlung halbierte Prüftiefe, auch für Änderungen an Anmeldung, Abrechnung und Datenbankstruktur. Eine Einstufung nach Risiko kehrt das um. Sie nimmt Tiefe dort weg, wo wenig auf dem Spiel steht und gibt sie dorthin, wo viel auf dem Spiel steht.

Risiko	Beispiele	Prüftiefe und Frist
Hoch	Anmeldung, Abrechnung, Datenbankänderungen, neue Pakete, Agent als Autor	Zwei Prüfende, davon eine Person aus dem Kernteam, Beginn binnen vier Stunden
Mittel	Alles andere mit Logik	Eine prüfende Person, Beginn binnen acht Stunden
Niedrig	Übersetzungen, generierte Dateien, Texte	Automatische Gatter genügen

Die letzte Zeile ist die heikelste und zugleich die wichtigste. Es gibt Änderungen, die ohne menschliche Prüfung durchlaufen dürfen. Der Unterschied zwischen 31 Prozent mehr ungeprüften Übernahmen und einer Regel, die genau benennt, welche Klasse ungeprüft durchlaufen darf, ist der ganze Punkt. Im ersten Fall entscheidet der Termindruck, im zweiten eine überprüfbare Festlegung. Diese Liste gehört eng gehalten und regelmäßig geprüft.

Fristen, die einen Adressaten haben

Eine Frist ohne benannte Zuständigkeit ist eine Bitte. Drei Festlegungen machen daraus eine Regel: Wer ist diese Woche für die Aufnahme zuständig, was passiert beim Überschreiten der Frist und wo wird die Überschreitung sichtbar. Eine Änderung, die die Frist reißt, muss eskalieren, nicht altern.

Die Wirkung lässt sich an derselben Kennzahl messen, die den Stau zeigt. Wenn die Zeit bis zum ersten Blick sinkt und die Zeit im Review gleich bleibt, wirkt die Regel. Wenn beide sinken, wurde die Prüftiefe reduziert. Diese Unterscheidung braucht laufende Auswertung der Lieferkennzahlen, nicht den Quartalsbericht. Deshalb gehört ein Monitoring der Lieferkennzahlen genauso zur Ausstattung wie das Monitoring der Produktion.

Kleine Änderungen erzwingen, statt sie zu empfehlen

Von allen Maßnahmen hat die Größenbegrenzung das beste Verhältnis von Aufwand zu Wirkung, weil sie an beiden Enden ansetzt. Eine kleine Änderung wird schneller aufgenommen, weil sie weniger Zeit im Kalender braucht. Sie wird gründlicher geprüft, weil sie in ein Arbeitsgedächtnis passt. Und sie ist billiger zurückzunehmen, wenn sie falsch war.

Die Umsetzung ist überwiegend Werkzeugarbeit: gestapelte Branches, damit Aufteilen nicht bestraft wird, Feature-Flags, damit unfertige Teile übernommen werden können und eine Vorlage, die den Umfang vor dem Öffnen sichtbar macht. Die Kette aus Gattern, Einstufung, Eskalation und Benachrichtigung ist ein klassischer Fall für durchgängige Automatisierung, weil sie sonst an der einen Person hängt, die daran denkt.

Der eigentliche Maßstab: Wer wartet das in drei Jahren?

Alle bisherigen Zahlen messen kurze Zeiträume. Die teurere Frage stellt sich später. Kann jemand, der heute nicht am Projekt beteiligt ist, diesen Code in drei Jahren ändern, ohne ihn neu zu schreiben?

Diese Frage hat eine unangenehme Vorgeschichte. In der METR-Studie vom Juli 2025 bearbeiteten 16 erfahrene Open-Source-Entwickler 246 echte Aufgaben. Mit KI-Werkzeugen brauchten sie 19 Prozent länger, schätzten sich hinterher aber 20 Prozent schneller ein. METR hat Anfang 2026 nachgelegt und hält es für wahrscheinlich, dass die Beschleunigung inzwischen real ist. Was bleibt, ist die Lücke zwischen gefühlter und tatsächlicher Geschwindigkeit. Wer sich schneller fühlt, prüft weniger.

Der DORA-Bericht 2025 liefert das Gegenstück auf Organisationsebene. 90 Prozent der Befragten nutzen KI, im Median zwei Stunden am Tag. Der Durchsatz profitiert inzwischen, die Stabilität der Auslieferung weiterhin nicht. Und das Vertrauen in die Ausgaben ist verhalten. 30 Prozent vertrauen ihnen wenig oder gar nicht, nur 24 Prozent stark.

Übergabefähigkeit ist deshalb keine Stilfrage. Sie ist der Grund, warum Prüftiefe nicht verhandelbar ist. Ein Review ist nicht nur eine Fehlersuche. Es ist der Moment, in dem eine zweite Person die Verantwortung überhaupt übernehmen kann. Fällt er weg, entsteht ein Bestand, den formal alle besitzen und faktisch niemand kennt. Genau hier unterscheidet sich Software, die man betreibt, von Software, die man erträgt.

Die Frist, die im September dazukommt

Auf diesen Bestand trifft in gut zwei Monaten eine gesetzliche Frist. Der Cyber Resilience Act, die EU-Verordnung für Produkte mit digitalen Elementen, ist seit Dezember 2024 in Kraft. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden, die Frühwarnung binnen 24 Stunden. Die übrigen Pflichten gelten erst ab Dezember 2027. Was das für dich bedeutet, steht im Beitrag zur Meldepflicht ab September.

Die Reihenfolge ist der springende Punkt. Die Meldepflicht kommt zuerst, die Bauanforderungen später. Sie trifft auf Codebestände, deren Prüftiefe nachweislich sinkt und verlangt eine Antwort in Stunden auf die Frage, ob diese Schwachstelle in etwas steckt, das du ausgeliefert hast. Ein Team, das die Herkunft einer Änderung nicht mehr nachvollziehen kann, weil sie ungeprüft übernommen wurde, beantwortet diese Frage nicht in 24 Stunden.

Was du diese Woche prüfen kannst

Die Daten aus 2026 sagen nicht, dass KI-gestützte Entwicklung nicht funktioniert. Sie sagen, dass mehr Kapazität vor einem Engpass den Engpass sichtbar macht, statt ihn zu lösen. Wie stark dich das trifft, hängt von deinem Ausgangszustand ab. Drei Fragen zeigen es dir:

Wie groß sind eure Änderungen im Schnitt und wie lange warten sie, bis jemand mit dem Prüfen beginnt? Wenn du das nicht ohne Suchen sagen kannst, fehlt die Messung.
Welche Änderungen dürfen bei euch ohne Prüfung übernommen werden? Wenn die Antwort lautet, das entscheidet der Einzelfall, entscheidet in Wahrheit der Termindruck.
Wer ist diese Woche dafür zuständig, dass Änderungen aufgenommen werden und was passiert, wenn die Frist reißt?

Drei Festlegungen ändern das und alle drei sind eine Frage von Tagen: ein blockierendes Größenlimit mit dokumentierter Ausnahme, eine Einstufung nach Risiko vor dem ersten menschlichen Blick und eine Frist mit benanntem Adressaten. Wenn du wissen willst, wie das in einer bestehenden Auslieferungsstrecke konkret aussieht, sprich mit uns.

Quellen

Hinweis zur Quellenlage

Der vollständige LinearB-Bericht ist registrierungspflichtig. Die Werte zu Größe, Wartezeit und Übernahmequote stammen aus den frei zugänglichen LinearB-Seiten und dem verlinkten Podcast. Alle Faros-Werte sind Veränderungen zwischen den Phasen mit niedrigster und höchster KI-Nutzung innerhalb derselben Organisation, keine absoluten Fehlerquoten.

Dein Team schreibt mehr Code, als es freigeben kann. Der Engpass sitzt jetzt im Review.

Kernaussagen