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

## Veille

Post by **Rachel Laycock**, CTO of **Thoughtworks**, published on **September 2, 2026** on *Rachel's Ramblings*, the martinfowler.com section she runs, roughly **8,000 characters**. The text is a **deliberate response** to [[houck-dx-what-are-code-reviews-for-2026-08-05]], following a public disagreement between the two authors on a **Code Remix** panel hosted by **Moderne**. Laycock accepts Houck's quantified diagnosis (+**106%** lines per diff at **Meta**, +**64%** median PR size on the DX side) and the list of non-defect-finding functions of review, then shifts the question: *« why are we waiting until code review to do all of those things? »* (A) The guiding principle is the shortening of feedback loops learned at Thoughtworks — if feedback has value, don't remove it, move it closer to the decision it informs. Each function attributed to review is reassigned upstream: exploring alternatives before implementation, knowledge transfer through **pair programming**, collective ownership through **mob programming** and team design sessions, architectural alignment through shared design followed by **fitness functions**, and automation of everything deterministic — *« We really shouldn't still be arguing about whitespace in 2026. »* (B) Exception-based review replaces systematic review: a fundamental architectural change, a sensitive security boundary, a large blast radius, an unfamiliar area of a critical system, or simply a team's declared lack of confidence. (1) Automating review with an agent that mimics the human reviewer is dismissed as *« automating the ceremony rather than questioning why the ceremony exists »*. (2) Houck's cognitive debt is acknowledged as real, but the mandatory PR is judged a weak defense: *« We need engineers to understand systems, not 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, exception-based review, pull request, short feedback loop, shift judgment left, shift left, pair programming, mob programming, team design session, trunk-based development, fitness functions, evolutionary architecture, static analysis, automated tests, security scan, ceremony, bottleneck, blast radius, security boundary, cognitive debt, intention debt, collective ownership, knowledge transfer, understand systems, not diffs, Thoughtworks, Code Remix, Moderne

## Authors

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

## Ton

Profile: short response post signed by a technical executive, fully owned first-person voice, argumentative and personal register, medium technical level, target audience of engineering leaders and agile practitioners. The text announces itself as such from the opening — panel, disagreement, the other author's invitation to write the response — and sets its terms of courtesy before attacking: agreement on the facts, agreement on the goals, disagreement on the means. *« I think we mostly want the same things. I just don't think code review is the best way to get them. »* The concession is explicit and doubled with humor (*« Brian is lovely, by the way »*, *« But I'd be lying if I said I didn't want you to think I'm right by the end :) »*), as is the admission of a long-held position: the author has never liked the pull request at the center of the process, and says so with a deliberate digression on merge conflicts. The construction is a point-by-point rebuttal that picks up her opponent's list and reassigns it, with a figure repeated to the point of self-irony (*« I won't repeat myself about pairing and team design sessions, oh wait... »*). The reservation is placed where it belongs, without staging: the cognitive and intention debt is conceded as *« a very real problem »*, only the remedy is disputed. Quotable as-is: *« If feedback is valuable, don't remove it. Move it closer to the decision it is informing »*; *« We need engineers to understand systems, not diffs »*; *« automating the ceremony rather than questioning why the ceremony exists »*; and the closing line, *« perhaps the question isn't how we get the code reviewed faster. Perhaps it's why we're waiting until code review to have all the important conversations in the first place. »*

## Pense-betes

- **The disagreement is about the means, not the end.** Laycock accepts Houck's figures and list — review also serves knowledge sharing, junior training, collective ownership, and spreading architectural understanding — and does not conclude that review must be preserved, but that we must stop waiting for review to do all of this. The thesis rests on a timing inversion, not a dispute over the data.
- **The imported principle: shorten the loop, don't remove the feedback.** *« If feedback is valuable, don't remove it. Move it closer to the decision it is informing. »* Function-by-function reassignment table: exploring alternatives → before implementation, not after; knowledge transfer → **pair programming**, because reasoning alongside someone teaches more than reading their finished solution; junior learning → working with seniors *while* they think; collective ownership → team organization, **mob programming**, whiteboard design sessions; architectural alignment → shared design followed by **fitness functions** encoding the constraints; formatting, linting, known security issues, and anything deterministically testable → automation.
- **« Exception-based review » is the proposed exit mechanism**, and it is explicitly bounded: a fundamental architectural change (possibly reviewed as a team after a design session), crossing a sensitive security boundary, a change with a large blast radius, an unfamiliar part of a critical system, or a team declaring itself lacking confidence. The distinction is between *« exactly the places where human judgment is valuable »* and requiring human inspection of every change in the name of the historical ceremony of producing confidence.
- ⚠️ **The anti-bottleneck argument is independent of the pedagogical one** and stands on its own: if an agent produces ten times more code but every line still ends up queued in front of a senior engineer, you haven't built a ten-times-faster organization — you've built a backlog and a new bottleneck. It's the same mechanism as the accepted-change cost in [[staples-gitlab-when-code-is-abundant-2026-08-24]]: removing one constraint exposes the next.
- **AI review mimicking the human reviewer is explicitly rejected** — not because it would work poorly, but because it preserves a process whose reason for existing hasn't been re-examined: *« That's automating the ceremony rather than questioning why the ceremony exists. »* Note for practice: this reservation targets like-for-like substitution, not agents participating in upstream loops, which the text accepts (challenging designs, testing hypotheses, continuous verification), while maintaining that the thinking comes from experienced humans.
- **What's conceded, and what's pushed back**: the cognitive and intention debt is called a *« very real problem »*; what's contested is the mandatory PR as a defense against it. The counter-proposal is not a single mechanism but a list — collaborative design, pairing, good boundaries, executable architecture, shared operational responsibility — paired with the admission that practices not yet invented will probably be needed.
- **The underlying diagnosis, worth keeping outside the debate**: years of piling an extraordinary number of responsibilities onto code review — quality gate, security control, architecture review, mentoring mechanism, knowledge-sharing system, ownership model. This held up only as long as humans could produce code at a certain speed; that constraint is what's disappearing, and the stack with it.
- **Related**: [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] (the same conclusion about human inspection, reached through automation rather than shifting left) and [[boeckeler-harness-engineering-coding-agents-2026-04-02]] (upstream verification tooling, also from Thoughtworks).

## RésuméDe400mots

Rachel Laycock, CTO of Thoughtworks, publishes a response on martinfowler.com on September 2, 2026 to the Engineering Enablement edition signed by Brian Houck a month earlier. The two authors clashed publicly on a Code Remix panel hosted by Moderne, and Houck encouraged her to write this piece. The disagreement is bounded from the outset: they want the same thing, she just doesn't think code review is the best way to get it.

She accepts the diagnosis. AI produces more code than humans can reasonably review, and Houck's figures — a 106% increase in significant lines per diff at Meta, a 64% median pull request size at DX — are taken at face value. She also shares his worry: automating review risks losing everything else, since review has never served only to find bugs. Her question lies elsewhere: why wait until review to do all of that?

She has never liked seeing the pull request at the center of the process. Building something, finishing it, packaging it, throwing it over the fence, then having the important conversation about whether what was built is right, strikes her as a reversed order. The principle she sets against it is one learned early at Thoughtworks: if feedback has value, don't remove it, but move it closer to the decision it informs.

A systematic reassignment follows. Exploring alternatives happens before implementing one. Knowledge transfer happens through pairing, which teaches more than reading a finished solution. Junior learning requires working alongside seniors while they think. Collective ownership comes from team organization, mob programming, and whiteboard design sessions. Architectural alignment emerges from shared design, then fitness functions. Formatting, linting, known security issues, and anything deterministic get automated.

What remains is exception-based review: a fundamental architectural change, a sensitive security boundary, a large blast radius, an unfamiliar area of a critical system, or a team declaring itself lacking confidence. That is different from requiring inspection of every change in the name of ceremony. She also dismisses the AI agent that would mimic the human reviewer: that automates the ceremony instead of questioning its reason for existing.

She concedes one point: the cognitive and intention debt Houck describes is a real problem. But the mandatory PR is a weak defense against it. What's needed is collaborative design, pairing, good boundaries, executable architecture, and shared operational responsibility — because engineers need to understand systems, not 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/en/fiches/laycock-thoughtworks-reviewing-all-this-code-2026-09-02/