Das Code-Review war jahrelang der ruhige Schlusspunkt vor dem Merge, doch KI-Agenten bringen dieses Gefüge ins Wanken. Ein einzelner Pull Request umfasst heute tausende neuer Zeilen, erzeugt in Minuten und gedacht zum Prüfen in Stunden. Rachel Laycock, Technikchefin der Beratung Thoughtworks, hält das bloße Beschleunigen für den falschen Reflex und will den Prüfprozess neu zuschneiden.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Bei Meta stieg der Code pro geprüfter Änderung binnen eines Jahres um 106 Prozent, über 80 Prozent davon steuern KI-Agenten bei.
- Rachel Laycock (Thoughtworks) will Prüfaufgaben nach vorne verlagern, statt das Review zu beschleunigen.
- Routinecode läuft künftig durch automatisierte Prüfungen, menschliches Review bleibt für riskante Änderungen.
- Haftung bleibt beim Team: Gefragt ist Verständnis der Systemlogik, nicht das schnelle Abnicken eines Diffs.
Warum überlastet KI-Code das Vier-Augen-Prinzip?
KI-Assistenten erzeugen Code schneller, als Menschen ihn lesen können, und sprengen das Review. Bei Meta wuchs der Umfang pro von Menschen abgenommener Änderung binnen eines Jahres um 106 Prozent, mehr als 80 Prozent dieses Zuwachses gehen auf agentische KI zurück.[1] Die Entwicklungsplattform DX beziffert den Anstieg der mittleren Pull-Request-Größe im selben Zeitraum auf 64 Prozent.[2]
Größere Änderungspakete kehren den Zweck des Reviews um. Ein Prüfer überfliegt tausend Zeilen, findet die entscheidende Stelle nicht und winkt durch, oder der Stapel offener Anfragen wächst zum Engpass. Beides untergräbt genau die Qualität, die das Review sichern soll, und treibt zugleich die Wartungskosten des Codes nach oben.
Was schlägt Thoughtworks stattdessen vor?
Laycock will das Prüfen nach vorne verlagern, statt das Review zu beschleunigen. Warum, fragt sie, warten Teams mit Qualität, Wissenstransfer und Architektur bis zum Schluss? Formatierung, Sicherheitsscans und Stilregeln erledigen Werkzeuge automatisch, Architekturgrenzen sichern sogenannte Fitness Functions, und Wissen fließt über Pair Programming und gemeinsame Entwurfsrunden schon vor der ersten Zeile Code.
Menschliches Review bleibt, aber gezielt. Nur riskante Änderungen kommen auf den Tisch: Eingriffe in die Architektur, in Sicherheitsgrenzen oder in unbekannte kritische Systeme. Laycock bringt es auf den Punkt: „Wir brauchen Ingenieure, die Systeme verstehen, nicht Diffs.“ Genau dieses Verständnis höhlen große KI-Diffs aus, wovor auch andere Beobachter im Umgang mit KI-Agenten warnen.
Ein beschleunigtes Review ist noch kein besseres Review. Den Prüfschritt dorthin zu holen, wo der Code entsteht, sichert die Qualität, die das KI-Tempo sonst zerreibt.
— Markus Seyfferth, Chefredakteur Dr. Web
Warum das klassische Review an seine Grenze stößt, in drei Zahlen.
Vom End-Review zum frühen Prüfen
- Ein Pull Request bringt tausende KI-erzeugte Zeilen auf einmal.
- Der Prüfer überfliegt, findet die kritische Stelle nicht und winkt durch.
- Der Stapel offener Anfragen wächst zum Engpass.
- Werkzeuge übernehmen Format, Stil und Sicherheitsscans automatisch.
- Wissen fließt über Pair Programming und gemeinsame Entwürfe.
- Menschliches Review bleibt nur für riskante Änderungen.
Was sollten deutsche Teams jetzt ändern?
Der Befund ist kein Einzelfall. Oracle untersagte KI-generierten Code im OpenJDK-Projekt, und Berichte über wachsende, kaum noch gelesene Pull Requests häufen sich. Der rote Faden liegt nicht in der Menge des Codes, sondern im erhaltenen Verständnis dafür.
In Deutschland verschärft die Haftungsfrage das Thema. Unter dem EU AI Act und der Produkthaftung bleibt die Verantwortung beim Team, nicht beim Modell, und sicherheitskritische Software verlangt dokumentierte menschliche Aufsicht. Wo diese Aufsicht zur Formsache verkommt, beginnt das eigentliche Risiko.
- Automatik ausbauen: Linting, Tests und Sicherheitsscans in die Pipeline, damit menschliches Review nur an riskanten Stellen greift.
- Verantwortung klären: Zuständigkeiten für kritische Systeme dokumentieren, statt große KI-Diffs stillschweigend abzunicken.
- Wissen sichern: Pair Programming und gemeinsame Entwürfe halten das Systemverständnis wach.
Das Code-Review verschwindet nicht, sondern verschiebt sich. Teams, die Prüfung und Wissen nach vorne ziehen, gewinnen die Kontrolle zurück, die das KI-Tempo sonst kostet. Der nächste überlange Pull Request ist die Gelegenheit: nicht schneller abnicken, sondern in prüfbare Stücke zerlegen.
Quellen
[1] Rachel Laycock: „Maybe We Shouldn’t Be Reviewing All This Code“
[2] DX: „AI-authored code has nearly doubled, but so has PR size“
