Your Code Review Is One Control Doing Five Jobs

“Why are we waiting until code review to do all of those things?”

That question, from Rachel Laycock, CTO at Thoughtworks, is the whole argument of a piece she published on 2 September 2026. The “those things” is the part worth sitting with. Code review, as the practice matured, quietly absorbed five separate jobs: finding bugs, transferring knowledge across the team, mentoring junior engineers, keeping architecture aligned, and assigning ownership of what ships.

At human authorship volume, one gate could carry all five badly and nobody noticed, because the queue was short enough that the badness never compounded. That is no longer the volume. Laycock cites Brian Houck of DX for the shape of the change: at Meta, significant lines of code per human-landed diff reportedly increased 106% in a year, and DX’s own data shows median pull request size increasing 64%. Both numbers are secondhand in her piece. She is quoting Houck, not reporting her own measurements, and that distinction matters if you plan to put either figure in a slide.

Take those two numbers as directional rather than precise and the structural point survives either way. Where those figures hold, the same checkpoint receives a substantially larger diff for the same unit of human attention, and the standard organizational response is to review harder. Reviewing harder makes the checkpoint slower without making it better at any of its five jobs.

The Five Jobs, Named Separately

We have written before that you cannot delete code review, only rename the governance, and that the review layer becomes the bottleneck it was built to fix. Laycock’s contribution is to stop treating the gate as one thing. Once the five jobs are named separately, it becomes obvious that they have almost nothing in common except a shared calendar slot.

Finding bugs. A diff-shaped read by one tired person, after the code exists, is a weak detector. Tests, static analysis, and security scanning run on every commit and do not get bored.

Transferring knowledge. Reading someone else’s finished diff transfers the change, not the reasoning that produced it. The reasoning is gone by the time the pull request opens.

Mentoring. Asynchronous comments on a diff are a poor teaching medium. The junior engineer receives corrections without the context that would let them generalize.

Aligning architecture. By review time the architectural decision has already been made and implemented. Objecting is expensive, so reviewers usually do not.

Assigning ownership. The approval stamp records who is accountable. This is the one job the gate genuinely does, and it is administrative.

Four of these are being performed at the worst possible moment: after the work is finished, by a single reviewer, in text.

Where Each Job Actually Goes

Laycock’s redistribution is specific. Pairing and mob programming take knowledge transfer and mentoring, because both work in real time, while the reasoning is still live and questions cost nothing. Collective whiteboard design sessions take architectural alignment, held before implementation instead of after, when changing the design is still cheap. Trunk-based development keeps the increments small enough that the review question stays answerable. Automated testing, static analysis, and fitness functions take architectural constraint enforcement, running continuously rather than being remembered by whoever happens to review. Automated linting and security scanning take formatting and known-issue classes, which no human should be spending attention on in 2026.

None of these practices are new. What changed is the arithmetic that made ignoring them survivable. A team could skip pairing and absorb the knowledge cost when a human wrote every line, because the human who wrote it retained the reasoning. When agents produce substantially more of the implementation, that retention does not happen by default. Laycock puts the requirement plainly: “If agents are going to produce substantially more of the implementation, we need to be much more deliberate about maintaining human understanding…”

Her sharper line is the one to carry into your next planning meeting: “We need engineers to understand systems, not diffs.” That is the same constraint we described as comprehension being the bottleneck, arriving here as an org-design instruction rather than a diagnosis.

The Exception List

Move four jobs out and human review does not disappear. It gets a scope. Laycock publishes the criteria as a closed list of five conditions that warrant a human reading the code:

1. Architectural changes.
2. Changes that cross a security boundary.
3. Changes with a huge blast radius.
4. Code in a critical system the team is unfamiliar with.
5. Cases where the team explicitly says its confidence is low.

The fifth is the most interesting and the easiest to sabotage. It only functions if a team can declare low confidence without that admission costing anyone politically. Where low confidence reads as weakness, nobody declares it, and the criterion silently becomes a four-item list.

Note also what is not on this list: volume, seniority of the author, and whether the code was written by a human or an agent. The criteria track the risk of the change, ignoring the provenance of the keystrokes. A team that adds “anything an agent wrote” as a sixth criterion has abandoned review by exception. It has renamed universal review and given it a permissive-sounding label.

Why This Is More Governance

The pitch sounds like a request to review less. Read the redistribution again and it is the opposite. Under the current model, one checkpoint carries five obligations and discharges the administrative one. Under review by exception, five obligations get five mechanisms, four of which run continuously rather than once at the end.

That is more control surface. It is also more expensive to set up, which is the real reason teams do not do it. Pairing costs calendar time. Whiteboard design sessions cost calendar time. Fitness functions cost engineering time to build and maintain. Review by exception is cheap only after those investments exist. Adopting the exception list first, without the four destinations, produces exactly what its critics predict: less review and nothing in its place.

This is also where the acceleration whiplash pattern bites. The generation side gets faster in a week. The verification side needs quarters of practice change to keep up. Announcing review by exception on Monday and building the fitness functions “later” inverts the sequence.

Do This Now

Take your last twenty merged pull requests and sort them against Laycock’s five criteria. Count how many qualify. Then look at what the rest received human review for: the process requiring it, or the change warranting it.

Then ask the harder question about that majority: which of the five jobs did that review actually perform? If the honest answer for most of them is “it assigned ownership,” you have a signature workflow, and you are paying senior engineering attention for it at a moment when that attention is the scarcest thing you have.

For each of the four displaced jobs, name the practice that will take it and the date it starts. A destination without a date is just intent, and the queue will keep filling.

---

This analysis synthesizes Maybe We Shouldn’t Be Reviewing All This Code (Rachel Laycock, CTO at Thoughtworks, September 2026).

Victorino Group helps engineering organizations redesign review and verification practice for agent-scale output. Let’s talk.