How the Claude Code Team Reviews Code When AI Writes 90% of It
The change sets the review tier, not the author. Here is how that system works and how to copy it on your own repo this week.
Code review was built on an unspoken assumption: somebody read the diff. That assumption holds when people write the code at people speed. It falls apart when an agent opens a pull request every few minutes and the reviewer is one tired engineer clicking Approve between meetings.
Most teams adopting coding agents hit this wall in the same order. Output jumps. The review queue grows. Then review turns into a rubber stamp, because nobody can actually read thirty diffs before lunch. The way out that's emerging is to stop asking who wrote a change and start asking how risky it is.
The Claude Code team at Anthropic lives at the far end of that curve. In a post on the claude.dev blog dated October 15, the team says Claude writes about 90% of Claude Code's own code. Their answer was not to read harder. They changed the question.
The old question was "did a human read this?" The new one, in their words, is "what could go wrong with this change, and which check, automated or human, is the right one to catch it?" That swap is the whole idea. Everything below is how they made it work, and what you can borrow without being Anthropic.
The insight: review effort should follow risk, not authorship
Think of airport security. Everyone walks through the metal detector, but only some bags get opened by hand, and which ones depends on what the scanner sees, not on who is carrying them.
The Claude Code team runs review the same way. Every change goes through automated checks. Then a classifier looks at the change and decides how many humans need to approve it. The post's shortest line says it best: "The change sets the tier, not the author."
That last part matters more than it looks. A senior engineer's change to billing code gets the same scrutiny as an agent's change to billing code. A junior engineer's typo fix in the docs gets the same light touch as an agent's. And the post is explicit that "an agent's approval never counts as a person's, either."
The result is a process judged by outcomes instead of by ritual. The team tracks human approvals per pull request, human comments and wait time as the cost. Revert and incident rates are the guardrail. If reverts climb, the process is wrong, no matter how many people read the code.
Six layers of checks, plus rollback
The post walks through seven stages: six layers of checks, with fast rollback underneath. Here they are in plain terms, from before a pull request exists to after it ships.
1. The work is verified before anyone looks. Claude runs the tests, the build and the linter (the tool that flags style and simple errors) and shows the output. Then a subagent, a second Claude instance with a fresh context window, rereads the diff without the original conversation's assumptions.
2. AI review on every pull request. An automated reviewer reads each change and posts findings.
3. Security review that can block. A separate security reviewer runs too, and its open findings stop the merge.
4. Automated checks that block. Required CI: lint, type checks, tests on several platforms, build and packaging.
5. Human approval, scaled by risk. A classifier assigns one of three tiers, per the post:
- Low risk (docs, copy, internal-only features, additive changes behind a feature flag): no human approval once the automated and security checks are green.
- Medium risk (ordinary product changes, plus sensitive areas like caching, the auto-updater and system prompts): one person.
- High risk (a short list of paths): always two people.
6. Merge queue, flags and a gradual release. In the merge queue, a waiting line changes join before they land, checks rerun against the latest version of main with the change applied, so two changes that each pass alone can't break each other. Features ship behind flags, internal users first, then to the latest release channel before stable.
7. Fast detection, fast rollback. Flags turn off without a deploy, and on-call watches for regressions.
Notice where the safety moved. Less of it lives in one person squinting at a diff, and more lives in layers before and after: verification before the PR, fast rollback after it.
What changed, by their numbers
These are Anthropic's internal numbers from one team, and the post doesn't claim they generalize. They are still worth knowing.
From June to September, merged pull requests to Claude Code more than doubled, while the share that got reverted fell by more than 40%. The share of internal pull requests getting substantive review comments went from 16% to 54% after the review tool's research preview. And after the team tuned the reviewer to converge, a chart in the post shows pull requests passing after one review-and-fix round rising from 65% to 78%, while those needing five or more rounds fell from 8.9% to 1.5% (claude.dev).
The context: changes landing per day in Anthropic's monorepo (the single repository that holds most of its code) went from about 2,500 in May to more than 30,000 in September, according to the same post. At that volume, "a human reads everything" stops being a policy and becomes a fiction.
What humans still do
It would be easy to read this as "humans are out of the loop." They are not, and the post is careful about it.
People still decide whether something should be built at all. They review the risky code (billing, the auto-updater, CI workflows). They shape architecture that others will copy. They read the evidence the agents produce: test output, commands run, screenshots, reviewer findings. And a named person owns every shipped change, whoever typed it.
There is one more rule that keeps the AI reviewer honest. Humans answer every finding, either by fixing it or by resolving the thread with a reason.
The team also learned that an AI reviewer can loop forever. The post describes one pull request that went through more than fifty review rounds overnight before its author stopped it. Their fix is a round cap: after three rounds, the reviewer asks the author to rethink the approach, and later passes only look at the new diff.
Put this into practice
You don't need a monorepo with 30,000 daily changes to use this. Here is the lowest-friction path, in order.
Step 1: Write your tiers down before you add more agents. List the paths where a mistake costs real money or real trust: auth, billing, CI workflows, release scripts, installers. Those are your high-risk tier. On GitHub, put them in a CODEOWNERS file and turn on branch protection that requires code-owner review, which is what the post recommends for auth, billing, CI, release workflows and installers. Everything else starts in the one-person tier. Only move work into the no-human tier once your automated checks have earned it.
Step 2: Make the agent check its own work before it opens a PR. In Claude Code, run /code-review on your branch before pushing. It works on any plan and runs in your own session (Claude Code docs). Ask the agent to paste the test and build output instead of telling you it passed. Boris Cherny, quoted in the post, estimates that giving Claude a way to verify its work makes results "two to three times better."
Step 3: Tell the reviewer what matters. Keep CLAUDE.md short: stack, conventions, goals, non-goals. If your organization uses the hosted Code Review service, add a REVIEW.md at the repo root. The customization docs include an example that does three useful things in a few lines:
## What Important means here
Reserve Important for findings that would break behavior, leak data,
or block a rollback. Style, naming, and refactoring suggestions are
Nit at most.
## Cap the nits
Report at most five Nits per review.
## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
Two details trip people up. The local /code-review command reads CLAUDE.md but not REVIEW.md, so put rules you want in both places in CLAUDE.md. And the service reads REVIEW.md from the base or default branch, never from the pull request itself, so merge changes to it first (docs).
Step 4: If you are on Team or Enterprise, pilot the hosted reviewer cheaply. An Owner turns on Code Review, installs the Claude GitHub App, and picks a review level per repo: Quick, Standard (the default) or Deep. Several agents read the change, a verification step filters out false positives, and findings land as inline comments ranked by severity. Anyone with write access can comment @claude review to start one. Automatic reviews skip drafts and pull requests from forks.
Watch the default. A newly added repository starts at After every push, which runs a review on every push and multiplies cost by the number of pushes. Billing is by token usage through usage credits, with no flat per-review price (costs docs). For a pilot, set a monthly spend limit at claude.ai/admin-settings/usage, switch a few repos to Once after PR creation or Manual, and read the average cost per review after a week.
Step 5: Measure reverts before and after. This is the part most teams skip. Pull your revert count (or rollback count, or hotfix count) for the last two months. Change the process. Compare. If reverts go up, a tier is too loose. If wait time goes down and reverts hold steady, you just bought back hours.
Honest limitations
These numbers come from one team at the company that sells the reviewer. They describe Anthropic's process, with Anthropic's tooling and Anthropic's engineers. Your mileage depends on how good your tests are, because every layer here leans on them.
The guardrail is not automatic yet. The post says there are no circuit breakers: revert and incident dashboards don't tighten approval rules on their own when they move. Engineers there want that before more code merges with zero humans. If you copy the no-human tier, you are copying it without the safety net its own authors still want.
AI review is noisy in a specific way. Agent authors fix every nit, which adds commits and review rounds. Without round caps and a nit limit, you pay for the same argument over and over.
The hosted reviewer reads the diff and the surrounding code. It doesn't build or run your code, and the docs say plainly that a review with no findings doesn't mean the code is error-free or secure. It never approves or blocks a pull request on its own, so the merge decision stays with your team.
Access has limits too. Code Review is not available to organizations with Zero Data Retention (where Anthropic doesn't keep your prompts and outputs) or the HIPAA configuration, isn't covered by Anthropic's Business Associate Agreement, and isn't yet available to those using customer-managed encryption keys (keys your company controls) (docs). And the severity-lowering, path-skipping and nit-capping instructions in REVIEW.md are only honored when the copy being read sits on a protected default branch.
The real shift
The most useful sentence in the post isn't a number. It's the reframing: stop treating "a human read it" as the measure of safety, and start asking which check is the right one for this change.
You can adopt that this week without buying anything. Put your high-risk paths in a CODEOWNERS file. Make your agent paste its test output. Count your reverts for the last two months. Then decide, with your own numbers in hand, how many humans each kind of change really needs.
Sources: How the Claude Code team does code review (claude.dev, October 15, 2026); Code Review docs; Customize Code Review; Code Review costs and usage. Docs read October 17, 2026.