How the Claude Code Team Does Code Review: Continuous AI Pre-Review Replaces the Human Gate

One boundary first: if you're here for the story of Anthropic's homegrown version control system Scion replacing Git — that's a different article, which VibeFix covered separately. This piece is about the same team's other half: how they review code when Claude writes about 90 percent of it.

On October 15, 2026, Anthropic published "How the Claude Code team does code review" on the claude.dev blog, authored by Addy Osmani, Morgan Westlee Lunt, and Qing Wang. Simon Willison picked it up and quoted its key passages on October 16. It's worth reading end to end, because it answers a question every AI-coding team will eventually face: when agents produce more code in a day than humans can read in a year, can the "human gate" of code review still hold?

The Claude Code team's answer: it can't, so they stopped trying. Review moved from an end-of-the-road gate — write the code, open a PR, wait for a colleague — to continuous AI pre-review running through the whole coding process. Their metaphor: it's now more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look.

The numbers: review was rebuilt under pressure

What drove the rebuild wasn't philosophy, it was volume. In Anthropic's monorepo, changes landing per day went from about 2,500 in May 2026 to more than 30,000 in September — a 12x jump in four months. Claude Code's own separate repository is under steep pressure too: from June to September, merged pull requests more than doubled, while the share that had to be reverted fell by more than 40 percent.

Note the combination: merge volume doubled while revert rates dropped sharply. The goal was never "move fast by relaxing review" but "less human time per change, with quality held or improved." The post pins down the metrics up front: human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail — if those rise, the saved human time is fake; the cost just moved from "review time" to "fixing production incidents time."

That's a measurement framework worth stealing. A solo vibe team doesn't need a dashboard this heavy, but everyone who lets agents write code should periodically ask: has the review time I saved turned into bug-fixing time?

The core judgment: "did a human read the code?" is a crude proxy

The sharpest line in the whole post: "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check — automated or human — is the right one to catch it?"

This splits review's purpose into two independent jobs: first, find and fix issues before they ship; second, build shared context and codebase understanding across the team. The traditional process bound both jobs to the same human step: a colleague reading the diff line by line, hunting bugs while incidentally learning what the codebase looks like. In the agent era, that binding dissolves — the bug-hunting part can go to machines, and the "spreading understanding" part needs a different answer (the post addresses it in the second half, more below).

Once you accept that human line-by-line reading is a means rather than the goal, review changes shape: no longer a gate at the end, but continuous pre-review. Spellcheck runs while you write and flags mistakes on the spot; the Claude Code team's review now sits in the same position.

Six layers: the gate was rebuilt as a pipeline

A change travels from an engineer's laptop (or a Claude session in Slack) to users through six layers of checks, with fast rollback underneath:

Layer 1: the work is verified before anyone else looks

Most review now happens before a PR exists. They give Claude something it can run — tests, a build, a screenshot to compare against the design — and ask it to show the output instead of saying it's done. Then a subagent with fresh context reviews the diff. Both habits come from their own best-practices guide.

Many engineers also run internal skills before opening a PR: one hunts for bugs, one simplifies the diff, one checks behavior end to end; UI changes get checked against design guidelines. Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results — he estimates it makes the final result two to three times better. Verification looks different in each domain: a bash command, a test suite, or actually running the app in a browser or phone simulator.

A key operational detail: when the automated reviewer keeps flagging the same thing, they fix it at the source — in the skill, with a lint rule, or with updates to instructional files like CLAUDE.md and REVIEW.md. CLAUDE.md tells Claude what the project is (stack, conventions, goals and non-goals); every review loads it, so in a large codebase it's kept short and points to other docs. The reviewer also flags code that breaks a convention in it, and changes that make a line in it out of date. REVIEW.md, written by code owners, says what matters in their part of the code — the good ones are short: what failure looks like in that repo ("it lies" for docs, "it misroutes" for config), a cap on nits, paths to skip, and a demand for file-and-line evidence instead of a guess from a name. They also ask for a summary that starts with a count and says plainly when there's nothing to fix.

Layer 2: AI review on every pull request

Every PR gets a Claude review before a person looks: it reads the diff against the whole repo and the PR's stated intent, asking three questions — does the change solve its problem, fit the system, or break something else? The public version, "Code Review for Claude Code," is now generally available on Team and Enterprise plans; /code-review runs a lighter version locally.

The research-preview numbers are telling: the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings; most small ones come back clean. Admins set each repo to Quick, Standard, or Deep — Deep is worth it where one missed bug costs more than the extra review time.

The findings pipeline matters more: several agents hunt for bugs simultaneously, then a separate group votes on each finding, and it only gets posted if enough of them agree it's real. Findings that are only about style, diagnostics, or cleanup get dropped — those filters were A/B tested on their own PRs before being kept. What survives shows up as inline comments sorted by severity, each tagged Important, Nit, or Pre-existing (so a bug the PR didn't introduce doesn't look like the author's fault). Every finding has to be answered: fix it or resolve the thread with a reason. Often an agent picks up the fix overnight, so the author returns to a PR that's already been through another round.

Layer 3: security review that can block

Security gets its own automated review. A PR can't merge while any finding from the bug review or the security review is still open: fix it or close the thread with a short reason (that's how false positives get cleared). If a later commit fixes the issue, the finding clears on its own. The open-source security review GitHub Action or the /security-review command sets up the same thing.

Layer 4: automated checks that block

The usual: lint, type checks, tests on every platform, a build. A typical CLI pull request may run dozens of checks before anyone looks at it. The PR template asks how the change was tested and how to undo it. Claude can fill that in, but the person who asked for the change signs off on it.

Layer 5: human approval, scaled by risk

The most copy-worthy table in the post:

• Low risk (docs, copy, internal-only features, additive changes behind a flag): no human approval required once automated review and security checks are green;
• Medium risk (ordinary product changes, plus sensitive areas like caching, the auto-updater, or system prompts): one person;
• High risk (the highest-risk code, plus a small set of paths that always need two people): two people.

Three rules are nailed down hard. First, the change sets the tier, not the author — a classifier reads the change and picks its risk tier; a second classifier asks whether this particular change needs another person even when its tier says it doesn't. Some paths always need a person: anything owners list as sensitive, and any CI workflow file. Second, only trusted authors get the lighter paths, and an agent's approval never counts as a person's — automated review can clear a low-risk change, but it can't fill a slot that calls for a human. Third, an approval covers one specific commit: if new commits land that the system can't vouch for — an agent's push, a hand-resolved merge — the approval has to be given again. And whoever prompted the change is on the hook for it: on an agent-written PR, the person directing the agent counts as one of the required reviewers, the same as if they'd typed the code themselves.

Layer 6: merge queue, flags, and fast rollback

The merge queue re-runs every check against main with the change applied, so two PRs that pass separately can't combine into a broken main. New behavior usually ships behind a flag to Anthropic employees first — their own heavy use often surfaces regressions before users do. Public releases go to the latest channel first; the stable channel trails it.

The last layer is fast detection and fast rollback: flags turn off without a deploy; a weekly on-call rotation; incident reviews that ask which layer should have caught the issue. They're candid that they don't yet have circuit breakers that tighten approval when revert and incident numbers move — engineers there want those before more code moves to zero-human merges. One colleague's line is worth remembering: slowing down does lower your error rate, but mostly because you're doing less of everything. They'd rather get faster at noticing and fixing problems.

The three passages worth reading closely: convergence, humans, context

1. Review has to converge: agent-vs-agent review spirals into 50+ rounds

This is the most battle-scarred passage in the post. An agent author and an agent reviewer can keep each other busy indefinitely: one CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it. Running git blame on what the reviewer kept flagging, they found about 59% was code that had been there since the reviewer's first pass — the reviewer was rarely finding new bugs, just a few more old ones each round.

And they made it worse themselves: they'd gotten used to running several rounds by default, since each pass catches something new. Worthwhile on a risky change, not on every PR. Now they track rounds-to-pass alongside recall, and changed re-review: a round cap — after three rounds, the reviewer asks the author to step back and reconsider the approach; diff-only re-review after the first few passes; flag the class of bug so the author fixes every instance, not one line; no repeats of findings already posted. Review agents also run nightly over existing code, catching old bugs before they show up somewhere else.

The direct lesson for vibe teams: if you let agents review each other, cap the rounds, or you're burning tokens on an infinite game of find-and-fix. Three rounds is a battle-tested starting number.

2. The five decisions that stay with humans

Freed from reading every diff in the small hours, senior engineers' attention moves to the decisions machines are bad at: should we build this at all (direction, taste, scope — one team that declared its review bottleneck solved still kept human review for changes from outside the team, so someone asks "should we even do this?"); risky code like billing, the auto-updater, and CI workflows; architecture that sets a pattern others will copy; reading the evidence — test output, the command that ran and what it returned, a screenshot, the reviewer's findings (if you can't say what the checks would miss, ask for a real review rather than a quick approval); and owning the outcome — whoever lands a change usually fixes it if something goes wrong; incident reviews look at the system, not for blame.

"Reading the evidence" deserves underlining: the AI-era reviewer builds confidence not by reading every line, but by knowing what the automated checks cover and what they don't, and deciding whether a deep look is warranted. It complements VibeFix's own guide on reading AI-generated code — which teaches you how to read — while this post tells you when reading is worth it.

3. Review's second job: if nobody reads diffs, how does the team share understanding?

With machines doing most of the reading, how does anyone learn the code? Their answer is blunt: there's no formal process, and nobody keeps a complete mental model of Claude Code in their head — nor should they. When someone wants to understand part of the codebase, they ask Claude to write an explainer for exactly that slice: it takes minutes and reflects the code as it is today. Some go further and have Claude build a small artifact that visualizes that part of the code the way that person likes to learn.

The argument: reading a one-line copy change teaches you almost nothing; an explainer for the module you're about to change teaches you a lot. Add a culture of defaulting to open Slack channels — you see what others are building while they build it — and quality doesn't slide just because there's no gate on every line.

The counterpoint: Geoffrey Huntley's pre-commit hook

At almost the same time (mid-October), independent developer Geoffrey Huntley documented a more extreme personal practice in his long essay "agency" — a useful counterpoint to Anthropic's official line.

Huntley's approach: a pre-commit hook that deterministically inspects the git diff for direct calls to observability modules that bypass his diagnostics library (his patterns for OTel and structured logging). On a hit, the commit fails and a prompt is injected telling the agent to use the diagnostics library. His words: "All of a sudden it's ten out of ten."

What's interesting is why he doesn't use the more "proper" approach: updating AGENTS.md leaves "a delta, and it'll drift." Skill packs, AGENTS.md files, MCPs are all probabilistic — "I swear it's astrology for software engineers." They read well and feel good, with no guarantee they do anything. What isn't astrology is engineering: a deterministic check that fails the commit and injects the correction. He calls it "Danger Systems in the loop," a nod to the decade-old Danger tool that automated checks like "the REST domain must not be coupled to the SQL domain" in CI. Architectural enforcement, same as it ever was.

The two approaches don't contradict — they're the same answer at different scales. Anthropic wrote "fix repeated problems at the source" into process (skills, lint rules, instruction files); Huntley pushes "the source" to the extreme — not even trusting the instruction file, going straight to a deterministic hook. For a solo vibe team, Huntley's version is the more practical one: you don't need six layers, but you need one or two non-negotiable deterministic checks. Think about your project's equivalent of the "diagnostics library": must all API calls go through a unified wrapper? Must every external call have a timeout? Must secrets never enter code? A few dozen lines of deterministic pre-commit checks beat three paragraphs of "please make sure" in a prompt, ten times over. That's the real meaning of "ten out of ten": constraints belong where machines can enforce them, not where agents are hoped to behave.

Judgment: review is shifting from "humans gating agents" to "agents review first, humans sample and correct"

Put both practices together and a clear paradigm shift surfaces: review is no longer "humans as the gate blocking agent output" but "agents review first, humans spot-check and correct course." Anthropic's version is the six-layer pipeline plus risk tiers plus convergence controls; Huntley's is the deterministic hook plus prompt injection. The common thread: humans no longer try to "read everything" — they design the machinery of what gets looked at, what gets blocked, and when to step in.

Three actions a solo vibe team can copy directly, in ascending order of investment. First, write one pre-commit hook that turns your one or two iron rules into deterministic checks (no more than three — more than that and even you won't maintain them). Second, give your agent a verification loop: whatever can run (tests, builds, screenshots) must run with output shown, never "it's done" on words alone — that's the source of the two-to-three-times gap Boris Cherny described. Third, if you use agents to review each other, cap it at three rounds; if three rounds don't pass, stop and change the approach instead of letting them peck at each other overnight.

And one counterintuitive reminder: Anthropic found the fastest way to improve review isn't tuning prompts but "fixing repeated problems at the source" — lint rules, skills, instruction files. Huntley goes further: even instruction files drift; only deterministic checks count. They disagree only on how far to push "the source"; they agree on "stop firefighting at review time." Next time your agent makes the same mistake for the fifth time, don't write a longer prompt — write a hook.

Where this is going

On the product side, Code Review for Claude Code is GA on Team and Enterprise plans, with /code-review and /security-review available locally — the "review pipeline" is becoming an off-the-shelf commodity. But Anthropic draws its own line: the product posts findings, not approvals; approving a PR is still a human call. Their own repos go further, letting owners decide which low-risk changes merge on automated checks alone, and that line keeps moving.

Whenever a review misses something, they don't ask "how do we write a better prompt" but "what didn't the model have in front of it" — and the fix goes into a CLAUDE.md, a skill, or a new check. The goal never changed: less human time per change, and no more reverts than before.

A final, very Anthropic detail: they invite teams that let agents open pull requests to share which checks they've automated, which still need a person, and what they think Anthropic got wrong. That's not modesty — it's their methodology for improving the reviewer itself: incidents become an eval set, run daily. The review system is itself under review.

Further reading: the human time saved at review should be spent on understanding code. VibeFix's guide "Reading AI-Generated Code: a code-reading playbook for the 'AI writes, you own it' era" offers six field-tested methods (map before entering, 300-line diff cap, a distrust checklist, cross-validation, weekly code walks) — the perfect complement to this article's answer to "when is reading worth it."