We've said before that Claude writes about 90 percent of Claude Code's own code. So how do we review code at the volume we produce it? Does anyone read code anymore? And if something breaks, who catches it?
This post covers the code review flow on the Claude Code team and how it has evolved. From June to September, merged pull requests to Claude Code's codebase more than doubled while the share that had to be reverted fell by more than 40 percent.
We didn't remove review. But we did move most of the reading to machines, optimized for human time and attention, and invested heavily in making it fast and easy to undo mistakes.
RETHINKING THE PURPOSE OF CODE REVIEW
When agents write code, the number of changes goes up, fast. In Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September this year.
Claude Code lives in its own repository, separate from the monorepo, but it's seeing a lot of pressure too. When you are shipping this fast, manual, line-by-line code review is incredibly difficult if not impossible.
Code review does two jobs:
- Find and fix issues before they ship
- Build shared context and codebase understanding across the team
This article mainly focuses on finding and fixing issues, but we will come back to the second job near the end.
We think "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?"
Asking that question also changed when review happens. Before, review was a gate at the end of the road: write the code, open a PR, wait for your colleague.
Now, review runs continuously, 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. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny.
THE SCARCE RESOURCE: HUMAN TIME AND ATTENTION
We want to preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest. At our current rate of change, there is still an incredible amount of work for humans to do, and our team encounters new and novel challenges almost daily.
Human time covers both sides of review's cost: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first doesn't help if the time just shows up in the second.
So the goal is that most pull requests in the Claude Code repos (the CLI, the desktop and web apps, and the mobile apps) merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. To measure human time, we track 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 they rise, we haven't saved human time, we've only moved it.
THE LIFE OF A CHANGE
A typical change, from an engineer's laptop (or a Claude session in Slack), goes through multiple layers of code review.
The life of a changepngA typical Claude Code change, from the author's machine to users
BEFORE THE PULL REQUEST
The work is verified
Claude runs the tests, build and linter; a second agent
reviews the diff in a fresh context
ON EVERY PULL REQUEST
Required CI
Lint, types, tests across platforms, build and packaging. Red
blocks the merge
Claude code review
Agents hunt for bugs in parallel, verifiers vote on each
finding, survivors ranked by severity
Security review
A separate pass. Open findings from either review block the
merge
Risk-based approval
A classifier sets the tier: no person, one, or two. Some paths
always need a person
MERGING
Merge queue
Checks run again on the latest main with the change applied
AFTER THE MERGE
Behind a flag, used internally first
Anthropic employees run it before it reaches everyone
Gradual release
The latest channel first; the stable channel trails it
Watch, fix forward or roll back
The author and on-call watch; flags turn off quickly, broken
builds get reverted
automated
a person decides, scaled by risk
recovery
BEFORE THE PULL REQUEST
The work is verified
Claude runs the tests, build and linter; a
second agent reviews the diff in a fresh
context
ON EVERY PULL REQUEST
Required CI
Lint, types, tests across platforms, build
and packaging. Red blocks the merge
Claude code review
Agents hunt for bugs in parallel, verifiers
vote on each finding, survivors ranked by
severity
Security review
A separate pass. Open findings from either
review block the merge
Risk-based approval
A classifier sets the tier: no person, one, or
two. Some paths always need a person
MERGING
Merge queue
Checks run again on the latest main with
the change applied
AFTER THE MERGE
Behind a flag, used internally first
Anthropic employees run it before it
reaches everyone
Gradual release
The latest channel first; the stable channel
trails it
Watch, fix forward or roll back
The author and on-call watch; flags turn off
quickly, broken builds get reverted
automated
a person decides, scaled by risk
recovery
FIG AMost of the path is automated; a person's attention goes where the risk is
LAYER BY LAYER
Layers, not one gatepngSix layers of checks, with rollback under them
problems in
verification
required CI
AI review
security review
human approval
merge queue + flags
fast rollback
problems in
verification
required CI
AI review
security review
human approval
merge queue + flags
fast rollback
FIG BEach layer catches some problems and misses others. Few get through all of them, and rollback handles the rest.
1. The work is verified before anyone else looks
Most review now happens before a PR exists. We give Claude something it can run—like tests, a build or a screenshot to compare against the design—and ask it to show the output instead of saying it's done. Then a subagent reviews the diff with fresh context. Both habits come from our best-practices guide.
Before opening a PR, many of us also run a few internal skills: one hunts for bugs, one simplifies the diff, and one checks the behavior end to end. UI changes also get checked against our 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, and writes, "Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator."
When the automated reviewer keeps flagging the same thing, we fix it at the source: in the skill, with a lint rule, or with updates to instructional files such as:
CLAUDE.mdtells Claude what the project is: the stack, the conventions, the goals and the non-goals. Every review loads it, so in a large codebase we keep it short and point to other docs from there. 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, tells the reviewer what matters in their part of the code. We check separately whether the reviewer actually follows it. The good ones are short. They say what failure looks like in that repo (for docs it's "it lies," for config it's "it misroutes"), cap the nits, list paths to skip, and ask for a file and line as 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.
2. AI review on every pull request
Every pull request gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent, and asks: does the change solve its problem, fit the system, or break something else?
On a bug fix, it looks for the root cause. The public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans, and /code-review runs a lighter version locally.
When we launched the research preview, the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings, and 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.
Findings get verified by other agents before humans review them. Several agents look for bugs at the same time. 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. We A/B tested those filters on our own PRs before keeping them. What's left shows up as inline comments sorted by severity. Each is 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. You either fix it or resolve the thread with a reason. Often an agent picks up the fix overnight, so the author comes back to a PR that's already been through another round.
3. Security review that can block
Security gets its own automated review too. A PR can't merge while any finding from the bug review or the security review is still open. You either fix it or close the thread with a short reason, which is how you clear a false positive.
If a later commit fixes the issue, the finding clears on its own. You can set up the same thing with the open-source security review GitHub Action or the /security-review command. Setup is covered in automated security reviews in Claude Code.
4. Automated checks that block
The usual: lint, type checks, tests on every platform, and a build. (We wrote about scaling CI for this volume here.) 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.
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: