KI habe die Code Review ruiniert, heißt es oft – sie erzeuge mehr Code, als Menschen lesen können. Rachel Laycock, CTO bei Thoughtworks, dreht die Beweislast um: Nicht die Werkzeuge überfordern das Verfahren, sondern die Softwareentwicklung hat ein einzelnes Verfahren mit Aufgaben beladen, die es nie tragen konnte. Veröffentlicht hat Laycock den Text am 2. September 2026 als Antwort auf einen Beitrag von Brian Houck von DX. Anlass war ein Panel bei Code Remix, moderiert von Moderne, auf dem beide unterschiedlicher Meinung waren. Der Streit selbst ist weniger aufschlussreich als die Frage, um die es dabei geht.
Houck hat seine Sicht unter dem Titel „What are code reviews even for?“ dargelegt. Laycock nennt ihn sympathisch und betont, dass beide Seiten dasselbe wollen – nur führe die Code Review nicht dorthin. Solche Auseinandersetzungen sind nützlich, weil sie zeigen, wo Annahmen auseinandergehen und nicht bloß Vorlieben. Wer sich mit Code Review, Pull Requests und Pair Programming beschäftigt, findet darin eine Positionsbestimmung, die über die übliche Werkzeugdebatte hinausreicht.
Die Zahlen hinter der Debatte: mehr Code pro Kopf, größere Pull Requests
Houck nennt Zahlen, die sich nicht wegdiskutieren lassen. Bei Meta sollen die signifikanten Codezeilen pro menschlich gemergtem Diff innerhalb eines Jahres um 106 Prozent gestiegen sein. Die Daten von DX zeigen nach seiner Darstellung einen Anstieg der medianen Pull-Request-Größe um 64 Prozent. Diese Entwicklung erklärt, warum Code Review in vielen Teams wieder zum Thema geworden ist.
Houck sorgt sich nicht nur um die Menge. Wenn Code Review automatisiert werde, so sein Argument, gehe verloren, was sonst daran hängt: Wissensaustausch, Einarbeitung jüngerer Entwickler, kollektives Eigentum am Code, Verständnis für Architekturentscheidungen. Diese Sorge teilt Laycock ausdrücklich. Der Einwand setzt eine Ebene tiefer an: Warum wartet man überhaupt bis zur Code Review, um all das zu erledigen?
Warum das Feedback nach vorne gehört
Dahinter steht ein Prinzip, das Laycock nach eigener Aussage früh bei Thoughtworks gelernt hat: Feedback-Schleifen verkürzen. Ist eine Rückmeldung wertvoll, schafft man sie nicht ab – man rückt sie näher an die Entscheidung heran, die sie beeinflussen soll. Der Pull Request als Mittelpunkt der Entwicklung erfüllt genau das nicht. Man baut etwas, stellt es fertig, schnürt ein Paket, wirft es jemand anderem zu – und führt erst dann das wichtige Gespräch darüber, ob das Richtige auf die richtige Weise gebaut wurde.
Laycock geht die üblichen Begründungen für die Code Review einzeln durch und verschiebt jede an den Ort, an dem sie früher wirkt. Wer Alternativen abwägen will, sollte das tun, bevor eine davon implementiert ist. Wer Wissen weitergeben will, soll paaren: Neben jemandem zu sitzen, während diese Person ein Problem durchdenkt, lehrt mehr als die fertige Lösung hinterher zu lesen. Wer will, dass jüngere Entwickler die Denkweise erfahrener Kollegen aufnehmen, lässt sie mitarbeiten, während gedacht wird – oder setzt das Team vor ein Whiteboard, bevor überhaupt jemand Code schreibt oder einen Agenten damit beauftragt.
Beim kollektiven Eigentum geht es um Organisation, nicht um ein Verfahren: Teams sollten Software gemeinsam bauen und betreiben, statt sich vom Pull Request erzählen zu lassen, was jemand anderes bereits fertiggestellt hat. Architektonische Übereinstimmung entsteht im gemeinsamen Entwurf – und die wichtigen Randbedingungen gehören anschließend als Fitness Functions in den Code, nicht in einen Kommentar. Und was Formatierung, Linting, bekannte Sicherheitsprobleme oder deterministisch prüfbare Eigenschaften angeht: automatisieren. Über Leerzeichen, so der trockene Kommentar, sollte man 2026 nicht mehr streiten.
Pair Programming, Trunk-based Development, automatisierte Tests, statische Analyse, Fitness Functions und Security-Scans haben eines gemeinsam – sie ziehen Rückmeldung nach vorne. Agenten können in diesen Schleifen zunehmend mitspielen, Entwürfe hinterfragen, Annahmen testen, laufend prüfen. Das eigentliche Denken kommt weiterhin von erfahrenen Menschen. Und wenn diese Erfahrung dem ganzen Team zugutekommen soll, muss das Team deutlich früher als bei der Code Review wie ein Team handeln.
Review nach Ausnahme statt nach Pflicht
Das heißt ausdrücklich nicht, dass niemand mehr Code liest. Es gibt Änderungen, bei denen Laycock einen zweiten erfahrenen Blick ausdrücklich will: eine grundlegende Architekturänderung etwa, die das Team nach einer gemeinsamen Entwurfssitzung noch einmal zusammen durchgeht. Ebenso etwas, das eine sensible Sicherheitsgrenze berührt, eine Änderung mit großem Wirkungsradius, ein unvertrauter Teil eines kritischen Systems – oder schlicht ein Fall, bei dem jemand im Team sagt: Da bin ich mir nicht sicher.
Genau dort ist menschliches Urteil wertvoll. Das ist aber etwas völlig anderes, als jede einzelne Änderung von einem Menschen inspizieren zu lassen, weil das historisch die Zeremonie war, mit der man Vertrauen hergestellt hat.
Der Engpass, den mehr Tempo nicht löst
Dass es so nicht weitergeht, zeigt sich daran, dass die Code Review überhaupt wieder als Problem auftaucht. Wenn ein Agent die zehnfache Menge Code produziert, aber jede Zeile am Ende darauf wartet, dass ein erfahrener Entwickler sie prüft, ist keine zehnfach leistungsfähige Organisation entstanden – sondern ein großer Rückstau und ein neuer Engpass.
Die naheliegende Antwort, einen KI-Agenten die Rolle des menschlichen Prüfers spielen zu lassen, hält Laycock für die falsche. Damit werde dasselbe Verfahren bei höherem Tempo beibehalten: Man automatisiert die Zeremonie, statt zu fragen, wozu es sie überhaupt gibt.
Was an Houcks Einwand bleibt
Ein Punkt aus Houcks Argumentation bereitet Laycock allerdings Sorge: die Vorstellung von kognitiven Schulden und Intent Debt. Software wächst, während die Menschen, die für sie verantwortlich sind, immer weniger davon verstehen, warum sie so funktioniert, wie sie funktioniert. Das Problem sei real. Nur seien verpflichtende Pull Requests keine besonders starke Verteidigung dagegen.
Wenn Agenten künftig einen erheblichen Teil der Implementierung übernehmen, braucht es nach Laycocks Darstellung deutlich mehr Absicht beim Erhalt des menschlichen Verständnisses: gemeinsamer Entwurf, Pairing, saubere Grenzen, ausführbare Architektur, geteilte Betriebsverantwortung – und vermutlich Praktiken, die noch niemand erfunden hat.
Systeme verstehen, nicht Diffs
Der Satz, auf den der Text hinausläuft, ist gleichzeitig seine Zusammenfassung: Entwickler müssen Systeme verstehen, nicht Diffs. Vielleicht, so die Vermutung, legt die KI hier nur etwas frei, das schon länger schief lag. Über Jahre wurde der bescheidenen Code Review eine außergewöhnliche Zahl von Zuständigkeiten aufgeladen – Qualitätstor, Sicherheitsprüfung, Architekturreview, Mentoring-Mechanismus, Wissensverteilung, Eigentumsmodell.
Das funktionierte, halbwegs, solange Menschen Code nur in begrenztem Tempo herstellen konnten. Diese Begrenzung verschwindet gerade. Damit verschiebt sich auch die Frage: Sie lautet nicht mehr, wie man Code schneller geprüft bekommt, sondern warum man mit allen wichtigen Gesprächen bis zur Code Review wartet.
Quelle: martinfowler.com
