Rachel Laycock, CTO von Thoughtworks, veröffentlicht am 2. September 2026 auf martinfowler.com eine Antwort auf die einen Monat zuvor von Brian Houck verfasste Engineering-Enablement-Ausgabe. Die beiden Autoren gerieten öffentlich auf einem von Moderne veranstalteten Code-Remix-Panel aneinander, und Houck ermunterte sie, diesen Beitrag zu schreiben. Die Kontroverse wird von Anfang an eingegrenzt: Sie wollen dasselbe, sie glaubt nur nicht, dass Code-Review der beste Weg ist, es zu erreichen.
Sie akzeptiert die Diagnose. KI produziert mehr Code, als Menschen vernünftigerweise überprüfen können, und Houcks Zahlen — ein Anstieg der signifikanten Zeilen pro Diff um 106% bei Meta, eine mediane Pull-Request-Größe von 64% bei DX — werden für bare Münze genommen. Sie teilt auch seine Sorge: Die Automatisierung des Reviews birgt das Risiko, alles andere zu verlieren, denn Review hat nie nur dazu gedient, Fehler zu finden. Ihre Frage liegt woanders: Warum bis zum Review warten, um all das zu tun?
Automatisierung der Zeremonie, statt zu hinterfragen, warum die Zeremonie existiert
Sie hat es nie gemocht, den Pull Request im Zentrum des Prozesses zu sehen. Etwas zu bauen, es fertigzustellen, zu verpacken, über den Zaun zu werfen und dann erst das wichtige Gespräch darüber zu führen, ob das Gebaute richtig ist, erscheint ihr wie eine umgekehrte Reihenfolge. Das Prinzip, das sie dagegenhält, hat sie früh bei Thoughtworks gelernt: Wenn Feedback einen Wert hat, entferne es nicht, sondern rücke es näher an die Entscheidung heran, die es informiert.
Es folgt eine systematische Neuzuordnung. Das Erkunden von Alternativen geschieht, bevor eine davon implementiert wird. Wissenstransfer geschieht durch Pairing, das mehr lehrt als das Lesen einer fertigen Lösung. Das Lernen von Junioren erfordert die Zusammenarbeit mit Senioren, während diese denken. Kollektive Verantwortung entsteht durch Teamorganisation, Mob Programming und Design-Sessions am Whiteboard. Architektonische Abstimmung entsteht durch gemeinsames Design, dann durch Fitness Functions. Formatierung, Linting, bekannte Sicherheitsprobleme und alles Deterministische werden automatisiert.
Was übrig bleibt, ist ausnahmebasiertes Review: eine fundamentale architektonische Änderung, eine sensible Sicherheitsgrenze, ein großer Blast Radius, ein unbekannter Bereich eines kritischen Systems, oder ein Team, das erklärt, ihm fehle das Vertrauen. Das unterscheidet sich davon, die Überprüfung jeder Änderung im Namen der Zeremonie zu verlangen. Sie verwirft auch den KI-Agenten, der den menschlichen Reviewer nachbilden würde: Das automatisiert die Zeremonie, statt ihren Daseinsgrund zu hinterfragen.
Einen Punkt räumt sie ein: Die kognitive Schuld und die Intentionsschuld, die Houck beschreibt, sind ein echtes Problem. Aber der verpflichtende PR ist eine schwache Verteidigung dagegen. Was gebraucht wird, ist kollaboratives Design, Pairing, gute Grenzen, ausführbare Architektur und gemeinsame operative Verantwortung — denn Engineers müssen Systeme verstehen, nicht Diffs.