Irgendwo in Ihrer Entwicklungsabteilung gibt es gerade einen Pull Request, der seit vier Tagen offen ist. 847 geänderte Zeilen in 23 Dateien. Das meiste davon stammt von einem Agenten. Der Pull Request hat zwei Approvals, beide in weniger als drei Minuten erteilt, das sieht man an den Zeitstempeln direkt in der GitHub-Timeline. Kommentiert hat niemand.
Pull Requests wurden für Code-Änderungen in menschlichem Maßstab und für menschliche Aufmerksamkeit gebaut, und KI sprengt beides. Das ist kein Prozessversagen. Der Prozess funktioniert genau so, wie er gedacht war, nur unter Bedingungen, für die er nie gedacht war.
Diese Realität steht hinter Ankit Jains aktuellem Essay in Latent.Space, „How to Kill the Code Review“. Die bewusst provokante These: von Menschen geschriebener Code ist 2025 gestorben, das menschliche Code Review stirbt 2026, und die richtige Antwort besteht darin, den menschlichen Kontrollpunkt nach vorne zu verlegen, weg vom Diff-Review Zeile für Zeile, hin zum Verfassen von Spezifikationen und Akzeptanzkriterien. Der Essay stieß auf die erwartbare Mischung aus „endlich sagt es jemand“ und „das ist gefährlich naiv“. Beide Reaktionen haben etwas für sich. Die interessantere Frage ist aber nicht, ob Code Review tot ist. Sondern ob es jemals verlässlich gelebt hat.
Zuerst ging die Rechnung nicht mehr auf
Die empirische Lage lässt wenig Spielraum. Laut den von Jain zitierten Faros-Daten (über 10.000 Entwickler in 1.255 Teams) erledigen Organisationen mit hoher KI-Nutzung 21 % mehr Aufgaben (in Engineering-Systemen erfasste Arbeitseinheiten, abgeglichen mit dem PR-Durchsatz) und mergen 98 % mehr Pull Requests, die PR-Review-Zeit steigt aber um 91 %. Lesen Sie das ruhig noch einmal: fast die doppelte Review-Last bei fast doppelt so vielen PRs.
GitHubs Octoverse-Daten von 2025 liefern den Kontext: Die Zahl der gemergten Pull Requests erreichte 2025 monatlich 43 Millionen, und GitHub weist einen großen und wachsenden Anteil dieses Codes als KI-gestützt aus. Der Engpass hat sich verschoben. In den ersten dreißig Jahren des modernen Software Engineering war das Schreiben von Code der Engpass. Jetzt ist es alles andere: Validierung, Review, Verständnis, Vertrauen.
Das Problem der kognitiven Last beim Menschen ist real und akut. Ein KI-gestützter Entwickler reicht einen sauber aussehenden PR mit 500 Zeilen ein: vernünftige Variablennamen, Linter bestanden, einheitlicher Stil. Um zu prüfen, ob er tatsächlich korrekt ist, muss ein Senior Engineer aber den gesamten Logikfluss im Kopf nachbauen. Nehmen Sie etwas so Banales wie den Umgang mit Zeitzonen: KI-generierter Code liefert oft Ergebnisse, die in UTC korrekt geparst werden, an der Sommerzeitumstellung (DST) aber stillschweigend versagen oder bei mehrdeutigen Ortszeiten den falschen Offset anwenden. Der Code sieht richtig aus. Das Gehirn überfliegt ihn. Der PR wird gemergt. Technische Schulden wachsen unsichtbar, und zwar mit hohem Tempo.
Das Durchwinken ist kein neues Phänomen. Neu sind das Ausmaß und die Tarnung.
Auch vor der KI war es keine verlässliche Kontrolle
Bevor man nach einer Lösung greift, sollte man bei der Ausgangslage ehrlich sein. Code Review als nahezu universelle Praxis ist jünger, als den meisten Entwicklern bewusst ist. Jain merkt an, dass es erst um 2012 bis 2014 allgegenwärtig wurde. Es gibt kaum noch genug Veteranen, die sich daran erinnern, ohne Review ausgeliefert zu haben. Und auch nachdem es zum Standard geworden war, ließ die Wirksamkeit von Reviews rasch nach, je größer die Diffs und je dünner der Kontext wurden. Eine vielzitierte Peer-Review-Studie bei Cisco ergab, dass die Fehlererkennung stark abfällt, sobald die Prüfrate einige hundert Codezeilen pro Stunde übersteigt. Ab einer gewissen Diff-Größe kaufen Sie sich keine Fehlererkennung mehr, sondern eine Plausibilitätsprüfung.
Die soziale Mechanik half auch nicht. PRs, die liegen blieben, erzeugten Druck, sie freizugeben. Große Diffs führten zu kognitiver Überlastung. Wer zu viele Probleme ansprach, bekam den Ruf, alles aufzuhalten. Das Anreizgefälle zeigte in Richtung „sieht gut aus“ statt „ich habe etwas gefunden“.
Es gibt Kontexte, in denen Review wirklich funktioniert: kleine Diffs mit viel Kontext, Subsysteme mit klarer Zuständigkeit, in denen der Reviewer die Domäne so gut kennt wie der Autor, sicherheitskritische Pfade, in denen das Langsamerwerden der Sinn der Sache ist. Halten Sie diese Bedingungen gegen einen KI-generierten Diff mit 500 Zeilen von einem Agenten, der in einem fremden Service arbeitet, und Sie machen kein Code Review mehr. Sie führen es auf.
KI hat Code Review nicht kaputt gemacht. Sie hat seine Schwachstellen im großen Maßstab offengelegt.
Womit die Skeptiker recht haben
Der Widerspruch gegen Jains Alternativvorschlag (spezifikationsgetriebene Entwicklung als neues primäres Artefakt) ist nicht aus der Luft gegriffen. Aus den Kommentaren bei Latent.Space: „Ich glaube, wer an spezifikationsgetriebene Entwicklung glaubt, unterschätzt naiv, wie schwer es ist, eine vollständige Spezifikation zu schreiben, verglichen damit, einfach Code zu schreiben. Es hat seinen Grund, dass wir in der Mathematik Symbole mit komplexen dahinterliegenden Bedeutungen verwenden: Das Äquivalent in Worten zu schreiben ist mühsam.“
Die Geschichte der formalen Spezifikation ist ein Friedhof guter Absichten. Eine Spezifikation, die sagt „gib den Kontostand des Benutzers zurück“, sagt Ihnen nicht, was passiert, wenn der Benutzer nicht existiert, wenn zwei gleichzeitige Schreibvorgänge auf demselben Konto kollidieren oder wenn die API eines Drittanbieters mitten in der Transaktion in ein Timeout läuft. In vieler Hinsicht ist der Code die Spezifikation, denn die Randfälle stecken dort und nicht im Fließtext.
Der richtige Rahmen ist nicht die „vollständige Spezifikation“, sondern akzeptanzkriteriengetriebene Entwicklung: testbare Invarianten und Verhaltensverträge, geschrieben vor der Generierung. „Muss idempotent sein.“ „Darf OAuth-Scopes nicht erweitern.“ „Darf das Datenbankschema nicht ändern.“ „Betragsfelder müssen den Typ Money verwenden.“ Das ist eine andere Forderung als eine Wasserfall-Spezifikation, und sie passt besser zu dem, wovon erfahrene Entwickler ohnehin wissen, dass sie es prüfen müssen.
Ein paralleles Problem gibt es bei KI als Reviewer. In einem HackerNews-Thread behauptete ein Praktiker, sein KI-Reviewer habe „vielleicht 80 %“ der Bugs gefunden, die ihm wirklich wichtig waren, den nützlichen Fund aber regelmäßig unter zwanzig hochspekulativen Kommentaren niedriger Priorität begraben. Das Fehlerbild hat einen Namen: hoher Recall, niedrige Precision, also erschöpfendes Linting, das sich als Urteilsvermögen ausgibt. Ein guter menschlicher Reviewer hat Geschmack: Er lässt die neun Dinge fallen, die ihm aufgefallen sind und keine Rolle spielen, und bringt das eine zur Sprache, das zählt. KI-Reviewer neigen zur Vollständigkeit, das trainiert Entwickler darauf, das Rauschen auszublenden, und damit bleiben die echten Bugs am Ende doch unentdeckt. Nicht das Werkzeug hat versagt, sondern die Anreizstruktur.
Sicherheit ist die Unbekannte, die niemand einpreisen will
Die Sicherheitsdimension von KI-generiertem Code verdient eine direkte Behandlung, nicht bloß einen Vorbehalt.
Veracodes 2025 GenAI Code Security Report, der über 100 LLMs anhand von 80 ausgewählten Programmieraufgaben in Java, JavaScript, Python und C# untersuchte, kam zu dem Ergebnis, dass KI-generierter Code in 45 % der Testfälle Schwachstellen aus den OWASP Top 10 einführte. Beunruhigender ist ein anderer Befund: Die Sicherheitsleistung ist gleich geblieben, obwohl die Modelle beim Erzeugen syntaktisch korrekten Codes dramatisch besser wurden. Größere Modelle schreiben nicht nennenswert sichereren Code als kleinere. Das deutet auf ein systemisches Problem hin (Modelle, die mit öffentlichen Repositories trainiert wurden, erben Jahrzehnte verwundbarer Muster) und nicht auf ein Skalierungsproblem, das künftige Modellgenerationen lösen werden.
Die 45 % brauchen einen Vorbehalt: Veracodes Aufgaben waren darauf ausgelegt, häufige Schwächen aufzudecken, nicht die gesamte Verteilung von Produktionscode abzubilden. Die tatsächliche Quote kennt niemand. Die Richtung des Befunds passt aber zu dem, was Sicherheitsteams aus der Praxis berichten: KI-Code kann tadellos aussehen und trotzdem bekannte Schwachstellenklassen enthalten, etwa CWE-80 (Cross-Site-Scripting, in 86 % der relevanten Aufgaben durchgefallen).
Das ist die entscheidende Unterscheidung für die Review-Architektur. Deterministische Leitplanken (Linter, Type Checks, Vertragsprüfung) fangen bekannte Problemklassen ab. Angreifer leben in den Lücken zwischen Klassen, Kontext und Konfiguration. Ein eigener Linter, der die Verwendung von PreparedStatement erzwingt, findet nicht den Authentifizierungs-Bypass, der aus dem Zusammenspiel zweier Services entsteht. Das spricht nicht gegen Leitplanken. Es spricht dafür, dass Leitplanken allein für sicherheitskritische Pfade nicht reichen und dass menschliche Eskalationsauslöser für diese Pfade keine Absicherung für alle Fälle sind, sondern das absolute Minimum.
Die Architektur, die wirklich skaliert
Nimmt man Jains Essay die provokante Zuspitzung, bleibt eine strukturelle Einsicht, die es wert ist, behalten zu werden: Der Ort des menschlichen Urteils muss sich verschieben. Nicht verschwinden, sondern verschieben. So sieht das in der Praxis aus.
Akzeptanzkriterien zuerst, und nicht als Dokumentation. Die Akzeptanzkriterien kommen aus der Spezifikation, nicht aus der Implementierung. Wenn der Agent sowohl den Code als auch die Tests schreibt, haben Sie das Problem nur verschoben: Sie vertrauen dann darauf, dass der Agent die richtigen Dinge testet. Verträge im BDD-Stil, die vor der Generierung geschrieben werden, werden zum Verifikations-Harness, mit dem der Agent nicht verhandeln kann. Zum Beispiel:
Feature: Payment processing
Scenario: Concurrent writes to the same account
Given two simultaneous debit requests for $100 against a $150 balance
When both requests are processed
Then exactly one succeeds and one returns InsufficientFunds
And the final balance is $50
And no amount is double-debited
Scenario: Third-party API timeout
Given the payment gateway times out after 3 seconds
When a debit request is in flight
Then the transaction is rolled back
And the account balance is unchanged
And the operation is marked retriable
Das macht aus einer Absicht ein überprüfbares Artefakt. Der Agent implementiert, das BDD-Framework setzt durch. Die Implementierung lesen Sie nur, wenn etwas fehlschlägt, und dann wissen Sie genau, wogegen sie verstoßen hat.
Bestandene Tests sind aber nicht das Ende der Geschichte. Contract Tests übersehen Randfälle der Integration. Ein Szenario, das isoliert besteht, kann katastrophal scheitern, wenn zwei Services unter Last zusammenspielen oder wenn eine dritte Abhängigkeit in der Produktion ihr Verhalten ändert. Observability ist deshalb keine betriebliche Nebensache, sondern Teil der Verifikationsarchitektur. Der Rollback-Plan gehört in die Akzeptanzkriterien, bevor die erste Zeile generiert wird, und darf nicht erst während der Incident Response entstehen. Wenn Sie nicht angeben können, wie Sie einen stillen Fehler erkennen und sauber zurückrollen, ist das Feature nicht bereit zum Ausliefern.
Belege im PR, nicht nur Diffs. Verlangen Sie, dass die PR-Beschreibung Nachweise enthält: Links zu bestandenen Testläufen, Lasttest-Deltas für performancekritische Pfade, Notizen zum Threat Model bei Änderungen an Authentifizierung oder Zahlungen und einen ausdrücklichen Rollout- und Revert-Plan. Damit wird der PR vom Genehmigungsritual zum Beweisstück, und „Approval“ bedeutet wieder etwas, was es seit Jahren nicht mehr bedeutet hat.
Adversariale Trennung. Der Agent, der den Code schreibt, sollte nicht der Agent sein, der ihn prüft. Das ist ein altes Prinzip (deshalb sollte die QA nicht an den Engineering Manager berichten), und heute lässt es sich billig architektonisch durchsetzen. Ein Verifikationsagent, der nur die Spezifikation und das Ergebnis bekommt, findet andere Fehlerbilder als der Agent, der den Code generiert hat.
Enge Berechtigungen. Wenn die Aufgabe lautet „behebe den Bug beim Parsen von Datumswerten in utils/dates.py“, sollte der Dateisystemzugriff des Agenten auf diese Datei und ihren Test beschränkt sein. Nicht auf src/. Scope Creep ist die Stelle, an der Agenten kaskadierende Probleme verursachen, und er lässt sich durch das Design vollständig verhindern.
Eskalationsauslöser für Pfade mit hohem Risiko, ohne Ausnahme. Authentifizierungslogik. Änderungen am Datenbankschema. Neue externe Abhängigkeiten. Zahlungen. Das alles wird für ein menschliches Review markiert, unabhängig vom Confidence Score des Agenten. Der Confidence Score ist hier nicht das relevante Signal.
Schnell ausliefern, alles beobachten, noch schneller zurückrollen, und Reverts üben wie den Feueralarm. Feature Flags, Canary Deployments, sofortige Rollbacks: Das System muss davon ausgehen, dass Dinge an den Leitplanken vorbeikommen. Nicht weil die Leitplanken schlecht sind, sondern weil sie das an irgendeinem Rand immer sind. Ein Rollback, den Sie nie geprobt haben, ist kein Rollback, sondern eine Hoffnung.
Was nicht skaliert
So tun, als ob. Das Approval nach drei Minuten auf einen Diff mit 847 Zeilen ist kein Code Review. Es ist die Unterschrift auf einem Dokument, das Sie nicht gelesen haben. Beim aktuellen Tempo von KI-generiertem Code ist die Lücke zwischen „wir haben einen Code-Review-Prozess“ und „dieser Prozess findet Bugs“ zu einem Abgrund geworden, und Addy Osmanis Beobachtung vom Januar, Review werde „strategischer“, ist die höfliche Art, das zu beschreiben. Die Verschiebung geht von „Haben Sie das korrekt geschrieben?“ zu „Testen wir die richtigen Dinge?“ Das ist eine grundlegend andere Arbeit.
Das wertvollste Training für die Entwickler, die in diesem Umfeld erfolgreich sein werden, ist nicht, mehr Code zu schreiben. Es ist das Entwerfen von Verifikationssystemen: zu wissen, was zu testen ist, welche Fragen man dem Review-Agenten stellt, wann die grünen Häkchen lügen und wie man Fehler korrigiert.
Der Streit darüber, ob Code Review „tot“ ist, verfehlt die betriebliche Realität: Bei KI-Tempo wird das Review Zeile für Zeile zur Zeremonie. Die Frage ist nicht, ob Pull Requests bleiben sollen. Die Frage ist, ob man das performative Approval durch ein Verifikationssystem ersetzt, das eine Welt übersteht, in der ein Diff mit 500 Zeilen ein Rundungsfehler ist.
Verlegen Sie das Urteil nach vorne. Automatisieren Sie, was geht. Zwingen Sie Menschen auf die Pfade, die Ihnen schaden können. Und üben Sie den Rollback, bevor Sie ihn brauchen.
Quellen:
- Ankit Jain, „How to Kill the Code Review“, Latent.Space: Faros-Daten, 10.000+ Entwickler, 1.255 Teams
- GitHub Octoverse 2025: 43 Mio. gemergte PRs pro Monat
- SmartBear / Cisco Peer-Review-Studie: Prüfrate und LOC-Richtwerte
- Addy Osmani, „Code Review in the Age of AI“, Elevate
- Veracode, 2025 GenAI Code Security Report: 45 % OWASP-Top-10-Fehlerquote über 100+ LLMs, 80 ausgewählte Aufgaben; Methodenhinweis: Die Aufgaben sollten bekannte CWE-Schwächen aufdecken und sind keine repräsentative Stichprobe von Produktionscode
- HackerNews: „There Is an AI Code Review Bubble“
Aus dem Englischen übersetzt: zum Originalbeitrag