# Maybe We Shouldn't Be Reviewing All This Code

Rachel Laycock, a Thoughtworks colleague of Martin Fowler's, wrote this for her "Rachel's ramblings" column on martinfowler.com as a reply to Brian Houck of DX. The two disagreed on a panel at Code Remix, hosted by Moderne, and Houck followed up with a piece titled "What are code reviews even for?". Her subtitle states the position: perhaps AI has not broken code review, and teams have been using review to solve the wrong problems.

## What they agree on

The volume problem is shared ground. Houck's numbers, as she relays them: at Meta, lines of code per human-landed diff reportedly rose 106% in a year, and DX's own data shows median pull request size up 64%. Both also agree that review does more than find bugs. Teams use it to share knowledge, teach junior engineers, build collective ownership and spread architectural understanding, and automating review away risks losing all of that. Where they part is her question: why wait until review to do any of it?

## Shift the judgment left

The principle she took from early Thoughtworks practice is to shorten feedback loops, keeping valuable feedback but moving it next to the decision it informs. She goes through review's jobs one at a time. Exploring alternatives belongs before one of them is implemented. Knowledge transfer happens better when you pair with someone while they reason than when you read their finished solution. Juniors learn how experienced engineers think by working with them while they think, in pairs or in whiteboard design sessions held before anyone writes code or instructs an agent to. Collective ownership comes from building and operating software together, not from a PR announcing what someone already built. Architectural alignment comes from designing together and then encoding the important constraints as fitness functions. Formatting, linting, known security problems and anything deterministically testable should be automated; nobody should be arguing about whitespace in 2026. Agents can take part in these earlier loops, challenging designs and testing assumptions, but she places the real thinking with experienced humans.

## Review by exception

She keeps human review for the cases where judgment pays: a fundamental architectural change (possibly reviewed by the whole team that designed it), a change crossing a sensitive security boundary, a huge blast radius, an unfamiliar part of a critical system, or simply a team saying it is not confident. What she rejects is requiring a human to inspect every change because that is the ceremony teams have used to create confidence. An agent that produces ten times the code, all of it queued for a senior engineer, yields a backlog and a new bottleneck, not a ten-times organisation.

She is equally unenthusiastic about the obvious fix. An AI agent pretending to be the human reviewer so the process survives at higher speed is, in her words, automating the ceremony instead of asking why the ceremony exists.

The one worry she takes from Houck is cognitive and intent debt: software growing while its owners understand less and less of why it works as it does. She accepts the problem and doubts mandatory PRs defend against it, pointing instead to collaborative design, pairing, clear boundaries, executable architecture and shared operational responsibility. The line she lands on is that engineers need to understand systems, not diffs. Review, she writes, was loaded with the jobs of quality gate, security check, architecture review, mentoring, knowledge sharing and ownership model, and that worked only while humans wrote code slowly.

## Where it sits

The argument arrives where [[code-review-knowledge-transfer]] and [[stop-using-pull-requests]] arrive from the research side, and her exceptions list is close to the "Ask" category of [[ship-show-ask]]. The delivery mechanisms she proposes are [[pair-programming]] and [[trunk-based-development]]. She agrees with [[reviewing-ai-code]] and [[code-review-throughput-limits]] that reviewing every line of agent output does not scale, and unlike Depierre she reads that as a reason to relocate review, not as a ceiling on agent use. The intent-debt worry is the same trade [[cognitive-debt]] describes.

Her dismissal of an AI stand-in reviewer is the sharpest contrast with [[cross-model-code-review]], where a second model reviewing the first is the whole design. The research there measures whether such a reviewer catches errors; Laycock asks whether that gate should exist for most changes at all. The practitioners quoted in [[cacm-code-review-ai-coding]] mostly take the opposite line, that review matters more once agents write the code.

## Cross-references

- [[agent-principal-agent-problem]] — why review's effort signal broke once agents wrote the diffs
- [[control-the-ideas-not-the-code]] — antirez's parallel move from reading lines to holding the design
- [[cacm-code-review-ai-coding]] — the counter-position from CACM's practitioner sources, September 2026