AI-assisted teams can produce code faster than humans can realistically review it. That turns a familiar pull-request bottleneck into a structural problem: if most feedback arrives only after implementation is finished, the checkpoint comes too late for many of the things teams expect code review to provide.
Rachel Laycock makes that argument in a recent piece on Martin Fowler's site, written in response to Brian Houck of DX. Houck argues that moving away from code review risks losing things teams currently rely on it for: bug-catching, knowledge transfer, mentoring, collective ownership and architectural alignment. Laycock agrees those outcomes matter. Her challenge is whether end-stage pull-request review is really the best place to achieve them.
The figures cited in the piece, attributed there to Houck, are worth noting as reported rather than treated as settled fact for your own team: at Meta, significant lines of code per human-landed diff reportedly rose 106% in a year, and DX's own data reportedly showed median pull request size up 64%. Whatever the exact numbers at your organisation, the practical pressure is clear: as AI-assisted development increases the volume of code moving through a team, end-stage human review can become the bottleneck.
Why the checkpoint arriving late is the actual problem
The piece's core move is to unpack what people mean when they say "we need code review" and ask, for each thing on the list, whether review is really the best point at which to get it:
- Finding bugs — better caught by automated tests, static analysis and fitness functions running continuously, not by a human reading a diff once.
- Exploring alternative designs — better done before something is built, not after, when the only alternative on the table is "approve this or send it back."
- Knowledge transfer — better achieved by pairing or working alongside someone while they reason through a problem than by reading their finished solution.
- Collective ownership — better built by teams that design and operate software together than by a pull request notifying everyone what one person already did.
- Architectural alignment — better achieved by designing together up front, with the important constraints then encoded as fitness functions that run continuously rather than argued about after the fact.
None of this is a case that nobody should ever look at anyone else's code. It's a case that a single end-stage gate has been asked to do the work of several different mechanisms, and each of those mechanisms works better earlier and in a different form.
What moves earlier, and what still gets reviewed
If you're restructuring a team's process around this, the practical shift isn't "remove review" — it's "review by exception" against a baseline of continuous, earlier feedback:
- Deterministic things — formatting, linting, known security issues, anything you can test — get automated rather than argued about in a PR thread.
- Design conversations happen before implementation: a whiteboard session, a pairing session, or an agreed shape for the increment, rather than being reconstructed from a finished diff.
- Architectural constraints get encoded as fitness functions that run against every change, not re-litigated by a human reader every time.
- Human review is reserved for the cases where judgement genuinely earns its keep: a fundamental architectural change, something crossing a security boundary, a change with a large blast radius, unfamiliar territory in a critical system, or simply a case where someone on the team says plainly "I'm not confident about this."
That last category matches the site's own view on when a professional review is warranted, covered separately in When You Should Get a Professional to Look at AI-Generated Software: the trigger is what happens if the software is wrong, not a fixed rule that every change gets the same scrutiny.
The piece is explicit that the wrong answer is putting an AI agent in the reviewer's seat to approve human-authored-looking diffs at higher speed. That preserves the ceremony without asking why the ceremony existed, and doesn't solve the volume problem — it just moves the bottleneck.
Where this connects to working in small increments
This is a team-process argument, but it lands on the same ground as the PDAID discipline of building in the smallest useful increment (see Why the Smallest Useful Increment Beats the Smallest Increment). A pull request is unreviewable at volume partly because of scale, but also because of shape: a diff that bundles several decisions together forces a reviewer to reconstruct intent from the finished result. An increment where Purpose and Behaviour were agreed before Build, and where the acceptance checks were settled in advance, gives a reviewer — human or automated — something concrete to check the result against, rather than something to interpret from scratch.
The same applies to the record you keep as you go. A Stable Baseline Record or a completed AI Development Test Record is closer to the "continuous verification" the piece describes than a PR approval is: it states what was checked and what was expected, at the point the work happened, rather than asking a reviewer to reconstruct that days later from a diff.
What this doesn't change
The piece is candid about one open risk in its own argument, raised against it by Houck: as agents produce more of the implementation, teams can accumulate what he calls cognitive and intent debt — the software grows while the humans responsible for it understand less and less about why it works. The author agrees the risk is real but argues that a mandatory PR gate was never much of a defence against it either. Their answer is that maintaining human understanding has to be deliberate — through collaborative design, pairing, clear boundaries, executable constraints and shared operational responsibility — not assumed to follow automatically from the fact that someone once approved a diff.
For a team adopting AI-assisted development, the practical takeaway isn't "stop reviewing code." It's to ask, for each thing you currently rely on code review to give you, whether it would actually happen earlier and more reliably if you built it into design, pairing, automated checks and agreed acceptance criteria — and to keep human review for the specific changes where judgement, not ceremony, is what's needed.