Claude Writes 90% of Claude Code: How Review Keeps Up

§ 01Why line-by-line review stopped working#

The volume changed first. Anthropic’s post says changes landing per day in its monorepo “went from about 2,500 in May to more than 30,000 in September”, the same jump behind its switch to Scion. Claude Code lives in its own repository, but the post says “it’s seeing a lot of pressure too.”

So the team changed the question. Instead of asking whether a human read every line, it asks which check, automated or human, is the right one to catch what could go wrong with a change. Its stated goal is that most pull requests in the Claude Code repos “merge with at most one human in the loop”, with no rise in reverts or incidents. Revert and incident rates are the guardrail: if they climb, the post says, human time was only moved, not saved.

§ 02The layers a change passes through#

Most review now happens before a pull request exists. Claude runs the tests, the build and the linter, then a second agent reviews the diff in a fresh context. Boris Cherny, who created Claude Code, estimates in the post that giving Claude a way to verify its work makes the result two to three times better.

On every pull request, four more layers run:

1. Required CI. Lint, types, tests on every platform, build and packaging. A red check blocks the merge.
2. Claude code review. Several agents hunt for bugs in parallel, a separate group votes on each finding, and only findings enough of them agree on get posted, sorted by severity and tagged Important, Nit or Pre-existing. Every finding has to be fixed or closed with a reason.
3. Security review. A separate pass. An open finding from either review blocks the merge.
4. Risk-based human approval. A classifier sets how many people must approve.

After that comes a merge queue that re-runs every check against the latest main, new behavior behind a flag for Anthropic employees first, a gradual release from the latest channel to stable, and fast rollback when something still gets through.

§ 03Who has to approve what#

Three rules keep that table honest. The change sets the tier, not the author: a classifier reads the diff, and a second classifier asks whether this change needs a person even when its tier says no. Only authors on a repo’s trusted list get the lighter paths. And “An agent’s approval never counts as a person’s“: on an agent-written pull request, the person directing the agent counts as one of the required reviewers.

§ 04The reviewer that would not stop#

Agent authors create a problem human authors do not. A person waves off a nit in seconds; an agent fixes it, which means another commit and another review round. The post describes one CLI pull request 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% 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 fix was a set of limits. After three rounds, the reviewer asks the author to step back and rethink the approach. Later passes review only the new diff. The reviewer flags a class of bug so the author fixes every instance, and it never repeats a finding it already posted.

The reviewer itself is graded every day. The team turned past pull requests that caused incidents into an evaluation set, confirmed each bug with engineers who know that code, and scores every change to the reviewer’s prompts, tools or model against it. It also measures noise by what people do with each comment: fixed it, called it wrong, called it intended, or ignored it.

§ 05What people still decide#

The post lists five jobs that stayed with humans: whether to build something at all, risky code such as billing, the auto-updater and CI workflows, architecture that others will copy, reading the evidence (test output, the command that ran, a screenshot), and owning the outcome. “A person is accountable for every change that ships, whoever typed it.”

The team is open about one gap: “We don’t yet have circuit breakers that tighten approval when those numbers move”, and the post says engineers want them before more code moves to zero-human merges.

§ 06What you can use today#

Anthropic says the public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans, with Quick, Standard and Deep settings per repository, and that /code-review runs a lighter version locally. During the research preview, the share of internal pull requests getting substantive review comments went from 16% to 54%. A /security-review command and an open-source security review GitHub Action cover the second layer. The rest is process: a short CLAUDE.md with checks the agent can run, a REVIEW.md from code owners, risk tiers, and fast rollback.

§ 07Where CellCog sits#

Our conflict, declared: we build CellCog, where businesses hire AI employees, and every CellCog tier runs on Claude Opus 5.5. The pattern in Anthropic’s post is the one we apply to agent work generally: the agent that directs the work answers for it. A CellCog AI employee or chat can start helper agents, including Claude Code, and it reviews each result before it calls the job done; actions above the level an owner sets wait for approval. If you want an engineer that works this way on your codebase, an AI software engineer is one role you can hire.

§ 08What we are watching#

• Circuit breakers that tighten approval when revert or incident rates move, which the post says the team wants next.
• How much of Claude Code moves to zero-human merges once those exist.
• Pricing and usage limits for Code Review on Team and Enterprise plans.

§ 09Update log#

• October 17, 2026: First published, from Anthropic’s October 15 post and the October 16 @ClaudeDevs thread.