How the Claude Code Team Does Code Review: What You Can Copy

The Claude Code team still reviews every change, but machines now do most of the reading and people are pulled in by risk. In Anthropic's October 15, 2026 engineering post, a change is verified and checked by a fresh-context subagent before a pull request exists, then gets a multi-agent Claude review, a security review and full CI. Human approvals come last and are set by risk: none for docs and flagged additive changes, one for ordinary product changes, two for the riskiest paths. A merge queue, feature flags, staged releases and fast rollback catch what slips through. Anthropic says merged pull requests more than doubled from June to September while the share that had to be reverted fell by more than 40%, without publishing the base numbers.

You can copy most of this with public tools, starting with one file. Put your review rules in CLAUDE.md, because the local /code-review command, which works on any plan, follows CLAUDE.md and does not read REVIEW.md. In a two-run test on October 23, 2026, it flagged a planted rule against TODO comments only after that rule moved from REVIEW.md into CLAUDE.md. Then add Testing, Risk and How to revert fields to your PR template, write down risk tiers that CODEOWNERS and branch protection enforce, and cap agent review rounds at three.

One part does not come out of the box. The managed Code Review service for Team and Enterprise plans reads REVIEW.md, but it never approves or blocks a pull request. The merge block in Anthropic's own repositories is their configuration, and you rebuild it with your own required checks.

The seven layers a Claude Code change goes through

Anthropic describes seven layers between an engineer's laptop and a stable release, and each one catches some problems and misses others. Review no longer waits at the end: most changes have been reviewed and fixed by Claude at least once before a person is asked to look, which the post compares to a spellchecker running while you write. The table follows the order in Anthropic's post "How the Claude Code team does code review", with the closest public tool for each layer.

Layer 1 carries more weight than it looks: when the reviewer keeps flagging the same thing, the team fixes it at the source, in a skill, a lint rule or an instruction file, instead of answering it on every pull request. The post also names a gap in layer 7. Noticing a bad merge still depends on people and dashboards, and there are no circuit breakers yet that tighten approval when revert or incident numbers move; the engineers want them before more code goes to zero-human merges.

Who approves: zero, one or two humans, set by the change's risk

Human approval is the one layer where a person is required, and the number of people depends on what the change touches, not on who wrote it. A classifier reads each change and picks its tier, and a second classifier asks whether this particular change needs a person even when its tier says it doesn't.

Several rules sit on top of the table, and they are what keep the zero-approval tier from being a loophole. Paths that owners have listed as sensitive, and any CI workflow file, always need a person. Only authors on the repository's trusted list, mostly the team that owns it, get the lighter paths; everyone else needs a second approver. An agent's approval never counts as a person's, so automated review can clear a low-risk change but can't fill a slot that calls for a human.

Responsibility follows the prompt. On an agent-written pull request, the person directing the agent counts as one of the required reviewers, the same as if they had typed the code. An approval also covers one specific commit: if new commits arrive that the system can't vouch for, such as an agent's push or a merge someone resolved by hand, the approval has to be given again.

So a docs change merges with no human reader only when the author is trusted, the change itself is classified low risk, and both the bug review and the security review came back clean or were answered. The classifiers are internal tools with no published public equivalent.

Does anyone still read the code? What humans decide at Anthropic

People on the Claude Code team still read code, but selectively, where only a person can judge it. The post lists five jobs that stay human: deciding whether to build something at all, reviewing risky code such as billing, the auto-updater and CI workflows, reviewing architecture that others will copy, reading the evidence behind an approval, and owning the outcome of every change that ships.

Reading the evidence is the job most likely to slide. It means looking at the test output, the command that ran and what it returned, a screenshot and the reviewer's findings before approving, and the post's rule for it is blunt: if you can't say what the checks would miss, ask for a real review instead of giving a quick approval. Direction is the other human call. Agents make it cheap to start work that shouldn't land, so the team raises a different direction early in the thread, not as a blocking comment on a finished pull request.

Review used to spread knowledge of the codebase, and that job moved too. When someone needs to understand a part of Claude Code, they ask Claude for an explainer of exactly that slice, and the team works in open Slack channels where others see what is being built. After merge the norm is "you land it, you own it": changes are small and reversible, and the person who landed a change usually fixes it because they have the most context, not as blame.

What the 90%, doubled PRs and 40% fewer reverts actually measure

The headline numbers are real but narrower than they look, and two of them describe a different repository or a different moment. All of them come from Anthropic and none can be recomputed from public data.

The target behind these numbers is human time, not revert rate. The team tracks human approvals per pull request (median and 95th percentile), human comments and how long a pull request waits on a person, and in the post's words it optimizes for "the minimum amount of human review time that doesn't raise reverts or incidents." Revert and incident rates are the guardrail, not the goal: if they rise, human time hasn't been saved, only moved to fixing what broke. The missing circuit breaker described above is the part that would apply that brake automatically.

Does REVIEW.md work with local /code-review? A two-run test

No. The local /code-review command reads your CLAUDE.md files and ignores REVIEW.md, which only the managed Code Review service on GitHub reads. Claude Code's documentation for local /code-review says so directly, and a two-run test on October 23, 2026 showed exactly that.

The test used Claude Code 2.1.309 on macOS with one account, running claude -p "/code-review low" --output-format json with only file-reading, git and node tools allowed, against a small demo repository. A branch added one function to a cart module with four planted problems:

// Apply a percentage discount to the first `limit` items only.
// TODO: support coupon codes
function discountedTotal(items, percent, limit) {
  let total = 0;
  for (let i = 0; i <= limit; i++) {
    const line = items[i].priceCents * items[i].qty;
    total += line * (1 - percent / 100);
  }
  for (let i = limit; i < items.length; i++) {
    total += items[i].priceCents * items[i].qty;
  }
  return total;
}

The repository's CLAUDE.md said "Money is always stored and computed as integer cents. Never use floating-point numbers for prices or totals." Its REVIEW.md held one extra rule, Any comment containing "TODO" in a changed line is an Important finding. For the second run, that same rule was appended to CLAUDE.md and nothing else changed.

The reviewer's answers came back in Chinese because that machine's Claude Code is set to reply in Chinese; the findings above are English paraphrases. The cost figures are the CLI's total_cost_usd field, an estimate at API prices rather than an invoice. Each condition ran once at low effort, which reports only the findings the review is most confident in, on one machine, and model output varies between runs, so treat this as a confirmation of the documented behavior, not a benchmark. The managed Code Review service, ultrareview and /security-review were not run.

The practical rule follows from the docs and the test: anything you want every review to enforce, local or on GitHub, goes in CLAUDE.md. Keep REVIEW.md for instructions that only make sense on pull requests in the managed service, such as what counts as Important, a nit cap and paths to skip. How CLAUDE.md files load and where to put them is covered in Claude Code Memory Guide (2026): CLAUDE.md vs Auto Memory vs Plugins.

What you can copy on each Claude plan

Every plan can run the local review, Pro and Max accounts get three one-time free cloud reviews, and only Team and Enterprise organizations get the managed review on every GitHub pull request. What changes between the tools is who can start them, which instruction files they read, who pays, and whether they can stop a merge.

The sources for each row are Claude Code's Code Review overview, the ultrareview documentation, the Claude Code GitHub Actions documentation and the README of Anthropic's claude-code-security-review GitHub Action, all as of October 23, 2026. That README also warns the Action is not hardened against prompt injection and should only review trusted pull requests, so require approval before it runs on outside contributors' forks.

Speed differs as much as price. Local /code-review takes seconds to a few minutes, ultrareview roughly 15 to 25 minutes, and the managed Code Review now finishes most reviews in 6 to 10 minutes, down from about 20 during the preview, according to Anthropic's Code Review general availability announcement. /review is an alias of /code-review; for when to reach for /simplify or other bundled skills instead, see Best Claude Code Skills to Use First: Picks by Workflow.

Does Claude Code Review block bad pull requests?

Not by default. Anthropic's Code Review documentation says a review "never approves or blocks the pull request": its check run, named Claude Code Review, finishes as neutral and never as a failure, so it cannot fail a required check. The rule in Anthropic's own repositories, that nothing merges while a bug or security finding is open, is their configuration on top of the product, which posts findings and leaves approval to people.

You can rebuild the block in two ways on GitHub. The simpler one is the branch protection rule "Require conversation resolution before merging," which mirrors Anthropic's habit of answering every finding: the author fixes it or resolves the thread with a short reason, and an unresolved inline comment holds the merge. The stricter one is to fail a CI job when the review found Important issues. Claude Code's guide to reading Code Review results on a pull request shows how: the last line of the check run's Details text is an HTML comment such as <!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->, where normal is the count of Important findings. The docs read it with gh and jq:

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID --jq '
  (.output.text | split("\n") | last
    | scan("^<!-- bughunter-severity: (.*) -->$")[0] | fromjson)?
  // error("no severity line")'

This command comes from the docs and was not run as part of the test above. Two cases matter when you script it. A missing severity line means no verdict, not zero findings, because a failed, timed-out, canceled or superseded review has none. And a check run titled "Code review not repeated" has no severity line either, because it kept an earlier result whose Important findings are still open, so read the title first and fail the job in that case if you are gating.

Set up Anthropic-style code review on your repo in eight steps

The order matters more than the tools: make the agent prove its work before a pull request exists, add AI review to one repository, then write the approval rules, and only loosen anything once your revert numbers allow it. The steps follow the adoption checklist at the end of Anthropic's post.

1. Write a short CLAUDE.md with checks the agent can run and rules every review should enforce. Keep it to the stack, the commands that prove a change works and the conventions you want flagged, and point to longer docs instead of pasting them in. Run formatters and linters through hooks rather than asking the reviewer to catch them; Claude Code Hooks vs Skills vs Slash Commands: What to Use and How to Start covers when a hook is the right tool.

   markdownCopy

   # Project rules
   - Before saying a change is done, run `npm test` and `npm run build` and paste the output.
   - Money is always stored and computed as integer cents.
   - A changed line containing "TODO" is an Important finding.

2. Review locally before you open the pull request. Run /code-review on your branch, with an effort level such as /code-review high for risky work and --fix to apply the findings, then run /security-review. For a second opinion with no memory of how the code was written, use a read-only reviewer subagent; Claude Code Subagents Documentation: Official Docs, Safe Templates, and When to Use Them has a safe template.

3. Add Testing, Risk and How to revert to your PR template. Claude can fill these in, but the person who asked for the change signs off on them, which is how "reading the evidence" becomes routine instead of optional. Save this as .github/pull_request_template.md:

   markdownCopy

   ## Testing
   <!-- The command you ran and what it returned, or a screenshot -->
   
   ## Risk
   <!-- Low, Medium or High, and any sensitive paths this touches -->
   
   ## How to revert
   <!-- The flag to turn off, or the revert steps -->

4. Turn on an AI reviewer for one repository and tune REVIEW.md for a few weeks. On Team or Enterprise, an Owner turns on Code Review in Admin settings > Claude Code, installs the Claude GitHub App and picks the repository; start it on "Once after PR creation" rather than the per-push default to keep costs readable. On other plans, run /install-github-app in Claude Code to set up the Claude Code GitHub Action's review workflow. Then move comments the reviewer keeps getting wrong into a short REVIEW.md that says what failure looks like in your repository, caps nits, lists paths to skip and asks for evidence:

   markdownCopy

   # Review instructions
   
   ## What Important means here
   Important = wrong behavior, leaked data, or anything that blocks a rollback.
   Style and naming are Nit at most.
   
   ## Cap the nits
   Report at most three Nits per review.
   
   ## Do not report
   - Generated files under `src/gen/` and lockfiles
   - Anything CI already enforces: lint, formatting, type errors
   
   ## Evidence and summary
   Behavior claims need a file:line citation, not a guess from a name.
   Start the summary with the number of findings, and say plainly when there is nothing to fix.

   Code Review reads REVIEW.md from the base or default branch, never from the pull request that changes it, so merge edits to it first. Lowering severity, skipping paths and capping nits only take effect from the root file on a protected default branch, according to Claude Code's guide to customizing Code Review.

5. Write down risk tiers and enforce the sensitive paths with CODEOWNERS and branch protection. Decide the tier from what the change touches, not who wrote it, and list the paths that always need a person: auth, billing, CI and release workflows, installers. In GitHub, a CODEOWNERS file plus the branch protection setting "Require review from Code Owners" makes those paths wait for an owner:

   Copy

   # Paths that always need a person
   /.github/workflows/   @your-org/release-owners
   /src/auth/            @your-org/security-owners
   /src/billing/         @your-org/billing-owners
   /scripts/install/     @your-org/release-owners

   GitHub has no built-in classifier that lets a docs change merge with zero approvals while an auto-updater change needs one, so start strict, with at least one human approval on everything, and loosen only with evidence from your revert and incident rates. Keep any lighter path for authors you trust, never let a bot's approval stand in for a required human's, and turn on dismissal of stale approvals when new commits are pushed, so an agent's push after approval needs a fresh look.

6. Require every review thread resolved before merge, and gate on Important findings if you use Code Review. Turn on "Require conversation resolution before merging," add automated security review, and if you want the stricter block, add the severity-count job from the previous section as a required check.

7. Match review depth to risk and cap the rounds. Use Quick on routine repositories and Deep where one missed bug costs more than the extra review time; Code Review sets this per repository. Stop agent review at three rounds and re-review only the new diff after that, using the rules in the next section.

8. After merge, make mistakes cheap to undo and turn them into tests for the reviewer. Use a merge queue, ship new behavior behind feature flags to internal users first, release in stages and keep rollback to one step. Every incident and revert becomes a case in an eval set that you rescore whenever the reviewer's prompts, tools or model change, and you measure human time per change with revert and incident rates as the guardrail.

What each Claude review tool costs: plan usage or usage credits

None of the three Claude review tools has a flat price, and they bill to different places. Local /code-review costs whatever the session uses, so on a subscription it draws on your plan's limits and with an API key it bills tokens; the two small test runs above cost well under a dollar each by the CLI's own estimate, but a large branch at high effort will cost more.

Ultrareview and the managed Code Review both bill as usage credits. Once ultrareview's free runs are used up, Claude Code shows an estimate before each paid run and won't launch one until usage credits are turned on. Code Review is billed to the organization rather than to the developer who opened the pull request, and Claude Code's Code Review costs page lists what drives each review's cost: the review level, the size of the change, the complexity of the surrounding code and how many candidate issues need checking. The setting matters most. A repository added from the admin page starts on "After every push," which multiplies cost by the number of pushes, while "Once after PR creation" and "Manual (@claude review)" run far fewer reviews.

To estimate before rolling out, the docs suggest a pilot: set a monthly spend limit for Code Review, enable a few representative repositories on "Once after PR creation" or "Manual," read the Average cost column in Admin settings > Claude Code after several reviews, and multiply by the pull requests each repository opens in a month, times the typical pushes per pull request if you use "After every push." Reviews are skipped, with a comment on the pull request, when the Code Review limit, the organization's spend limit or the credit balance runs out. A "$15–25 per review" figure circulated during the research preview; the current docs give no per-review price. Eligible Enterprise organizations can claim at least $10,000 in Code Review credits by January 15, 2027, and the credits expire 30 days after claiming. For how usage credits are charged against a plan, see Claude Extra Usage Cost: Credit Math and When Max Is Cheaper.

Keep agent review from looping: evals, noise counts and a round cap

Anthropic tunes its reviewer against its own incidents and limits how many rounds a pull request can go through, because an agent author and an agent reviewer can keep each other busy indefinitely. One Claude Code CLI pull request went through more than fifty rounds of review and fixes overnight before its author stopped it, and when the team ran git blame on what the reviewer kept flagging, about 59% was code that had been there since the reviewer's first pass. The reviewer was finding a few more old bugs each round, not new ones.

Recall is measured against real failures. The team collected past pull requests that caused incidents, with their fix-forwards and reverts, had engineers who know that code confirm each bug and where it lived, and runs the reviewer against that set daily; every change to the reviewer is scored against all of it. Noise is measured from what people do with comments, sorted into fixed, wrong, intentional or didn't matter, plus runs on pull requests known to be clean. The written priority is catching real bugs first and cutting review rounds second. Noise also costs more when the author is an agent, because a person waves off a nit in seconds while an agent fixes it, which means another commit and another round.

These are the four convergence rules the team adopted, and they work just as well written into your own agent instructions or review script:

• After three rounds, the reviewer asks the author to step back and reconsider the approach instead of patching again.
• After the first few passes, re-review only the new diff.
• Flag the class of bug, so the author fixes every instance rather than one line.
• Don't repeat a finding that has already been posted.

The old bugs don't go unreviewed. Review agents also run nightly over existing code, which catches them before they show up in someone else's pull request.

Claude Code Review: other questions

Does Claude Code Review run your code or push changes to your repository?

No. As of October 23, 2026, Claude Code's Code Review documentation says a review works from reading the diff and the surrounding code without building or running it, runs on Anthropic infrastructure, has read-only access to the repository and pushes no commits. On the pull request it only posts comments and a check run and resolves its own earlier threads. The Claude GitHub App it uses holds a broader permission set shared with other Claude features.

Does Claude Code Review work with GitLab?

The managed Code Review service works only with GitHub, including GitHub Enterprise Server and GitHub Enterprise Cloud with data residency. On GitLab you can run local /code-review --comment against a merge request, which posts the findings as a single note through the glab CLI in Claude Code v2.1.257 or later, or run Claude Code in GitLab CI/CD with an API key or cloud provider credentials.

Is a Team plan worth it just for Code Review?

Only if you want every GitHub pull request reviewed automatically without maintaining a workflow file, and you are prepared to pay usage credits on top of the plan. On other plans, the Claude Code GitHub Action reviews each pull request through a workflow you maintain, and local /code-review covers the review before a pull request exists.