How the Claude Code Team Reviews Code: The AI-First Review Loop Explained, and How to Copy It

On October 15, three engineers on Anthropic's Claude Code team, Addy Osmani, Morgan Westlee Lunt and Qing Wang, published How the Claude Code team does code review on the claude.dev blog. The official ClaudeDevs account on X linked it the next day. The post is unusual for a vendor blog: it describes an internal process in enough detail to copy, names the tools that do each step, and admits what is still missing.

This explainer walks through what the post actually claims, how the review loop works layer by layer, and what a team outside Anthropic can take from it.

What the numbers say, and what they do not

Several summaries of the post have circulated with rounded or stretched figures. Here is what the primary source states.

• About 90 percent of the code. The post opens: "We've said before that Claude writes about 90 percent of Claude Code's own code." That is a restated figure, not a new measurement in this post. Boris Cherny, who created Claude Code, was asked on X who writes the other 10 percent and replied: "Also Claude, but we're fixing up the attribution to be super confident before claiming it." Treat 90 percent as Anthropic's own estimate.
• Merged pull requests more than doubled. From June to September, merged pull requests to Claude Code's codebase "more than doubled." The post gives no raw counts.
• The revert share fell by more than 40 percent. This is a share, not a count. The post says "the share that had to be reverted fell by more than 40 percent." Because volume more than doubled over the same period, the absolute number of reverts may not have dropped by that much. The post does not say.
• Low-risk changes merge without a required human approval, with conditions. It is not accurate to say low-risk changes ship with no human involved. Low-risk changes such as docs, copy, internal-only features and additive changes behind a flag need no human approvals "once automated review and security checks are green." That lighter path applies only to authors on the repo's trusted list, and on an agent-written PR "the person directing the agent counts as one of the required reviewers." The stated goal is that most pull requests merge "with at most one human in the loop, who can be the author."

Other figures in the post: changes landing per day in Anthropic's monorepo went from about 2,500 in May to more than 30,000 in September. Claude Code lives in a separate repository but faces similar pressure. When Anthropic launched the research preview of its Code Review product, the share of internal PRs getting substantive review comments went from 16 percent to 54 percent.

The core idea: review is a set of checks, not a person reading a diff

The authors frame the problem in terms of cost. Human time is the scarce resource, and it is spent in two places: reviewing code, and fixing what bad code breaks. Cutting review time only helps if it does not reappear as incident time.

So the team stopped treating "did a human read this?" as the test. The post calls that an "imprecise proxy" for a better question: what could go wrong with this change, and which check, automated or human, is the right one to catch it.

That reframing also moved review earlier. In the old model, review was a gate at the end: write code, open a PR, wait for a colleague. In the new one, review runs continuously, "more like spellcheck while you write." Most changes have been reviewed and fixed by Claude at least once before a person is asked to look.

The team measures the result with three human-time metrics: 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. In the post's words, if those rise, "we haven't saved human time, we've only moved it."

How the loop works, layer by layer

The post describes a stack of layers. Each one catches some problems and misses others, and rollback sits underneath to handle what gets through all of them.

1. Verification before a PR exists

Most review now happens before the pull request. Engineers give Claude something it can run, such as tests, a build, or a screenshot to compare against a design, and ask it to show the output rather than say it is done. A subagent then reviews the diff with fresh context.

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 are checked against design guidelines. The post cites Cherny's estimate that giving Claude a way to verify its work makes the final result two to three times better.

When the automated reviewer keeps flagging the same issue, the team fixes it at the source: in a skill, a lint rule, or an instruction file. Two files matter here:

• CLAUDE.md describes the project: stack, conventions, goals and non-goals. Every review loads it, so the team keeps it short and links out to other docs.
• REVIEW.md is written by code owners and tells the reviewer what matters in their part of the code. The post says good ones are short, define what failure looks like in that repo, cap nits, list paths to skip, and ask for a file and line as evidence.

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 and asks whether the change solves its problem, fits the system, or breaks something else. On a bug fix it looks for the root cause.

Findings are filtered before anyone sees them. Several agents hunt for bugs in parallel, then a separate group votes on each finding, and it is posted only if enough agree it is real. Style-only, diagnostic and cleanup findings are dropped. The team A/B tested those filters on its own PRs. What remains appears as inline comments sorted by severity and tagged Important, Nit, or Pre-existing, so a bug the PR did not introduce is not pinned on the author.

Every finding must be answered: fix it, or resolve the thread with a reason. Often an agent picks up the fix overnight.

The public version is Code Review for Claude Code, which the post says is now generally available on Team and Enterprise plans. Admins set each repo to Quick, Standard or Deep. A lighter version runs locally as /code-review.

3. Security review that can block

Security has its own automated review. A PR cannot merge while any finding from the bug review or the security review is still open. A later commit that fixes the issue clears the finding on its own. Outside teams can get the same behavior from the open-source security review GitHub Action or the /security-review command.

4. Required CI

Lint, type checks, tests on every platform, and a build. The post says 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.

5. Human approval, scaled by risk

This is the layer most summaries compress into "low-risk changes skip review." The actual rules:

• Low risk (docs, copy, internal-only features, additive changes behind a flag): no human approvals required once automated review and security checks are green.
• Medium risk (ordinary product changes, plus sensitive areas such as 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.

Several rules keep the tiers honest:

• The change sets the tier, not the author. A classifier reads the change and picks its tier. A second classifier asks whether this specific change needs another person even if its tier says it does not.
• Some paths always need a person: anything owners list as sensitive, and any CI workflow file.
• Only authors on the repo's trusted list, mostly the owning team, get the lighter paths. Everyone else needs a second approver.
• An agent's approval never counts as a person's.
• An approval covers one specific commit. If new commits land that the system cannot vouch for, such as an agent's push or a hand-resolved merge, approval must be given again.

6. Merge queue, flags and gradual release

The merge queue re-runs every check against main with the change applied, so two PRs that pass separately cannot combine into a broken main. New behavior usually ships behind a flag to Anthropic employees first. Public releases go to the latest channel, and stable trails it.

7. Fast detection, fast rollback

Flags turn off without a deploy. Claude Code has a weekly on-call rotation, and incident reviews ask which layer should have caught the issue. The post is candid about a gap here: there are no circuit breakers yet that tighten approval rules when revert or incident numbers move, and engineers on the team want them before more code moves to zero-human merges.

How the reviewer itself gets better

The loop is not only about reviewing code. It also reviews the reviewer.

• Incidents become an eval. The team collected past PRs that caused incidents, with their fix-forwards and reverts, and had engineers who know that code confirm each bug and its location. The reviewer runs against that set daily.
• Noise is measured by what people do. Every reviewer comment is sorted by the response: fixed, marked wrong, marked intentional, or judged not to matter. The reviewer also runs on PRs known to be clean, to count findings that would have led someone to make a harmful change. The written priority is catching real bugs first and cutting review rounds second.
• Noise costs more with agent authors. A person can wave off a nit in seconds. An agent fixes it, which means another commit and another review round.

Making review converge

One failure mode is specific to agent-on-agent review: an agent author and an agent reviewer can keep each other busy indefinitely. The post describes one CLI PR that went through more than fifty rounds of review and fixes overnight before its author stopped it. When the team ran git blame on what the reviewer kept flagging, about 59 percent was code that had been there since the reviewer's first pass. It was finding a few more old bugs each round, not new ones.

The fixes:

• A cap of three rounds, after which the reviewer asks the author to reconsider the approach.
• Diff-only re-review after the first few passes.
• Flagging the class of bug so the author fixes every instance.
• No repeats of findings already posted.

The post's chart on internal PRs reports the before and after: PRs passing after one review and fix round rose from 65 percent to 78 percent, PRs needing five or more rounds fell from 8.9 percent to 1.5 percent, and mean reviews to pass fell from 2.08 to 1.32. Review agents also run nightly over existing code to find old bugs.

Where people stay in the loop

The post lists five kinds of decisions that stay with humans:

• Whether to build the thing at all: direction, taste and scope.
• Risky code such as 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, screenshots, the reviewer's findings.
• Owning the outcome. A person is accountable for every change that ships.

Code review used to have a second job: spreading knowledge of the codebase. The team says it has no formal replacement. Instead, when someone needs to understand part of the code, they ask Claude to write an explainer for that slice. Working in open Slack channels also lets people see what others are building as they build it.

The cultural rule is "you land it, you own it." If a small or medium change breaks, the author usually fixes it. That works because changes are small, everything is reversible through flags, reverts and staged releases, and incident reviews look at the system rather than assign blame.

How other teams can copy it

The post ends with an adoption checklist. Condensed, in the order a team would roll it out:

Before the pull request

• Give your agent checks it can run, listed in a short CLAUDE.md, plus hooks that run formatters and linters.
• Run /code-review and /security-review locally, or a fresh-context subagent review.
• Add a REVIEW.md and move repeated review comments into it.

On every pull request

• Require CI and add "Testing", "Risk" and "How to revert" sections to the PR template.
• Add an AI reviewer (Code Review for Claude Code or the Claude Code GitHub Action) on one repo, tune REVIEW.md for a few weeks, then widen.
• Add automated security review and require every review thread resolved before merge.
• Match review depth to risk.
• Cap review rounds and re-review only the new diff after the first few.

Approval

• Write down risk tiers set by the change, not the author. Start strict and loosen with evidence.
• Keep lighter approval paths for trusted authors.
• Use CODEOWNERS and branch protection so auth, billing, CI and release workflows, and installers always need a person.
• Never let a bot's approval replace a required human's, and dismiss approvals on new commits.

Merge and after

• Use a merge queue, feature flags, internal use first, staged releases and one-step rollback.
• Turn incidents and reverts into an eval set and rescore the reviewer whenever its prompts, tools or model change.
• Measure human time, with revert and incident rates as the guardrail.

Why it matters

Most teams adopting coding agents hit the same wall: output goes up, and review becomes the bottleneck. The Claude Code post is one data point on a way through it that does not depend on trusting the model blindly. Its central move is to make reversibility and measurement carry the weight that line-by-line reading used to carry, and to keep humans on the decisions that need judgment.

Two caveats apply. The figures are internal, reported by the vendor that sells the review product, with no raw data published. And the setup assumes things many teams lack: a mature CI, feature flags, staged releases and a fast on-call loop. The post's own advice is to start strict on one repo and loosen only with evidence, which is the sensible way to read it.

Sources

• How the Claude Code team does code review, claude.dev blog (Oct 15, 2026)
• ClaudeDevs post on X linking the article (Oct 16, 2026)
• Boris Cherny reply on X about code attribution (Oct 16, 2026)
• ClaudeDevs post on X: Code Review generally available (Oct 15, 2026)
• Code Review for Claude Code, claude.com
• Claude Code GitHub Action, GitHub