# laycock-thoughtworks-reviewing-all-this-code-2026-09-02

## Veille

Beitrag von **Rachel Laycock**, CTO von **Thoughtworks**, veröffentlicht am **2. September 2026** in *Rachel's Ramblings*, der von ihr geleiteten martinfowler.com-Rubrik, mit rund **8.000 Zeichen**. Der Text ist eine **bewusste Antwort** auf [[houck-dx-what-are-code-reviews-for-2026-08-05]], nach einer öffentlichen Kontroverse zwischen den beiden Autoren auf einem **Code Remix**-Panel, veranstaltet von **Moderne**. Laycock akzeptiert Houcks quantifizierte Diagnose (+**106%** Zeilen pro Diff bei **Meta**, +**64%** mediane PR-Größe auf der DX-Seite) sowie die Liste der nicht-fehlererkennenden Funktionen des Reviews, verschiebt dann aber die Frage: *« warum warten wir bis zum Code-Review, um all das zu tun? »* (A) Das Leitprinzip ist die bei Thoughtworks erlernte Verkürzung von Feedback-Schleifen — wenn Feedback einen Wert hat, entferne es nicht, sondern rücke es näher an die Entscheidung heran, die es informiert. Jede dem Review zugeschriebene Funktion wird vorverlagert: das Erkunden von Alternativen vor der Implementierung, Wissenstransfer durch **pair programming**, kollektive Verantwortung durch **mob programming** und Team-Design-Sessions, architektonische Abstimmung durch gemeinsames Design, gefolgt von **fitness functions**, und Automatisierung von allem Deterministischen — *« Wir sollten 2026 wirklich nicht mehr über Whitespace streiten. »* (B) Ausnahmebasiertes Review ersetzt systematisches Review: eine fundamentale architektonische Änderung, eine sensible Sicherheitsgrenze, ein großer Blast Radius, ein unbekannter Bereich eines kritischen Systems, oder schlicht das erklärte mangelnde Vertrauen eines Teams. (1) Die Automatisierung des Reviews durch einen Agenten, der den menschlichen Reviewer nachbildet, wird verworfen als *« Automatisierung der Zeremonie, statt zu hinterfragen, warum die Zeremonie existiert »*. (2) Houcks kognitive Schuld wird als real anerkannt, doch der verpflichtende PR wird als schwache Verteidigung eingestuft: *« Wir brauchen Engineers, die Systeme verstehen, nicht Diffs. »*

## Titre Article

Maybe We Shouldn't Be Reviewing All This Code

## Date

2026-09-02

## URL

https://martinfowler.com/rachels-ramblings/code-review.html

## Keywords

Code Review, ausnahmebasiertes Review, Pull Request, kurze Feedback-Schleife, Urteilsvermögen vorverlagern, Shift Left, Pair Programming, Mob Programming, Team-Design-Session, Trunk-Based Development, Fitness Functions, evolutionäre Architektur, statische Analyse, automatisierte Tests, Sicherheitsscan, Zeremonie, Engpass, Blast Radius, Sicherheitsgrenze, kognitive Schuld, Intentionsschuld, kollektive Verantwortung, Wissenstransfer, Systeme verstehen, nicht Diffs, Thoughtworks, Code Remix, Moderne

## Authors

Rachel Laycock, CTO de Thoughtworks, sur *Rachel's Ramblings* (martinfowler.com).

## Ton

Profil: kurzer Antwortbeitrag, unterzeichnet von einer technischen Führungskraft, voll übernommene Ich-Stimme, argumentatives und persönliches Register, mittleres technisches Niveau, Zielgruppe Engineering-Führungskräfte und Agile-Praktiker. Der Text kündigt sich von Anfang an als solcher an — Panel, Kontroverse, die Einladung des anderen Autors, die Antwort zu schreiben — und legt seine Höflichkeitsbedingungen fest, bevor er angreift: Einigkeit über die Fakten, Einigkeit über die Ziele, Uneinigkeit über die Mittel. *« Ich glaube, wir wollen größtenteils dasselbe. Ich denke nur nicht, dass Code-Review der beste Weg ist, es zu bekommen. »* Das Zugeständnis ist explizit und mit Humor verdoppelt (*« Brian ist übrigens ein Schatz »*, *« Aber ich würde lügen, wenn ich sagte, ich wollte nicht, dass du am Ende denkst, ich hätte recht :) »*), ebenso wie das Eingeständnis einer lange gehegten Position: Die Autorin hat es nie gemocht, den Pull Request im Zentrum des Prozesses zu sehen, und sagt dies mit einem bewussten Abstecher zu Merge-Konflikten. Der Aufbau ist eine Punkt-für-Punkt-Widerlegung, die die Liste ihres Gegners aufgreift und neu zuordnet, mit einer bis zur Selbstironie wiederholten Formulierung (*« Ich wiederhole mich nicht noch einmal zu Pairing und Team-Design-Sessions, ach, doch... »*). Der Vorbehalt wird an der richtigen Stelle platziert, ohne Inszenierung: Die kognitive Schuld und die Intentionsschuld werden als *« ein sehr reales Problem »* eingeräumt, nur das Mittel wird bestritten. Wörtlich zitierbar: *« Wenn Feedback wertvoll ist, entferne es nicht. Rücke es näher an die Entscheidung heran, die es informiert »*; *« Wir brauchen Engineers, die Systeme verstehen, nicht Diffs »*; *« die Zeremonie automatisieren, statt zu hinterfragen, warum die Zeremonie existiert »*; und der Schlusssatz, *« vielleicht ist die Frage nicht, wie wir den Code schneller überprüfen lassen. Vielleicht ist es, warum wir überhaupt bis zum Code-Review warten, um alle wichtigen Gespräche zu führen. »*

## Pense-betes

- **Die Kontroverse betrifft die Mittel, nicht das Ziel.** Laycock akzeptiert Houcks Zahlen und Liste — Review dient auch dem Wissensaustausch, der Ausbildung von Junioren, der kollektiven Verantwortung und der Verbreitung architektonischen Verständnisses — und schließt daraus nicht, dass Review erhalten bleiben muss, sondern dass wir aufhören müssen, auf das Review zu warten, um all das zu tun. Die These beruht auf einer Umkehrung des Zeitpunkts, nicht auf einem Streit über die Daten.
- **Das importierte Prinzip: die Schleife verkürzen, nicht das Feedback entfernen.** *« Wenn Feedback wertvoll ist, entferne es nicht. Rücke es näher an die Entscheidung heran, die es informiert. »* Funktion-für-Funktion-Neuzuordnungstabelle: Erkunden von Alternativen → vor der Implementierung, nicht danach; Wissenstransfer → **pair programming**, denn gemeinsames Denken mit jemandem lehrt mehr als das Lesen seiner fertigen Lösung; Lernen von Junioren → Zusammenarbeit mit Senioren, *während* diese denken; kollektive Verantwortung → Teamorganisation, **mob programming**, Design-Sessions am Whiteboard; architektonische Abstimmung → gemeinsames Design, gefolgt von **fitness functions**, die die Zwänge kodieren; Formatierung, Linting, bekannte Sicherheitsprobleme und alles deterministisch Testbare → Automatisierung.
- **« Ausnahmebasiertes Review » ist der vorgeschlagene Ausstiegsmechanismus**, und er wird explizit eingegrenzt: eine fundamentale architektonische Änderung (gegebenenfalls als Team nach einer Design-Session überprüft), das Überschreiten einer sensiblen Sicherheitsgrenze, eine Änderung mit großem Blast Radius, ein unbekannter Teil eines kritischen Systems, oder ein Team, das erklärt, ihm fehle das Vertrauen. Die Unterscheidung verläuft zwischen *« genau den Stellen, an denen menschliches Urteilsvermögen wertvoll ist »* und der Forderung, jede Änderung im Namen der historischen Zeremonie zur Erzeugung von Vertrauen menschlich zu überprüfen.
- ⚠️ **Das Anti-Engpass-Argument ist unabhängig vom pädagogischen** und steht für sich: Wenn ein Agent zehnmal mehr Code produziert, aber jede Zeile trotzdem in der Warteschlange vor einem Senior Engineer landet, hat man keine zehnmal schnellere Organisation gebaut — man hat einen Rückstau und einen neuen Engpass gebaut. Es ist derselbe Mechanismus wie die Kosten akzeptierter Änderungen in [[staples-gitlab-when-code-is-abundant-2026-08-24]]: Die Beseitigung eines Engpasses legt den nächsten frei.
- **Ein KI-Review, das den menschlichen Reviewer nachbildet, wird explizit abgelehnt** — nicht weil es schlecht funktionieren würde, sondern weil es einen Prozess bewahrt, dessen Daseinsgrund nicht neu überprüft wurde: *« Das automatisiert die Zeremonie, statt zu hinterfragen, warum die Zeremonie existiert. »* Hinweis für die Praxis: Dieser Vorbehalt richtet sich gegen eine Eins-zu-eins-Substitution, nicht gegen Agenten, die an vorgelagerten Schleifen teilnehmen — das akzeptiert der Text (Designs hinterfragen, Hypothesen testen, kontinuierliche Verifikation) —, wobei festgehalten wird, dass das Denken von erfahrenen Menschen kommt.
- **Was eingeräumt und was zurückgewiesen wird**: Die kognitive Schuld und die Intentionsschuld werden als *« sehr reales Problem »* bezeichnet; strittig ist der verpflichtende PR als Verteidigung dagegen. Der Gegenvorschlag ist kein einzelner Mechanismus, sondern eine Liste — kollaboratives Design, Pairing, gute Grenzen, ausführbare Architektur, gemeinsame operative Verantwortung —, verbunden mit dem Eingeständnis, dass noch nicht erfundene Praktiken wahrscheinlich nötig sein werden.
- **Die zugrunde liegende Diagnose, die man unabhängig von der Debatte festhalten sollte**: jahrelang wurde eine außerordentliche Zahl von Verantwortlichkeiten auf das Code-Review gehäuft — Qualitätsgate, Sicherheitskontrolle, Architekturüberprüfung, Mentoring-Mechanismus, Wissensaustauschsystem, Ownership-Modell. Das hielt nur so lange, wie Menschen Code mit einer bestimmten Geschwindigkeit produzieren konnten; genau diese Beschränkung verschwindet nun, und der ganze Stapel mit ihr.
- **Verwandt**: [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] (dieselbe Schlussfolgerung zur menschlichen Überprüfung, erreicht durch Automatisierung statt durch Vorverlagerung) und [[boeckeler-harness-engineering-coding-agents-2026-04-02]] (vorgelagerte Verifikationswerkzeuge, ebenfalls von Thoughtworks).

## RésuméDe400mots

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?

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.

## GrapheDeConnaissance

- Rachel Laycock —a_créé→ Maybe We Shouldn't Be Reviewing All This Code (DOCUMENT, 0.97)
- Rachel Laycock —dirige→ Thoughtworks (ORGANISATION, 0.95)
- Maybe We Shouldn't Be Reviewing All This Code —s_oppose_à→ What are code reviews even for? (DOCUMENT, 0.96)
- Rachel Laycock —affirme_que→ le problème n'est pas que l'IA ait cassé la revue de code, mais qu'on utilisait la revue pour résoudre les mauvais problèmes (AFFIRMATION, 0.95)
- boucle de rétroaction courte —recommande→ ne pas supprimer un retour de valeur, mais le rapprocher de la décision qu'il informe (CITATION, 0.94)
- pair programming —remplace→ revue de code (METHODOLOGIE, 0.92)
- pair programming —surpasse→ la lecture d'une solution achevée pour apprendre le raisonnement d'un ingénieur expérimenté (AFFIRMATION, 0.91)
- mob programming —permet→ propriété collective par construction, au lieu d'une notification de l'équipe après coup (AFFIRMATION, 0.89)
- session de design d'équipe —permet→ explorer les alternatives avant l'implémentation plutôt qu'après (CONCEPT, 0.91)
- fitness functions —permet→ encoder les contraintes architecturales importantes après un design commun (CONCEPT, 0.92)
- analyse statique —s_applique_à→ formatage, linting, problèmes de sécurité connus et tout ce qui est testable déterministiquement (CONCEPT, 0.92)
- revue par exception —s_applique_à→ changement architectural fondamental, frontière de sécurité sensible, large rayon d'impact, zone inconnue d'un système critique, inconfiance déclarée de l'équipe (CONCEPT, 0.94)
- revue par exception —s_oppose_à→ exiger l'inspection humaine de chaque changement au titre de la cérémonie historique de production de confiance (AFFIRMATION, 0.93)
- Rachel Laycock —prédit→ un agent produisant dix fois plus de code devant une file de revue senior ne crée pas une organisation dix fois plus rapide mais un backlog et un nouveau goulot (AFFIRMATION, 0.93)
- revue de code par agent imitant le relecteur humain —s_oppose_à→ interroger la raison d'être de la cérémonie plutôt que l'automatiser à l'identique (CITATION, 0.92)
- agents IA —permet→ participer aux boucles amont en contestant des designs, testant des hypothèses et vérifiant en continu, la pensée restant humaine (AFFIRMATION, 0.88)
- Rachel Laycock —soutient→ la dette cognitive et d'intention est un problème réel (AFFIRMATION, 0.92)
- pull request —réduit→ faiblement la dette cognitive et d'intention lorsqu'elle est rendue obligatoire, contre l'usage qui lui est prêté (AFFIRMATION, 0.9)
- Rachel Laycock —affirme_que→ il faut que les ingénieurs comprennent des systèmes, pas des diffs (CITATION, 0.95)
- revue de code —est_instance_de→ empilement de responsabilités (CONCEPT, 0.93)
- abondance du code générée par l'IA —s_oppose_à→ la contrainte de vitesse humaine qui rendait cet empilement tenable (AFFIRMATION, 0.9)
- Code Remix —observé_dans→ le désaccord public entre Rachel Laycock et Brian Houck, à l'origine du billet (AFFIRMATION, 0.9)
- Moderne —publie→ Code Remix (EVENEMENT, 0.88)
- Rachel Laycock —recommande→ maintenir la compréhension humaine par design collaboratif, pairing, bonnes frontières, architecture exécutable et responsabilité opérationnelle partagée (AFFIRMATION, 0.92)

---
Canonical: https://www.thekb.eu/de/fiches/laycock-thoughtworks-reviewing-all-this-code-2026-09-02/