A Human Reading the Diff Is Not a Review Policy: Scaling Approval for Agent-Written Code

Most engineering organizations wrote their code review rules for a world in which a person typed the change and a colleague read it. The rule was usually short: every change needs an approving human. That rule now meets agents that open changes faster than anyone can read them, and the organization has two bad options. It can hold the rule and let review queues become the bottleneck, or it can keep the rule on paper while approvals turn into a click. Neither one is a control.

The way out is to stop treating “a human read the diff” as the goal. It is a proxy for something else, which is whether the change is likely to hurt anyone and whether a check that could catch the problem actually ran. This article argues for a review policy built on that second question: approval scaled to risk, evidence attached to every change, and a small set of guardrail numbers that tell you when to tighten the rules again.

What the volume does to the old rule

The Claude Code team’s account of how it does code review, published October 15, 2026, is unusually specific about this shift, and it is worth reading with its source in mind: it describes the vendor’s own practice, with its own measurements. The team reports that Claude writes about 90 percent of Claude Code’s code, that merged pull requests more than doubled between June and September, and that the share of changes later reverted fell by more than 40 percent over the same months. Anthropic’s separate engineering post on redesigning source control reports its monorepo going from about 2,500 merged changes a day in May to more than 30,000 in September. That second figure covers the whole monorepo and is not a review statistic.

The independent evidence is thinner and more mixed. A LeadDev report summarized in April 2026 found that 29 percent of respondents say reviews take longer with AI, 24 percent report time savings, and 47 percent see no change. Among those who require fully manual review of AI-written code, 38 percent spend more time on review than before. The article does not state a sample size or question wording, so treat those as directional. Sonar’s January 2026 survey release reports that 96 percent of more than 1,100 developers do not fully trust AI-generated code to be correct while only 48 percent always check it before committing. Sonar sells verification products and the release gives no methodology, so the framing serves its business as well as the reader.

Put the two together carefully. They do not show that review is failing everywhere. They show a gap between how much people distrust the output and how consistently they check it, and a mandatory-reading rule that costs real time without evidently closing that gap.

Review is a set of checks, and a person is one of them

The Claude Code team makes the move that matters most: it stops asking whether a human read the code and asks what could go wrong with this change and which check, automated or human, should catch it. That reframes a review policy as a list of risks mapped to checks, with people assigned to the checks that need judgment.

Under that framing, a person adds value in places where a tool cannot: whether the thing should be built at all, risky code such as billing or deployment pipelines, architecture that other code will copy, and accountability for what ships. A person adds little when the diff is a docs change behind a flag. The Claude Code team lists the same split, and it keeps one rule that is easy to miss: an agent’s approval never counts as a person’s, and the person who prompted an agent counts as a required reviewer.

The team’s stated goal is also worth copying because it contains its own brake. It optimizes for the least human review time that does not raise reverts or incidents. Human approvals per change and wait time are the savings metrics; revert and incident rates are the guardrails. If the guardrails rise, human time was moved, not saved.

An illustrative approval policy

Here is what such a policy can look like as configuration. This is an illustrative scenario that we composed for this article, not a description of any client or of Anthropic’s actual system. The thresholds are placeholders to be set from your own incident history.

# approval-policy.yaml (illustrative)
tiers:
  low:                       # docs, copy, additive change behind a flag
    human_approvals: 0       # only after every automated gate is green
    requires: [ci, security_scan, rollback_note]
  medium:                    # ordinary product change
    human_approvals: 1       # the prompter of an agent counts as this person
    requires: [ci, security_scan, test_evidence, rollback_note]
  high:                      # auth, billing, deploy config, shared libraries
    human_approvals: 2
    requires: [ci, security_scan, test_evidence, rollback_note, owner_review]

classification:
  by: change_contents        # paths and diff, never the author's identity
  escalate_if_any: [touches_ci_workflows, touches_owned_sensitive_path]

approvals:
  bot_approval_counts_as_human: false
  dismiss_on_new_commit: true      # an approval covers one specific commit

review_loop:
  max_agent_rounds: 3              # then the author must reconsider the approach

guardrails:                        # the brake on everything above
  revert_rate_increase: tighten_one_tier
  incident_in_low_tier: reclassify_the_path

Each block answers a specific failure. Classifying by contents and not by author stops a trusted name from carrying a risky change through a light path. Dismissing approvals on new commits stops a person from approving one version and shipping another. The round cap exists because of something the Claude Code post documents candidly: one change went through more than 50 review-and-fix rounds overnight, and about 59 percent of what the reviewer kept flagging predated its first pass, so later rounds were finding old problems, not new ones.

Where the risk really is, and the loop that hides it

Three failure modes show up in the sources, and each one sits behind a reasonable-looking policy.

The first is a reviewer that is confident and wrong in the same way as the author. The Anthropic engineering post calls adversarial model review “incredibly effective” and also “myopic”: in one example a review fixated on a hypothetical trust problem and the agent added excessive validation, so engineers had to steer it back. Separately, an EMNLP 2025 paper on self-preference reports that language models acting as judges tend to favor their own responses. That study measures judgments in general and not code review specifically. Our inference, not a result from that paper, is that a reviewer drawn from the same model family as the author can share its blind spots, so for high-risk tiers it is safer to rely on deterministic checks, tests, and a person than on a second reading by a similar model.

The second is noise that costs more when the author is an agent. A human author can ignore a nit. An agent author makes another commit, which triggers another round. The Claude Code team tracks how authors respond to each comment (fixed, wrong, intentional, or did not matter), drops style and cleanup findings, and runs the reviewer against its own past incidents and reverts to score changes. Their numbers on internal changes are encouraging but self-reported: passing after one review-and-fix round rose from 65 to 78 percent, and changes needing five or more rounds fell from 8.9 to 1.5 percent. The method is the transferable part. Treat your reviewer as a system you evaluate against your own history, not as a purchase.

The third is review demand that is concentrated in a small share of changes. An MSR 2026 paper on 33,707 agent-authored pull requests reports that 28.3 percent merged instantly, that agents often fail at iterative refinement and abandon changes after subjective feedback, and that a model built on simple creation-time signals such as file types and patch size separated the expensive tail with an AUC of 0.96. With a review budget of 20 percent of changes, it captured 69 percent of the high-effort ones. These are the authors’ own results on their dataset, and they come from open-source repositories, so a private codebase will behave differently. The finding to take is the shape: effort is uneven, and cheap signals can route attention before anyone reads a line.

How to roll this out without a leap of faith

The surest way to lose trust is to loosen review on a Friday and find out why on a Monday. The Claude Code team’s own advice is to start strict and loosen with evidence, and the same discipline applies to any organization with ordinary constraints: a few repositories, a platform team of two or three people, and an incident history that is mostly in someone’s memory.

Start by measuring before changing. For one quarter, record for each repository the median and 95th-percentile number of human approvals per change, the time a change waits for a person, and the revert and incident rates. Without that baseline you cannot tell later whether human time was saved or only displaced.

Then write the tiers from your incidents, not from a template. List the last year’s reverts and outages, find the paths and change types they came from, and put those in the high tier. This is also the seed of a reviewer test set: past incident changes plus their fixes, confirmed by engineers who know the code, against which any automated reviewer is scored before it is trusted with approvals.

Pilot on one repository with low-tier changes only. Require attached evidence (test output, a rollback note), cap agent review rounds, and keep the guardrail numbers on a visible dashboard. Move a path down a tier only when the guardrails stay flat for a defined period, and move it back up on the first incident.

One gap deserves honesty. The Claude Code team states that it has no circuit breakers yet that tighten approval automatically when revert or incident numbers rise, and that engineers want them before more code moves to zero-human merges. If the team that built the tooling is not there yet, most organizations should expect to operate that brake by hand, with a named person who reviews the guardrail numbers weekly and can change a tier without a committee.

When this is more than you need

If a single team owns a small codebase and changes arrive at a pace people can read, the old rule is fine, and a tiered policy adds configuration without adding safety. If your regulator or contract requires a named human approval for every change, the tiers still help you decide what that person should look at, but they cannot reduce the number of approvals. And a tiered policy is only as good as its classification: a path missing from the sensitive list will sail through the light lane, so someone must own that list.

If your teams are merging more agent-written code than anyone can read, we help engineering organizations define risk tiers for change approval, evaluate automated reviewers against their own incident history, and set up the revert and incident guardrails that show when to tighten the rules. Talk with us about your code review and merge controls.