Claude Writes 90% of Claude Code. Here's Who Still Approves the Merge.

The Claude Code team says Claude writes about 90 percent of its own code. Changes arrive faster than people can read them line by line. So the team stopped asking "did a human read this?" and started asking a better question: what could go wrong with this change, and which check should catch it?

Their answer is a stack of checks, with a person accountable for every change that ships. This article walks through the layers, the numbers they published, and what they still have not solved.

How to read it: the post is "How the Claude Code team does code review," published October 16, 2026, at claude.dev/blog/solving-code-review-at-anthropic, read on October 18, 2026. Every number below is the team's own, from internal measurements, and I have not checked them independently. I have not used their system. Where I add an opinion, I label it.

The problem they named

Merged pull requests more than doubled from June to September, and the share needing a revert fell by more than 40 percent. The stated goal is to minimize human review time without increasing reverts or incidents. Those two numbers together are the real claim: faster merging with fewer rollbacks, not just faster merging.

The reframing matters more than any tool. "Did a human read the code?" is a poor proxy for safety. The team moved review from a gate at the end of a process to something that runs continuously, which they describe as "more like spellcheck while you write."

The layers

1. Verify before the pull request. Claude runs tests, builds and linters, and shows the output rather than claiming success. A subagent reviews the diff in a fresh context. Recurring findings are fixed at the source, in CLAUDE.md, a REVIEW.md written by code owners, skills, or lint rules.
2. An AI reviewer on every pull request. Parallel agents hunt for bugs. A separate group votes on each finding, and only the findings that survive are posted, labeled Important, Nit, or Pre-existing. The team reports that internal pull requests getting substantive comments rose from 16 percent to 54 percent when the tool launched.
3. A security review that can block. Open bug or security findings stop a merge until they are fixed or closed with a reason.
4. Required continuous integration. Lint, types, tests across platforms, and builds. The pull request template asks how the change was tested and how to revert it.
5. Human approval scaled to risk. A classifier sets the tier from the change, not the author. Low risk needs no human once automated checks pass. Medium needs one person, and high needs two. Some paths, such as CI workflow files, always need a person.
6. A merge queue, flags and gradual release. The queue re-runs checks against main. New features reach internal users first, and releases go to a latest channel before stable.
7. Fast detection and rollback. Flags turn a feature off without a deploy, and a weekly on-call rotation watches for problems.

Two rules in the list are easy to skim past. An agent's approval never counts as a human approval. And an approval covers one specific commit, so a later change needs a new review.

The reviewer needed its own fixing

The team found that the AI reviewer could fail to converge. One command-line pull request went through more than fifty review rounds overnight. About 59 percent of what the reviewer kept flagging was code that had been there since its first pass.

Their fixes were practical: cap the review at three rounds, re-review only the diff after the first few passes, flag bug classes rather than single lines, and never repeat a finding. Their numbers before and after:

Metric	Before	After
Pass after one review-and-fix round	65%	78%
Needed five or more rounds	8.9%	1.5%
Mean reviews to pass	2.08	1.32

They also turn past incidents into a test set: bug-causing pull requests, their reverts and their fixes become cases the reviewer runs daily.

Where humans stay

The post lists what stays with people:

• Whether to build something at all: direction, scope and taste.
• Risky code, such as billing, the auto-updater and CI workflows.
• Architecture that others will copy.
• Reading evidence, such as test output, screenshots and findings.
• Owning outcomes: "A person is accountable for every change that ships, whoever typed it."

What is still unsolved

The post is direct about the gaps, and I think this is the most useful part for other teams.

• No circuit breakers yet. The team has no mechanism that tightens approval when reverts or incidents rise. Engineers want one before more code moves to zero-human merges.
• Bad merges are still caught by people. Detection depends on the author and on-call, as well as dashboards.
• Slowing down is not the fix. The post says slowing down lowers error rates, "mostly because you're doing less of everything." They prefer getting faster at detection and repair.
• Reviewer loops have no limit. Agent-author and agent-reviewer loops can run indefinitely without a convergence cap.

What I would take from it

This section is my opinion, not the team's.

1. Replace "who read it?" with "which check catches this risk?" Then write down the check for each risk class.
2. Scale approval to risk. Most changes do not need two people. A few paths always do.
3. Cap every automated review loop. Three rounds is a number they chose; the principle is a hard limit.
4. Turn incidents into tests. Every revert should leave behind a case the reviewer runs.
5. Build the circuit breaker before you need it. The team says it doesn't have one yet.

What I could not verify

• Every number. The 90 percent, the 16-to-54 percent, and the convergence table are internal figures, and I cannot check them.
• Transfer to other teams. Claude Code is one product with one codebase, and the team's tooling is its own.
• Current state. The post describes one moment in October 2026, and the tooling is changing.

Source, accessed October 18, 2026: "How the Claude Code team does code review," claude.dev/blog/solving-code-review-at-anthropic (October 16, 2026).

If your team's reviewers approved the last ten changes in under a minute each, which one would you have checked yourself?

#AI #ClaudeCode #CodeReview #SoftwareEngineering

---

Work with me: I take 1:1 calls on mobile architecture reviews, mobile and AI questions, and startup tech consults. Book a slot on Topmate: topmate.io/sairamkotha