What changed in review
The Claude Code team reports that merged pull requests to Claude Code's codebase more than doubled from June to September, and the share that had to be reverted fell by more than 40 percent. ClaudeDevs posted those figures on October 16, 2026. The pull-request comparison is June to September, and the year of that window is unstated.
The team also reports that Anthropic's monorepo went from about 2,500 landed changes a day in May to more than 30,000 in September this year. Those daily counts belong to the monorepo. Claude Code lives in its own repository, separate from that monorepo, and the team says that repository is seeing a lot of pressure too. The team calls manual line-by-line review incredibly difficult, and at times impossible, once changes are shipping this fast. Review still has two jobs, the team says: catch issues before they ship, and build a shared understanding of the codebase. The post mainly follows catching issues before they ship and returns to shared codebase understanding near the end.
The question the team says it asks is what could go wrong with a change, and which check, automated or human, should catch it. Review used to wait until a pull request was open. It now runs while the change is being written, and the team says most changes have been reviewed and fixed by Claude at least once before a person is asked.
Before a pull request exists, Claude has to show the output of a check it can run, such as tests, a build, or a screenshot compared with the design. A subagent with fresh context, a separate pass from the session that wrote the change, then reviews the diff. Many people on the team also run internal checks that hunt for bugs, simplify the diff, and try the behavior end to end. UI changes are checked against the design guidelines. Boris Cherny, who created Claude Code, calls giving Claude a way to verify its work probably the most important thing for good results. He estimates that this makes the final result two to three times better. He describes verification as a bash command, a test suite, or the app in a browser or phone simulator. The article presents that multiplier as his estimate.
Every pull request is then reviewed against the whole repo and the stated intent before a person looks. On a bug fix, the reviewer looks for the root cause. At the research preview, the team says the share of internal pull requests with substantive review comments went from 16 percent to 54 percent. No preview date and no customer rate are given with that figure. Most pull requests over 1,000 lines get findings, and most small ones come back clean.
The team stacks six layers of checks, with rollback under them, and then describes fast detection and rollback as a seventh stage.
- Before the pull request: show output from a check the agent can run, then a fresh-context subagent reads the diff.
- On the pull request: Claude reviews the diff against the repo and the stated intent.
- Security review: under the team's rule, an open bug-review or security-review finding blocks the merge.
- CI: lint, types, tests, and a build still block.
- Human approval: the risk of the change sets the tier. Only trusted authors get the lighter counts, and everyone else needs a second person.
- Release: a merge queue, a flag for employees first, the latest channel, then stable.
- After ship: flags turn off without a deploy, and incident review asks which layer should have caught the miss.
Approvals by risk, and the public product
On Anthropic's own Claude Code repos, the change, not the author, sets the tier. A classifier reads the change and picks low, medium, or high. A second classifier can still require another person even when the tier would not. Paths the owners have listed as sensitive, and any CI workflow file, still need a person.
Only authors on the repo's trusted list, mostly the owning team, get the lighter path in the table. That list is a separate gate from the tier. Everyone else needs a second person. An agent's approval never counts as a person's. Automated review can clear a low-risk change, and it cannot fill a slot that calls for a human. On an agent-written pull request, the person directing the agent counts as a required reviewer, the same as if they had typed the change. An approval covers one commit. A later agent push, or a merge resolved by hand, needs approval again.
People still decide whether to build the change, how to handle billing, the auto-updater, and CI, whether the change sets a pattern others will copy, whether the test output and the findings are enough, and who owns the outcome. A person remains accountable for every change that ships.
Code Review for Claude Code is generally available on Team and Enterprise plans. Admins set each repo to Quick, Standard, or Deep. Those are depths for how hard the reviewer looks. Deep is the one the team explains: use it where one missed bug costs more than the extra review time. The command /code-review runs a lighter version locally. The team article states no price and does not say which plans can run the local command.
Several agents look for bugs at the same time. A separate group then votes, and a finding is posted only if enough of them agree it is real. How many must agree is unpublished. On this pull-request reviewer, findings that are only about style, diagnostics, or cleanup are dropped. The team says it A/B tested those filters on its own pull requests before keeping them. What remains is tagged Important, Nit, or Pre-existing. Pre-existing marks a bug the pull request did not introduce. Each finding is fixed, or the thread is closed with a reason, which is how a false positive is cleared. A later commit that fixes the issue clears the finding on its own.
An open bug-review or security-review finding blocks the merge under the Claude Code team's rule. The post points readers who want that block to the open-source security review GitHub Action and /security-review. Code Review on Team and Enterprise plans posts findings and leaves approval to a person. It does not turn on the team's merge block. On Anthropic's own repos, owners decide which low-risk changes merge on automated checks alone, and the team says that line keeps moving. That choice sits apart from the trusted-author list, which decides who gets the lighter path.
On the local command, the Claude Code changelog says medium-effort /code-review also reports cleanup and CLAUDE.md convention findings on models without tuned review settings, including Opus 5.5 and Sonnet 5.5. On the pull-request reviewer, style, diagnostic, and cleanup-only findings are dropped.
| Risk | Examples | Human approvals |
|---|---|---|
| Low | Docs, copy, internal-only features, additive changes behind a flag | None required once automated review and security checks are green |
| Medium | Ordinary product changes, and changes to sensitive areas such as caching, the auto-updater, or system prompts | One person |
| High | The highest-risk code, plus a small set of paths that always need two people | Two people |
How to try the same flow
Before a pull request, the team points readers to checks the agent can run, listed in a short CLAUDE.md, plus hooks that run formatters and linters. It also points to local /code-review and /security-review, or a fresh-context subagent. CLAUDE.md carries the stack, the conventions, the goals, and the non-goals. Every review loads it, so the team keeps it short. A REVIEW.md, written by code owners, says what failure looks like in that area, caps the nits, lists paths to skip, asks for a file and a line as evidence, and asks for a summary that starts with a count of what is left to fix. When the same flag keeps coming back, the team moves the fix into a skill, a lint rule, or one of those files.
On each pull request, lint, type checks, tests, and a build still block. The template asks for Testing, Risk, and How to revert. Claude can draft those sections. The person who asked for the change signs off. After three rounds, the reviewer asks the author to reconsider the approach. Later passes review the new diff. The author is asked to fix a class of bug, findings already posted are not repeated, and review agents also run nightly over existing code. The caption on the team's chart of internal pull requests says there were fewer review rounds per pull request after those convergence changes. The caption gives no count.
For approval, write tiers from the change, keep the lighter paths for authors you trust, and keep a bot from filling a required human seat. Use CODEOWNERS and branch protection so auth, billing, CI, release workflows, and installers always need a person. Dismiss an approval when a new commit cannot be vouched for.
Their release path uses a merge queue, which re-runs every check against main with the change applied, so two pull requests that pass separately cannot combine into a broken main. New behavior usually ships to employees behind a flag first. Public releases go to the latest channel first, and the stable channel trails it. How long stable trails latest is unpublished. Flags turn off without a deploy. Past incident pull requests, fix-forwards, and reverts are confirmed by engineers who know the code, and the reviewer is run against that set daily. No score for that daily run is published.
What is still a goal
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, who can be the author, and that reverts and incidents do not rise. The article states the goal. It does not say the goal has been met. The June-to-September evidence is volume and revert share.
Human time is tracked with median and 95th-percentile approvals per pull request, human comments, and how long a pull request waits on a person. Revert and incident rates are the guardrail: if they rise, the team says the time was moved, not saved. Those medians, comment counts, and wait times are unpublished.
The line that Claude writes about 90 percent of Claude Code's code is one the team says it has said before. This article includes no counting method for that share.
Circuit breakers that would tighten approval when revert or incident numbers move are not in place. Engineers on the team want them before more code moves to merges with no human approval. No ship date is given. Noticing a bad merge still depends on the author, the weekly on-call rotation, and the revert and incident dashboards. Incident reviews ask which layer should have caught the issue.
One CLI pull request went through more than fifty rounds of review and fixes overnight before its author stopped it. The team tells that as one case of an agent author and an agent reviewer keeping each other busy. A person can dismiss a nit in seconds. An agent fixes it, which means another commit and another round of review. The team says a git blame check on what the reviewer kept flagging found that about 59 percent was code already present on the first pass, and that the reviewer was rarely finding new bugs and was finding a few more old ones each round. The post gives no sample size for that 59 percent.
The team measures that noise by what people do with the comments. Each comment is sorted by the response on the pull request: fixed, called wrong, called intentional, or set aside as something that did not matter. The reviewer is also run on pull requests the team knows are clean, and the team counts how often it reports something that would have led someone to make a harmful change. The written priority is catching real bugs first and cutting review rounds second.
Shared understanding has no formal process. Someone who needs a slice of the codebase asks Claude for an explainer of that slice, and some people have Claude build a small artifact that teaches it. The team says open Slack channels show work while it is being built. On a small or medium change, the person who lands it usually fixes a later failure. The safeguards they name are small diffs, flags, reverts, staged release, and fast internal use. Because agents make starting cheap, the article says a teammate should question direction early in the thread, and closing the pull request is ordinary.
Source
Also from
Sources and editorial approach
This article relies on the ClaudeDevs post of October 16, 2026 and the claude.dev article it links, How the Claude Code team does code review, checked the same day, plus the Claude Code changelog note that medium-effort /code-review also reports cleanup and CLAUDE.md convention findings on models without tuned review settings, including Opus 5.5 and Sonnet 5.5. The team article states no price and does not say which plans can run the local command. Security-review install steps, the best-practices guide, the separate Code Review announcement, and later changelog entries are not covered. The chart caption says internal review rounds fell after the convergence changes and gives no count. The daily incident eval is described without a published score.