Claude Writes Roughly 90% of Claude Code’s Code. What the Review Account Does—and Doesn’t—Show

Anthropic has published an account of how the Claude Code team reviews code now that Claude writes roughly 90% of it. The account also says nobody keeps a complete mental model of the codebase ¹. That raises a practical question for engineering leaders: if reviewers cannot rely on knowing the whole system, what evidence are they checking?

The account describes a pull request that went through more than fifty review rounds overnight ¹. That shows substantial iteration on that change. The excerpt does not report whether the process catches more bugs than another approach or whether it would work for teams with different codebases and risks.

What the Claude Code review account reports, and what it leaves unspecified

Reported in the account 1	What it indicates	What the excerpt does not specify
Claude writes roughly 90% of the team’s code	The reported scale of AI authorship	Defect rates or a quality comparison with an earlier workflow
Nobody keeps a complete mental model of the codebase	Review cannot rely on one person knowing the whole system	What, if anything, replaces that knowledge
One pull request went through more than fifty rounds overnight	Extensive iteration on at least one change	What the rounds found or changed
A reviewer spent most of the effort on pre-existing code	The review included code beyond the new change	When that broader review is necessary
The team does not yet have a control	The account identifies a gap	What the control is 1

The excerpt does not provide a controlled comparison. It describes one team’s current practice, as reported by Anthropic ¹.

The detail about reviewing pre-existing code is useful to consider. A change may depend on behavior, configuration, or assumptions outside its diff. That suggests reviewing only changed lines can leave relevant context unchecked. It does not mean every reviewer needs to understand the entire system; it does mean familiarity with the diff alone may not be enough to judge a change’s safety.

Why reviewing AI-written code changes the review question

In workflows where an agent writes much of an implementation, a reviewer may be assessing work they did not author or observe as it developed. Anthropic’s account describes a team without anyone holding a complete mental model of its codebase ¹. One implication is that reviewers may need evidence beyond their own familiarity with the system.

A practical review can focus on three questions: What should the change do? What evidence supports that it does it? Who is accepting the remaining risk? A reviewer still has to exercise judgment, but intent should not have to be reconstructed from code alone.

An AI code review process could make those questions explicit:

• Intended behavior — what should change for users or downstream systems
• Evidence — which tests or checks support the correctness claim
• Risk — whether the change touches security, data handling, dependencies, or configuration
• Ownership — who approves the change and accepts the residual risk

This is a proposed approach, not a description of Anthropic’s process.

For related reading on automated review tooling, see GPT-6.1 Sol in CodeRabbit's Security Agent: What Buyers Need to Verify.

What more than fifty review rounds tell us

More than fifty rounds overnight sounds intensive, but a round count alone says little about review quality. The excerpt does not say what each round found, whether the findings changed the outcome, or how the team decided the review was complete ¹.

Iteration can be useful when each round tests a specific concern and resolves it. It can also become churn without a clear stopping rule. The account says the team lacks a control but does not identify it ¹. The supported conclusion is limited: the account identifies a gap, without naming the control in the excerpt.

For teams considering a similar workflow, round count is less useful than a clear completion standard. Does the reviewer understand the expected behavior? Are required checks complete? Are exceptions documented and owned? If those answers are unclear, more rounds may not solve the problem.

A proposed control model for AI-generated code governance

This is a proposed model, not a description of Anthropic’s process. Its aim is to make review auditable without requiring anyone to hold the whole codebase in their head.

1. Write a change contract. State the intended behavior, affected components, and known limitations so reviewers have something to check the implementation against.
2. Make evidence explicit. Record which tests ran, what they cover, and what remains untested. Treat generated tests as evidence to inspect, not proof that the implementation is correct.
3. Set escalation triggers. Require deeper review when a change crosses a trust boundary, touches authorization, alters data handling, changes dependencies, or lacks test coverage. Adapt the list to your architecture.
4. Name a human owner. Someone signs off, identifies the risks they accept, and knows when to involve a second reviewer—even when an agent wrote most of the change.
5. Record the basis for approval. Document what was checked, what remains uncertain, and why the reviewer considers the review complete. That is a more useful stopping rule than a round count.

If a reviewer cannot state the intended behavior, point to evidence for the key claims, or name who owns the remaining risk, pause the change and resolve those gaps rather than simply adding another round of edits.

Teams exploring how agents learn from review history may also want to read Pull Requests Can Feed Coding-Agent Skills—but the Evidence Stops at the Proposal.

How to test an AI code review process before adopting it

Treat Anthropic’s account as a case study, not a template. The excerpt reports no comparative quality results and does not establish whether the approach generalizes beyond the team ¹.

Before rolling out a similar process, run a limited pilot with evaluation criteria set in advance—for example, escaped defects, review rework, time to approval, security findings, and rollback incidents. Compare it with your current process on comparable changes and use the same acceptance bar. Track what reviewers found, not just how many passes a pull request took. Faster approval would not be meaningful if the pilot were handling lower-risk work.

Build in a stop condition from the start. If a reviewer cannot explain what a change is supposed to do, what evidence supports that claim, or who owns the risk, add review rather than treating the agent’s output as self-certifying.

It also helps to calibrate expectations about the agents themselves. InfraDev Tests Coding Agents on Multi-GPU Infrastructure. The Best Score Is 38.9%. is one example of benchmark evidence on coding-agent limits in a specialized domain.

What remains unknown about the Claude Code review process

The excerpt does not identify the control the team is missing. It also does not describe escalation rules, what the more-than-fifty review rounds found, or how the team decides whether a reviewer has adequately covered unfamiliar code ¹. It reports no evidence about whether the approach reduces defects or works on another team’s codebase ¹.

That is not a reason to dismiss the account. It is a reason to be precise about what the excerpt supports: a report of one team’s current practice, not a validated governance model. Engineering leaders can pilot the proposed contract-evidence-ownership approach, define defect and rework measures in advance, and evaluate the results on their own work.

FAQ

How much of Claude Code’s code does Claude write?
Anthropic says Claude writes roughly 90% of the Claude Code team’s code ¹.

Does the Claude Code team maintain a complete mental model of its codebase?
The account says nobody on the team keeps a complete mental model of the codebase ¹.

How many review rounds did the reported pull request go through?
The account describes a pull request that went through more than fifty review rounds overnight ¹.

Does Anthropic’s account prove that this review process improves code quality?
No. The supplied account describes the workflow but does not provide comparative quality results or evidence that it works for other engineering teams ¹.

What control does Anthropic’s team not yet have?
The account says the team does not yet have a particular control, but the supplied source does not specify what that control is ¹.

Source

¹ “Anthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing That,” InfoQ AI, ML & Data Engineering, October 29, 2026. https://www.infoq.com/news/2026/10/anthropic-code-review/