Dein Team schreibt mehr Code, als es freigeben kann. Der Engpass ist von der Tastatur ins Review gewandert.

Warum mehr Code weniger Auslieferung bedeutet

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

LinearB hat für den Benchmarks-Report 2026 über 8,1 Millionen Pull Requests aus 4.800 Engineering-Teams in 42 Ländern ausgewertet. Zwei Befunde daraus beschreiben das Problem fast vollständig. Erstens: KI-gestützte Pull Requests sind im 75. Perzentil 2,6-mal größer als PRs ohne KI, 408 gegenüber 157 Zeilen Code. Zweitens: Agentische Pull Requests warten 5,3-mal länger darauf, dass ein Reviewer sie überhaupt aufnimmt, 1.055 gegenüber 201 Minuten (LinearB, Auswertung der Einzelwerte).

Diese beiden Effekte multiplizieren sich, statt sich auszugleichen. Ein Reviewer, der bisher 157 Zeilen zu lesen hatte, bekommt jetzt das Zweieinhalbfache, und er bekommt es später. Die Arbeit, die vor dem Merge zu leisten ist, wächst also mit der Menge, während die Zeit bis zum Beginn dieser Arbeit ebenfalls wächst. Das ist die Definition einer Warteschlange, die nicht konvergiert.

Der dritte Befund macht daraus eine Bilanz. LinearB führt für 2026 die Acceptance Rate als Kennzahl ein, den Anteil der binnen 30 Tagen gemergten Pull Requests. Bei KI-gestützten PRs liegt sie bei 32,7 Prozent, bei PRs ohne KI bei 84,5 Prozent (LinearB). Zwei von drei KI-gestützten Pull Requests erreichen die Produktion also nicht innerhalb eines Monats. Der Aufwand für ihre Erzeugung ist trotzdem angefallen, der Aufwand für ihre Prüfung ebenfalls, der Kontext der Autoren ist inzwischen kalt, und der Branch driftet.

Wo die Zeit tatsächlich verloren geht

Der AI Engineering Report 2026 von Faros AI misst nicht die Größe der PRs, sondern die Dauer der Abschnitte dazwischen. Das Ergebnis ist ein Stau, der sich über die gesamte Prüfstrecke ausdehnt.

Wichtig ist die Reihenfolge dieser Zahlen. Die Wartezeit bis zum ersten Blick wächst am wenigsten, die Zeit im Review selbst am stärksten, und die Gesamtstrecke von Commit bis Produktion wächst noch einmal deutlich darüber hinaus. Der Engpass ist also nicht nur, dass niemand anfängt. Der Engpass ist, dass das Prüfen selbst länger dauert, weil größere und dichter gepackte Änderungen mehr Kontext verlangen, den die Prüfenden nicht mehr aus dem Schreiben mitbringen.

Der Durchsatz steigt dabei real. Faros misst plus 33,7 Prozent Aufgaben je Entwickler und plus 66,2 Prozent abgeschlossene Epics je Entwickler. Auch die Streuung nimmt zu: plus 51,3 Prozent PR-Größe, plus 59,7 Prozent Dateien je PR und plus 149,9 Prozent berührte Dateien je Entwickler und Monat. Ein Team produziert also nicht nur mehr Änderungen, sondern verteilt sie auch über deutlich mehr Stellen der Codebasis. Genau diese Streuung ist es, die ein Review teuer macht, denn sie zerstört die Annahme, dass eine Änderung lokal überprüfbar ist.

Die Warteschlange wird nicht abgearbeitet, sie wird umgangen

Eine Warteschlange, die schneller wächst als sie abgearbeitet wird, hat zwei mögliche 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 misst diesen Ausgang direkt: plus 31,3 Prozent Pull Requests, die ohne jede Prüfung gemergt werden. Das ist keine Vermutung über Kultur, das ist eine Zählung. Und der Preis dafür steht in derselben Auswertung: plus 242,7 Prozent Incidents je PR. Faros ordnet das so ein, dass sich die Wahrscheinlichkeit eines Incidents je gemergtem Pull Request mehr als verdreifacht hat. Dazu kommen plus 57,9 Prozent monatliche Incidents und plus 54 Prozent Bugs je Entwickler, gegenüber plus 9 Prozent im Vorgängerbericht. Der berichtete Anstieg ist damit sechsmal so groß wie ein Berichtsjahr zuvor.

Warum Churn die ehrlichste Kennzahl ist

Die aussagekräftigste Zahl im Faros-Bericht ist keine Fehlerzahl, sondern plus 861 Prozent Code-Churn. Definiert ist Churn dort als Verhältnis gelöschter zu hinzugefügten Zeilen bei gemergtem Code je Quartal. Übersetzt: Code, der es durch die Freigabe geschafft hat, wird kurz darauf wieder entfernt.

Das ist deshalb die ehrlichste Kennzahl, weil sie keine Bewertung enthält. Ein Bug-Ticket setzt voraus, dass jemand den Fehler gefunden und gemeldet hat. Ein Incident setzt voraus, dass etwas sichtbar ausgefallen ist. Churn setzt nichts voraus. Er zählt schlicht, wie viel von dem, was freigegeben wurde, wieder zurückgenommen werden musste. Ein Faktor von fast zehn bedeutet, dass ein erheblicher Teil der zusätzlichen Ausgabe nie stabiler Bestand geworden ist. Die Arbeit ist zweimal bezahlt worden: einmal beim Schreiben und Prüfen, 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 das ist der Punkt, an dem die Daten unbequem werden.

Veracode testet seit 2023 die Sicherheit generierten Codes und veröffentlicht die Ergebnisse im Frühjahrsbericht 2026, getestet an über 150 Modellen und 80 Coding-Aufgaben. Die syntaktische Korrektheit ist in diesem Zeitraum von rund 50 auf 95 Prozent gestiegen. Die Sicherheits-Bestehensquote verharrt seit zwei Jahren zwischen 45 und 55 Prozent und liegt im Frühjahr 2026 unverändert bei 55 Prozent. Das heißt: In 45 Prozent der Fälle wird eine bekannte Schwachstelle eingebaut. Die Streuung nach Sprache ist erheblich, Python 62 Prozent, C# 58 Prozent, JavaScript 57 Prozent, Java nur 29 Prozent. Nach Schwachstellenklasse fällt sie noch weiter auseinander: SQL-Injection wird in 82 Prozent der Fälle korrekt vermieden, Cross-Site-Scripting nach CWE-80 nur in 15 Prozent und Log Injection nach CWE-117 in 13 Prozent.

Diese Verteilung ist kein Detail, sie ist die eigentliche Nachricht. Die Klassen, die Modelle gut abdecken, sind die, für die es seit zwanzig Jahren eindeutige Muster gibt. Die Klassen, die sie schlecht abdecken, sind die kontextabhängigen. Und genau diese sind auch für menschliche Prüfende die schwersten, weil sie den Aufrufpfad und nicht die Zeile betreffen.

Die Sicherheitsforschung von Apiiro zeigt dieselbe Verschiebung an echten Repositories. Untersucht wurden Zehntausende Repositories bei Fortune-50-Unternehmen. KI-gestützte Entwickler erzeugen dort drei- bis viermal so viele Commits, und die monatlichen Sicherheitsbefunde erreichten im Juni 2025 über 10.000, das Zehnfache des Standes von Dezember 2024. Interessanter als die Menge ist die Art:

Der klassische Review-Prozess ist auf die obere Hälfte dieser Tabelle kalibriert. Ein Mensch, der einen Diff liest, findet zuverlässig Tippfehler, falsche Vergleichsoperatoren und vergessene Nullprüfungen. Genau diese Fehlerklassen verschwinden. Was zunimmt, sind Rechteausweitungspfade und Designfehler, also Eigenschaften, die im Diff überhaupt nicht sichtbar sind, weil sie sich erst aus dem Zusammenspiel mit dem übrigen System ergeben. Mehr Augen auf denselben Diff erhöhen die Trefferquote 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 Halluzinationen im Sinne falsch generierter Zeilen. Es sind Lücken in der Freigabestrecke.

Im Juli 2025 löschte ein Replit-Agent während eines ausdrücklich verhängten Code-Freeze die Produktionsdatenbank von SaaStr-Gründer Jason Lemkin und legte anschließend eine Datenbank mit rund 4.000 erfundenen Personendatensätzen an. Replit sprach hinterher von einem “katastrophalen Fehlurteil” (The Register). Der Code-Freeze war formuliert, aber er war nirgends erzwungen.

Im August 2025 wurden zwei Schwachstellen in der Cursor IDE veröffentlicht. CVE-2025-54135, genannt CurXecute, CVSSv3 8,5, gefunden von AIM Security, erlaubte über indirekte Prompt Injection das Schreiben und Ausführen einer MCP-Konfiguration, bevor der Nutzer überhaupt zustimmen konnte. CVE-2025-54136, genannt MCPoison, CVSSv3 7,2, gefunden von Check Point, nutzte aus, dass eine einmal freigegebene MCP-Konfiguration später unbemerkt gegen Schadbefehle getauscht werden konnte (Tenable). Beides sind Prüf- und Zustimmungslücken, keine Codegenerierungsfehler.

Im Mai 2025 traf es die generierten Projekte von Lovable. CVE-2025-48757, CVSS 9,3: Unzureichende Row-Level-Security-Policies machten Datenbanktabellen für unauthentifizierte Anfragen lesbar und beschreibbar. Der Sicherheitsforscher Matt Palmer fand 303 betroffene Endpunkte in 170 von 1.645 analysierten Projekten, also rund 10,3 Prozent (securityonline.info). Auch das ist kein Syntaxproblem. Es ist eine Standardeinstellung, die niemand freigegeben und niemand geprüft hat.

Was gegen den Stau tatsächlich wirkt

Die Gegenmaßnahmen sind unspektakulär und sie greifen alle am selben Punkt an: Sie verlagern Prüfarbeit von menschlicher Aufmerksamkeit zu Regeln, die unabhängig von 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 Abhängigkeitsprüfung.

# .github/workflows/merge-gate.yml (Auszug)
name: merge-gate
on: [pull_request]

jobs:
  size-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Diff-Größe begrenzen
        run: |
          ZEILEN=$(git diff --numstat "origin/${{ github.base_ref }}...HEAD" \
            -- . ':(exclude)**/*.lock' ':(exclude)**/generated/**' \
            | awk '{s+=$1+$2} END {print s+0}')
          echo "Diff umfasst $ZEILEN Zeilen"
          test "$ZEILEN" -le 400 || {
            echo "Über 400 Zeilen. Aufteilen oder Ausnahme dokumentieren."
            exit 1
          }

  required-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run lint && npm test
      - name: Statische Sicherheitsanalyse
        run: semgrep --config p/owasp-top-ten --error
      - name: Abhängigkeiten prüfen
        run: npm audit --audit-level=high

Die Grenze von 400 Zeilen ist bewusst am 75. Perzentil der KI-gestützten PRs aus dem LinearB-Datensatz orientiert. Sie ist kein Naturgesetz, sondern eine Festlegung mit klarem Zweck: Sie zwingt große Änderungen zurück in die Größenordnung, in der PRs 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.

Risikobasierte Triage statt gleichmäßiger Aufmerksamkeit

Der teuerste Fehler im Umgang mit der Warteschlange ist, alle Pull Requests gleich zu behandeln. Bei doppeltem Volumen bedeutet gleiche Behandlung automatisch halbierte Prüftiefe, und zwar auch für die Änderungen an Authentifizierung, Abrechnung und Migrationen. Eine Triage kehrt das um: Sie nimmt Tiefe dort weg, wo wenig auf dem Spiel steht, um sie dort zu haben, wo viel auf dem Spiel steht.

KRITISCHE_PFADE = ("auth/", "billing/", "migrations/", "infra/", "policies/")

def review_pfad(pr) -> dict:
    """Legt Prüftiefe und Abholfrist fest, bevor ein Mensch den PR sieht."""
    risiko = 0
    if any(d.startswith(KRITISCHE_PFADE) for d in pr.dateien):
        risiko += 3
    if pr.zeilen > 400:
        risiko += 2
    if pr.autor_ist_agent:
        risiko += 2
    if pr.neue_pakete:
        risiko += 2
    if pr.api_bruch:
        risiko += 1

    if risiko >= 5:
        return {"tiefe": "zwei Prüfende, davon ein Codeowner",
                "abholfrist_stunden": 4, "ohne_review_mergebar": False}
    if risiko >= 2:
        return {"tiefe": "ein Prüfender, Codeowner informiert",
                "abholfrist_stunden": 8, "ohne_review_mergebar": False}
    return {"tiefe": "automatisierte Gatter genügen",
            "abholfrist_stunden": 24, "ohne_review_mergebar": True}

Der letzte Rückgabewert ist der heikelste und zugleich der wichtigste. Es gibt Änderungen, die ohne menschliche Prüfung durchlaufen dürfen, etwa reine Übersetzungsdateien oder generierte Clients. Der Unterschied zwischen plus 31,3 Prozent ungeprüft gemergter PRs und einer Regel, die genau benennt, welche Klasse ungeprüft durchlaufen darf, ist der ganze Punkt. Im ersten Fall entscheidet der Termindruck, im zweiten Fall eine überprüfbare Festlegung. Die Liste dieser Klasse gehört eng gehalten und regelmäßig geprüft.

Review-SLAs, die einen Adressaten haben

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

Der Effekt lässt sich messen, und zwar an derselben Kennzahl, die den Stau zeigt. Wenn die mediane Zeit bis zum ersten Review sinkt, während die Zeit im Review konstant bleibt, wirkt die Regel. Wenn beide sinken, wurde die Prüftiefe reduziert. Diese Unterscheidung braucht laufende Auswertung der Lieferkennzahlen und nicht den Quartalsbericht, weshalb ein Monitoring der Delivery-Metriken genauso zur Ausstattung gehört wie das Monitoring der Produktion.

Kleine Pull Requests erzwingen, statt sie zu empfehlen

Von allen Maßnahmen ist die Größenbegrenzung diejenige mit dem besten Verhältnis von Aufwand zu Wirkung, weil sie an beiden Enden gleichzeitig ansetzt. Ein kleiner PR wird schneller abgeholt, weil er weniger Kalenderblock verlangt. Er wird gründlicher geprüft, weil er in ein Arbeitsgedächtnis passt. Und er ist billiger zurückzurollen, wenn er falsch war.

Die Umsetzung ist überwiegend Werkzeugarbeit: Stacked Branches, damit Aufteilen nicht bestraft wird, Feature-Flags, damit unfertige Teile mergebar bleiben, und eine Vorlage, die den Umfang vor dem Öffnen sichtbar macht. Genau diese Kette aus Gattern, Triage, 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 und lautet, ob jemand, der heute nicht am Projekt beteiligt ist, diesen Code in drei Jahren ändern kann, ohne ihn neu zu schreiben.

Diese Frage hat eine unangenehme Vorgeschichte. Die randomisierte kontrollierte METR-Studie vom Juli 2025 ließ 16 erfahrene Open-Source-Entwickler 246 reale Aufgaben bearbeiten. Mit KI-Werkzeugen brauchten sie 19 Prozent länger, schätzten sich hinterher aber 20 Prozent schneller ein. METR kennzeichnet das Ergebnis inzwischen selbst als überholt und hat eine Fortsetzung mit Daten aus dem Frühjahr 2026 veröffentlicht. Was übertragbar bleibt, ist die Lücke zwischen wahrgenommener 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 letzten Arbeitstag. Der Durchsatz in der Auslieferung profitiert davon inzwischen, die Stabilität weiterhin nicht: KI-Adoption erhöht laut Bericht nach wie vor die Instabilität der Auslieferung. Und das Vertrauen der Nutzenden 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. Der Code, den heute niemand mehr liest, weil die Warteschlange zu lang war, ist derselbe Code, den in drei Jahren jemand ändern muss, der nie an ihm gearbeitet hat. Ein Review ist nicht nur eine Fehlersuche, sondern der Zeitpunkt, an 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 an dieser Stelle 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 regulatorische Frist. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, ist seit dem 10. Dezember 2024 in Kraft. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle an ENISA und den zuständigen CSIRT melden, die Frühwarnung binnen 24 Stunden. Die Hauptpflichten der Verordnung gelten erst ab dem 11. Dezember 2027.

Die Reihenfolge ist der springende Punkt. Die Meldepflicht kommt zuerst, die Bauanforderungen später. Sie trifft damit auf Codebestände, deren Prüftiefe nachweislich sinkt, und sie verlangt eine Antwort in Stunden auf eine Frage, die eine belastbare Freigabestrecke voraussetzt: Steckt diese Schwachstelle in etwas, das wir ausgeliefert haben. Ein Team, das die Herkunft einer Änderung nicht mehr rekonstruieren kann, weil sie ungeprüft und ohne Kontext gemergt wurde, beantwortet diese Frage nicht in 24 Stunden.

Was du diese Woche entscheidest

Die Daten aus 2026 sagen nicht, dass KI-gestützte Entwicklung nicht funktioniert. Sie sagen, dass eine Kapazitätserhöhung vor einem Engpass den Engpass sichtbar macht, statt ihn zu lösen. Wer die Schreibkapazität verdoppelt, ohne die Freigabekapazität anzufassen, kauft sich mehr Ausschuss, längere Wartezeiten und eine höhere Incident-Wahrscheinlichkeit je ausgelieferter Änderung.

Drei Festlegungen ändern das, und alle drei sind eine Frage von Tagen, nicht von Quartalen. Erstens ein blockierendes Größenlimit auf Pull Requests, mit dokumentierter Ausnahme. Zweitens eine Triage-Regel, die vor dem menschlichen Blick festlegt, wie tief geprüft wird und bis wann. Drittens eine Abholfrist mit benanntem Adressaten und sichtbarer Eskalation.

Was danach kommt, ist Ausbau. Was davor liegt, ist eine Warteschlange, die weiter wächst. Wenn du wissen willst, wie diese drei Festlegungen in einer bestehenden Auslieferungsstrecke konkret aussehen, sprich mit uns.

Quellen

• LinearB: 2026 Benchmarks Roundtable, Datensatzumfang
• LinearB: Software Engineering Benchmarks Report
• LinearB, Dev Interrupted: 2026 Benchmarks, AI PR Merge Rate
• Larridin: Auswertung der LinearB-Einzelwerte zum Review-Engpass
• Faros AI: AI Engineering Report 2026, Volltext-PDF
• Faros AI: Takeaways zum AI Acceleration Whiplash
• Veracode: GenAI Code Security, Frühjahr 2026
• Veracode: GenAI Code Security Report, Oktober 2025
• Google DORA: State of AI-assisted Software Development 2025
• METR: Randomisierte Studie zu KI-Werkzeugen bei erfahrenen Entwicklern, Juli 2025
• Apiiro: 4x Velocity, 10x Vulnerabilities
• Kommission: Cyber Resilience Act
• EUR-Lex: Verordnung (EU) 2024/2847
• The Register: Replit-Agent löscht SaaStr-Produktionsdatenbank
• Tenable: CVE-2025-54135 und CVE-2025-54136 in Cursor
• securityonline.info: CVE-2025-48757, Row-Level-Security in Lovable-Projekten