Removing the Human From Code Review: How to Let Machines Own the Merge

Nish · September 7, 2026

Agents   Essay
24 min read

It is Monday morning on a team that switched to coding agents about six months ago. While everyone slept, the agents opened a dozen pull requests. Two engineers are on review duty this week, and each PR is a few hundred lines they did not write and only half understand. By lunch they have approved four, skimmed three, and asked the rest to wait. Out in the pipeline the agents sit idle, because every loop they run ends at a person, and the person is busy. This team writes more code than it ever has. It ships barely faster than it did last year. And the two people on review duty are quietly the unhappiest engineers in the building. If any of that sounds familiar, this post is for you.

Here is what I want to convince you of. The person reading every diff before merge has become the most expensive check in your pipeline, and it has stopped being a reliable one. Every job that reviewer does can be handed to something better suited to it. The mechanical checks go to tools that simply pass or fail. The judgment calls go to review agents built for one question each. The decision about what is allowed to merge moves upstream, to a person who writes the rules once instead of reading every change forever. The human does not leave the loop. They leave the per-diff loop. Do this carelessly and you will ship bugs at scale. Do it well and a five-person team can keep a dozen agents busy while trusting what merges more than they do today, because the trust comes from checks they designed rather than from a tired skim at four in the afternoon.

I am not the first to say this. In April 2026 a podcast host asked Robert Martin, Uncle Bob to most of us, how anyone could properly review a 500-line agent PR in a codebase they did not know. His answer was that he does not try: “I don’t review code written by agents. I measure things like test coverage, dependency structure, cyclomatic complexity, module sizes, mutation testing, etc.”1 By July he had stopped reading any of the code his agents write. What he does instead is surround them with what he calls “extreme constraints”, so that whatever reaches him has, in his words, “run the gauntlet”. I find that position more convincing every month, and this post is my attempt to work out what has to be true before a normal team can adopt it. It builds on three earlier posts of mine. The one on working with coding agents argued for reviewing by risk and for letting a fresh agent review what another agent wrote. The one on goals and loops showed that an agent loop is only as good as the outside check that ends it. And the dividend is not speed traced how cheap code generation pushed the bottleneck onto review. This post is the next step: taking the person out of the check itself.

The gate is already failing

Let me start with the uncomfortable part, which is what the human gate actually does today. If it still worked, the case for removing it would be much weaker. It does not work, and we have the numbers to prove it.

Faros AI tracked more than ten thousand developers through 2025 and found that teams leaning hard on AI merged nearly twice as many pull requests. Good news, until you read the next line: time spent reviewing each one rose by 91%, and the average PR grew by more than half again.2 Their 2026 follow-up, this time on 22,000 developers, is bleaker. The typical change now spends more than five times as long in review as it did two years ago. Meanwhile the share of PRs merged with no review at all rose by almost a third, and incidents per PR more than tripled.3 Read those together and the picture is clear. Review did not get more careful under the load. It got slower and it got skipped, at the same time.

The attention that survives is thinning too. A study published in June 2026 followed 400 reviewers who kept reviewing agent-written pull requests for seven months. Over that time they approved more, commented less, and took longer to respond.4 The authors do not think the reviewers learned to trust the agents. They think the reviewers got used to the flow and started looking less. Another study of AI-generated PRs found that most receive no human review at all, and when someone does review them, that someone is usually another AI.5 Blake Crosley described the end state in one line I keep coming back to: “A human who approves because the code looks correct and the tests pass is not reviewing. He is signing.”

So this is the loop most of us are actually running. Every change waits for a person. The person signs more and reads less. The waiting is now the single biggest cost in the pipeline. We have kept the gate in name, which keeps the queue, and lost the scrutiny, which was the whole point. That is the worst of both worlds, and it is where most teams are sitting right now.

What the reviewer was for

Before you hand someone’s job to someone else, it is only fair to write down what the job was. Google’s engineering guide tells reviewers to check the design, the behaviour, the complexity, the tests, the names, the comments, the style, the consistency, and the documentation, and then to look at every line. The Google engineering book explains why the ritual exists at all: correctness, understanding, consistency, sharing knowledge, and a culture where anyone’s work can be questioned. It is a long list. Reading it next to what tools and agents can now do is what turned this from a hunch into an argument for me.

The list falls into three groups. The first group could always have been done by a machine, and honestly should have been: style, formatting, naming rules, complexity limits, whether tests exist and what they cover, whether the dependencies point the right way. Linters and metrics do these better than any of us, and a reviewer who spends attention here is spending it badly. The second group needs judgment but stays inside the change: does the code do what the ticket asked, is there a security hole, did it quietly weld two modules together that should stay apart. Review agents are being built for exactly these questions, and we can measure how good they are, which we will do in a moment. The third group is not about code at all. It is about people: understanding, sharing knowledge, culture. A merge gate was never a good way to get those, even when humans had time for it. As Swarmia’s Miikka Holkeri points out, code review was never much good at catching what actually breaks production, which is usually two components interacting in a way no diff can show you.

So the case for taking the human out of the per-diff gate is not a case that review stops mattering. It is a case that the first two groups can be done by machines well enough to merge on, and that the third group deserves a proper replacement rather than a gate that stopped delivering it a while ago and never told anyone.

Three layers that replace the diff read

Here is what the loop looks like once the person steps out of it. Each layer catches a different kind of mistake, and the order matters: cheap checks that always give the same answer come first, expensive judgment comes second, and a written policy decides what the first two mean.

Two merge loops. Top: a coding agent opens a pull request that waits in a review queue for a human who reads the diff and then merges. Bottom: a coding agent's change passes through mechanical gates, then agentic review, then a written policy that either auto-merges or escalates to a person; the human sits upstream, supplying the spec, acceptance tests, and merge policy.
Today's loop (top) makes every change wait for a person, whatever its risk. The layered loop (bottom) lets mechanical gates, specialised review agents, and a written policy decide. The human writes the spec and the policy upstream and only sees the changes that escalate. Throughput moves from reviewer hours to compute and policy.

Layer one is mechanical. These checks are not opinions. They pass or they fail, and a machine can block a merge on them with nobody watching. Tests, type checks, linters, formatters: you have most of these already. Behind them sit the numbers Martin reads instead of code: coverage, complexity with a hard ceiling, module size, dependency direction, plus security scanners and licence checks.6 But the most important gate in this layer is the one almost nobody runs, and it is called mutation testing. A mutation tool makes small deliberate breaks in your code, flipping a comparison here, deleting a line there, and reruns your tests after each one. If no test fails, that break is a “surviving mutant”, and a surviving mutant is proof that your tests would sleep through a real bug in that exact spot. Google’s engineers wrote in 2018 that “coverage alone might be misleading, as in many cases where statements are covered but their consequences not asserted upon”. By 2021 their version was part of mandatory code review for more than 24,000 developers, and it shows reviewers only the surviving mutants on the lines that changed.7

Why does mutation testing matter so much more now? Because of a failure that is specific to agents. When the same agent writes the code and the tests, the tests have a way of confirming whatever got built rather than whatever was asked for. Birgitta Böckeler watched agents do test-driven development inside their own loop and put it perfectly: “When the agent both writes the test and confirms it failed, a red test tells you the agent ran it and saw failure, not that the failure was for the right reason.” Worse, anything the agent never thought to test never got built at all. Kent Beck has watched agents delete a failing test just to get back to green. Coverage cannot see any of this. Mutation testing can, because a test that checks nothing kills nothing. Martin runs it twice over. One pass mutates the code. The other mutates the acceptance scenarios themselves, changing the example values in the Gherkin and expecting the generated tests to fail.8 A suite that survives both has proved, mechanically and without anyone reading it, that it checks the behaviour a person actually asked for.

Layer two is agentic. This is where the judgment calls go, and the first rule is not to use one general-purpose bot that comments on everything. Use several reviewers with one job each. Give each of them a fresh context that sees only the diff and what the change was meant to do. One checks the change against the spec. One hunts for security problems. One watches architecture and coupling. If an agent wrote the change, add one more that reads that agent’s transcript, not just its output, because the transcript is where the shortcuts show. Keeping the writer and the reviewer apart was the strongest idea in my earlier post on working with agents, and it is the same idea behind the separate grader that makes goal loops work. Kieran Klaassen ran thirteen review agents at once on a change that touched 27 files and a thousand lines, and finished with fifteen minutes of decisions instead of an afternoon of reading. The second rule is to verify before reporting. Anthropic’s Code Review sends agents out to hunt for bugs in parallel, then makes them check each finding to weed out false alarms before anything is ranked and shown. In Anthropic’s own use, fewer than 1% of findings turn out to be wrong, and the share of PRs getting a substantive review comment rose from 16% to 54%.9 Cursor’s Bugbot, once it could propose the fix as well as the complaint, raised the share of flagged bugs actually resolved by merge time from 52% to 76%.

Now the honest numbers, because they are the reason this is one layer and not the whole answer. Martian’s independent benchmark scores AI reviewers on whether developers actually act on their comments on fresh public PRs. The leading tools land between 51% and 61% F1, with recall around half. In plain terms, they catch about half of the issues that matter.10 On a separate benchmark of planted security flaws, commercial models caught 89 to 96%, and the best setup, which cross-checked each finding against a static analyser, reached 96.9%.11 That last result is the whole design in one number. The agentic layer works best sitting on top of deterministic tools, not standing in for them.

Layer three is policy. A person writes it. A machine runs it. This is the layer where your thinking has to change, so let me spell out what a policy actually says. For each change it answers one question: given that the mechanical gates passed and the review agents said what they said, may this merge without a person looking? Macroscope’s approvability model splits that into three smaller questions. Who owns this code? What kind of change is it? Did anything serious survive review? Their default auto-approve list is documentation, tests, code behind a disabled feature flag, simple fixes, mechanical edits, and small CI changes. Their always-escalate list is schema-breaking changes, anything touching security, authentication, billing, or sensitive data, major refactors, production infrastructure, and the feature-flag logic itself. Their tie-breaker is the sentence every policy should end with: “if there’s any doubt about scope or side effects, defer to a human”. Notice what decides the tier. It is the blast radius of the change, not the line count.

None of this is new in kind, which is comforting. Google’s tool for sweeping changes, Rosie, breaks one enormous change into thousands of small ones and lets “global reviewers” auto-approve every piece that matches a pattern, rather than reading each one.12 Dependabot’s documented auto-merge flow only fires when the update is a patch version and the required checks pass, and Will Larson’s advice for it applies to everything in this post: it works well when CI already blocks on linting, typing, and tests. Then, on 1 September 2026, GitHub shipped the platform-level version. An administrator can now let Copilot’s review approval count toward a repository’s required-approvals rule.13 The branch-protection rule that used to mean “a person looked” can now be satisfied by a machine, on purpose, by someone who chose it.

Where the person goes

Taking the human out of the diff read only works if their attention lands somewhere more valuable, and the people doing this agree on where that is. Martin’s pipeline is the clearest published example, so let me walk it. He writes rough specifications by hand. An agent turns them into firmer tasks, and he reviews those. A specifier agent turns each task into Gherkin, and he spot-checks it. From there a coder agent writes acceptance tests, unit tests, and code. A refactorer agent brings complexity and duplication under his limits and adds property tests. An architect agent runs both kinds of mutation and fixes every surviving mutant. He describes the whole thing as “transformations from the informal to the formal through managed stages, with human interaction decreasing with each stage”, and adds, almost as an aside, that raw computer power is now his limiting factor. Not review. Compute.14 In his open-source harness the one hard human gate is the operator approving the specifier’s output before any code exists.

That is the shift in thinking, and it is bigger than a tooling change. The old basis for trust was “I trust this code because I read it.” The new basis is “I trust this code because it survived checks I designed, and it would have failed them if it were wrong.” Cory House summed up what his readers converged on as “Don’t review code. Review decisions.” Addy Osmani says the human does not leave, the human moves up a level. Qodo’s Itamar Friedman says the reviewer’s new material is rules, quality workflows, and agent transcripts rather than lines. Upstream, the person owns intent: the spec, the acceptance criteria, the architecture rules, the merge policy. Downstream, the person owns exceptions: the escalations, the production signals, and regular audits of the gates themselves. That last job is not optional, and I want to be blunt about why. Any number that becomes a gate will be gamed, by people and by agents alike. Tell an agent to raise coverage and it will cheerfully add tests that check nothing. Mutation testing is the gate instead of coverage because it is much harder to satisfy without doing the real work. But nothing is impossible to satisfy, so someone has to keep checking that the gates still measure what they were built to measure.

Now look at what this does for the two engineers from the opening scene. They stop being interrupted a dozen times a day by diffs they never asked to see. The changes that reach them are the ones a written policy decided were worth a person, with the mechanical noise already gone and the review agents’ findings already checked and ranked. Klaassen’s title for his account of making this change was that he stopped reading code and his reviews got better. That is the better experience, and it comes from the same design as the higher throughput. You do not trade one for the other. You get both, or you get neither.

Doing it in stages

Nobody should flip a switch on this. The rollout that works treats every widening of auto-merge as an experiment with a number attached, and the number is the escape rate: how many bad changes got through.

Start by being honest about your harness. If the repository has thin tests, no type checking, and a CI that advises rather than blocks, the layered loop has nothing to hold onto. Your first job is to build those basics, which my earlier post on working with agents covers. Mutation testing is a good place to begin, because it tells you the truth about the suite you already have. Run it once and count the survivors before you let a green build mean anything.

Then write the policy before you automate any of it. Sort your kinds of change into tiers the way Macroscope does, and keep the always-escalate list long at first. A workable first policy looks like this.

  • Auto-merge when the mechanical gates pass, including mutation testing on the changed lines, the review agents report nothing above your severity threshold, the change touches no protected path, and it adds no new dependency.
  • Escalate when the change touches authentication, payments, schemas, migrations, or deployment infrastructure, when the mutation score on the changed code drops, when the review agents disagree with each other, or when the diff is much bigger than the ticket asked for.
  • Make gate-readiness the author’s job. Whether the author is a person or an agent, a change that arrives with failing gates does not get reviewed. It gets sent back. This is what Cory House’s five-second check script does inside his agent loop, and it is what keeps the queue empty.

Open the first tier on the kinds of change other people already auto-merge: dependency patches, documentation, test-only changes, mechanical refactors. Measure reverts, incidents per merged change, and the trend in mutation score for that tier. After a month, if the tier’s escape rate is no worse than what human review was achieving, widen by one tier. And be fair about the comparison, because the baseline is a gate that already skips a third of what passes through it. Keep the escalation path real, too. A person who gets an escalation should receive the checked findings and the policy’s reason, not a raw diff. Otherwise you have rebuilt the old queue with extra steps and a nicer name.

The measure that matters at the end is not PRs per week. It is the time from an agreed intent to a change running in production that you trust, with the reviewers’ calendar no longer part of that time.

What could go wrong

The counterarguments are serious, and most of them are right about today’s general-purpose tools. Dex Horthy, replying to Martin, wrote that “no amount of deterministic linting and ai code review will make it feasible to stop reading the code entirely.” Böckeler, after building maintainability sensors for her own agents, concluded they are “not a magical solution to take the human totally out of the loop.” Anthropic says its reviewer will not approve PRs because that is still a human call. OpenAI’s Codex documentation warns that review rules do not replace branch protections or required approvals. Georgia Tech researchers confirmed 74 vulnerabilities introduced by AI-generated code in public advisories in early 2026, fourteen of them critical, and a study of 675 security-related AI pull requests found that many flawed ones were merged anyway.15 DORA’s 2025 report found that AI adoption goes with higher throughput and still goes with lower delivery stability.

Read them carefully, though, and every one of these is an argument against “let the AI read the PR and ship it.” None of them is an argument against the layered loop. DORA’s own explanation of its stability finding is the best case for it I know: “Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.” The layers are the control system. Where the critics are right is about scope. This fits well-specified, testable systems with a harness worth trusting. It is a poor fit for new product work where the judgment is the job, for domains where a wrong merge can hurt someone, and for codebases where nobody has yet written the tests the gates would run.

The loss that is hardest to measure is the human one, and I do not want to wave it away. The Google engineering book lists knowledge sharing as a core purpose of review. A recent paper argues that agent systems “passively incentivize the degradation of the very human skills they rely on.”16 My earlier post on the AI dividend made the same point through Peter Naur: a program is the theory its builders hold in their heads, and a team that stops reading its own system stops holding that theory. So if review was how understanding spread on your team, replace it on purpose. Review the specs together. Read the escalations together. Pair on the architecture rules. Do not let it disappear along with the queue. The layered loop takes the person out of the per-diff read. It does not take them out of understanding the system, and a team that confuses the two will find the second loss arriving quietly, and late.

The gauntlet

Back to that Monday. The dozen overnight pull requests still exist, but most of them never became anyone’s problem. They passed the mechanical gates, survived mutation testing, were read by three specialised review agents that checked their own findings, and matched a policy the team wrote and can change whenever it likes. Two escalated. One touched a migration. On the other, the review agents disagreed, which is exactly the kind of thing a person should see. Both arrived with ranked findings and a stated reason. The two engineers on review duty spent the morning on next week’s spec and an hour on the escalations, and went to lunch on time. The agents never waited.

Writing code has become cheap. Confidence in code has not, and it never will be free, because confidence has to come from somewhere. Martin’s word for where it comes from is the gauntlet: the constraints and tests his agents must pass before he believes them. The job of an engineering team is now to build that gauntlet, to keep checking that it still measures what it should, and to spend human attention only on what comes out the other end still uncertain. That is not removing people from quality. It is putting them where quality is actually decided.

Sources & further reading

  1. Reply on X, 14 April 2026, to a question from the Wookash Podcast about reviewing a 500-line Claude Code PR. The July line comes from a reply on 23 July 2026 that reached several million views. Both are linked in the sources. ↩

  2. Faros AI, “The AI Productivity Paradox Report”, July 2025, from telemetry on 10,000+ developers across 1,255 teams: 98% more PRs merged, 91% longer review time, 154% larger PRs. These compare teams with different levels of AI use, so they are associations, not a randomised trial. ↩

  3. Faros AI, “AI Engineering Report 2026: The Acceleration Whiplash”, April 2026, covering 22,000 developers and 4,000+ teams over two years: median time in review up 441.5% (mean up 199.6%), PRs merged without review up 31.3%, incidents per PR up 242.7%. The 441.5% figure is often quoted without its source; it is the median from this 2026 report. ↩

  4. Yu et al., “Habituation at the Gate”, arXiv, June 2026, on 11,429 reviews from the AIDev dataset: approval rate up from 30.1% to 36.8%, inline comments down 22%, response time up 3.5 times. The sample is open-source projects, where reviewer time is scarcer than on most paid teams, so the size of the effect may differ. The direction is hard to argue with. ↩

  5. Duma et al., “These Aren’t the Reviews You’re Looking For”, arXiv, May 2026. ↩

  6. Martin’s own limits, from his X posts: cyclomatic complexity below about 4 per function, and a CRAP score of 6 or lower. CRAP combines complexity with coverage, so complex code only stays cheap while it is well tested. ↩

  7. Petrović and Ivanković, “State of Mutation Testing at Google”, ICSE 2018, reported 6,000 engineers using the system on every change they wrote or reviewed. The 24,000-developer figure is from the 2021 follow-up, “Practical Mutation Testing at Scale”, by Petrović, Ivanković, Fraser, and Just. The two are often mixed up. ↩

  8. Gherkin is the plain-language “Given, When, Then” format for acceptance scenarios used by Cucumber-style tools. Martin has an agent turn each task into Gherkin, generate runnable tests from it, and then change the scenario values to confirm the tests really depend on them. ↩

  9. Anthropic, “Bringing Code Review to Claude Code”, March 2026. Both figures come from Anthropic’s internal use, so they describe a team that already has a strong test harness and is used to agent-written code. Anthropic’s product does not approve PRs; the layering in this post is what turns findings into a merge decision. ↩

  10. Greptile reported 60.8% F1 in July 2026 and CodeRabbit 51.2% in March 2026 on the same Martian Code Review Bench. The leader changed between the two runs while the range barely moved. This kind of benchmark measures whether comments get adopted, not ground-truth bugs, so treat the recall as an upper bound on how much of what matters gets caught. ↩

  11. Thornton, arXiv 2602.16741, February 2026: eight models, 9,366 trials, on a 100-sample vulnerability set. The set is small and the flaws are planted, so real-world recall will be lower. The ordering is the useful part. ↩

  12. Described in the “Large-Scale Changes” chapter of Software Engineering at Google, by Hyrum Wright. Each piece is atomic within one project and the approving tool is pattern-based, so this is a precedent for mechanical approval of a class of change, not for judgment. ↩

  13. GitHub changelog, 1 September 2026. The setting is off by default and the approval is dismissed when new commits land. That is the right shape for a first policy: opt in, per repository, revoked on change. ↩

  14. From his X post of 1 June 2026, and the README of his swarm-forge repository. The six-agent version he ran on 4 June 2026 used a specifier, coder, cleaner, architect, hardener, and QA agent. ↩

  15. Georgia Tech’s SSLab, April 2026, scanning 43,000+ advisories; and Rabbi et al., arXiv 2604.19965, April 2026. Both look at AI-written code in general, not code that passed a layered gate. That is the point: the failures come from pipelines that had no such gate. ↩

  16. Mitchell, Ghosh, and Passi, “AI Agents Push Humans Out of the Loop”, arXiv, August 2026. A randomised trial at Anthropic, discussed in the working-with-agents post, found the same effect for individuals: engineers who handed off code generation without asking questions understood the result least. ↩

Citation Information

If you find this content useful, please cite this work as:

Bhana, Nish. "Removing the Human From Code Review: How to Let Machines Own the Merge". Nish Blog (September 2026). https://www.nishbhana.com/Removing-The-Human-From-Code-Review/

Or use the BibTeX citation:

@article{bhana2026removingthe,
  title   = {Removing the Human From Code Review: How to Let Machines Own the Merge},
  author  = {Bhana, Nish},
  journal = {nishbhana.com},
  year    = {2026},
  month   = {September},
  url     = {https://www.nishbhana.com/Removing-The-Human-From-Code-Review/}
}

Related Posts 🔥

Career Progression for People Who Build Software
Careers Jul 2026
Your Prompts Were Written for the Last Model: What Changed With Opus 5 and GPT-5.6
Agents Jul 2026
Several Breakthroughs Away
Futures Jul 2026
The Dividend Is Not Speed: Steering a Team Through AI Coding Tools
Agents Jul 2026
Agent Memory: How AI Agents Remember, Forget, and Learn on the Job
Agents Jul 2026
Goals and Loops: Telling Your Coding Agent When It's Done
Agents Jul 2026

x.com, Facebook