AI Wrote 90% of the Code: How the Claude Code Team Does Review

Addy Osmani published a long post about how the Claude Code team does code review. The title is “How the Claude Code team does code review.”

First, the data. 90% of the code in this repository is written by Claude. From June to September this year, the number of PRs merged into the codebase more than doubled, while the rollback rate instead dropped by more than 40%.

If AI wrote 90% of the code, who reviews it? Fewer people are looking—so why are there fewer mistakes? A developer paired this with a video and turned the question into a poster.

The core logic isn’t complicated: AI helps read the code, while technical decisions still go to humans. This direction matches Linear’s new Guided Review. But the Claude Code team broke implementation down in great detail.

The whole process has six layers of checks, plus rollback as a safety net. Most bugs can’t get through all six layers. Below are the key parts.

1. Verification before the PR

Saying “it’s done” out loud doesn’t count. Have Claude run tests, builds, and compare screenshots, then put the results out in the open. Then call a subagent to review the diff with fresh context. Boris Cherny (author of Claude Code) estimates that the verification process can improve output quality by two to three times.

2. Every PR goes through AI review first

Before a human looks at every PR, it first goes through Claude. It looks at the diff in the context of the entire codebase and the PR’s intent: does it actually solve the problem, does it fit the larger system, does it break other parts? When fixing bugs, it tries to find the root cause.

Found issues are divided into three tiers: Important, Nit, and Pre-existing. All comments must be addressed—either fix them or explain why not. In many cases the agent fixes them overnight; when the author gets up in the morning, the PR has already been reviewed again.

3. Security review

Runs automatically and can block merges. If there is an open finding, it cannot merge. False positives can be closed with a short reason.

4. Automated checks

Lint, type checking, tests across all platforms, and builds. For a typical CLI PR, dozens of checks have already run before human involvement. The PR template asks “How was it tested?” and “How do we roll it back?” Claude can help fill them in, but the author is responsible for reviewing them.

5. Human approval, graded by risk

Risk is determined by the change itself, not the author. One classifier determines the risk level, and another determines whether additional approval is truly needed. Sensitive paths such as billing and CI workflows always require human approval.

When an agent writes a PR, the person operating the agent counts as a reviewer. Approval is valid only for a single commit; if a new commit is untrustworthy, it must be approved again.

6. Merge queue, feature flags, and staged rollout

The merge queue ensures all checks pass on main, avoiding a situation where two successful PRs merge and main breaks. New features are hidden behind feature flags by default; Anthropic employees use them first, then they are gradually made public.

7. Rollback as a safety net

Bad merges will always slip through. Feature flags can be turned off without deploying. There is weekly on-call, and incident reviews trace back to which layer should have caught the issue.

This system is also being iterated on itself. The team treats incidents as evals: they collect the PRs that caused incidents, the fixes, and the rollbacks, and use this data every day to evaluate the review system. Noise is also tracked: how people handle comments—fixed, rejected, or explained as intentional.

One detail is very typical. Agent authors and agent reviewers can get stuck in a loop. One PR went back and forth more than fifty rounds overnight before a human stopped it. The team later limited the number of loops; after three rounds, only the new diff is reviewed, to avoid repeatedly reporting issues already seen.

Human reviewers are still important: deciding whether to build the feature, auditing dangerous code (billing, auto-updaters, CI), architecture review, verifying proof (test output, commands, screenshots, review comments), and taking responsibility. Every line of code that ships has a specific person accountable for it.

The way teams pass context has also changed. No one has the whole codebase in their head. If you want to understand a piece of code, have Claude generate an explainer—a few minutes, and in real time. Some people also have Claude make a mini artifact that visualizes the code and explains it in their own style.

“You merge it, you own it.” If a small change causes a problem, by default you fix it yourself. Small changes are easy to review, easy to debug, and easy to roll back. Feature flags and staged rollout can reverse most mistakes within minutes. High-risk code gets more eyes. It isn’t a blame culture; the person who ran into the problem has the most context.

The long post spread quickly among developers, and the comments included many substantive discussions. Gaurang Karia posted an image saying the shape of review has changed. In the past, people looked at the code itself; now they look at intent: the goal, the why, and what it is trying to achieve.

One commenter said that now everyone on the team maintains their own code review, with inconsistent angles, which is inefficient, though they can catch risks the others miss. Another added that human decisions haven’t been systematized.

One commenter summarized: the core isn’t having AI look at code; it’s having it give consistent judgments according to team standards. If the standards aren’t written clearly, AI will only amplify disagreements.

Some questioned whether the 40% drop in rollbacks was just benefiting from lower iteration costs—if there’s a problem, one prompt can fix it. That was rebutted with one line: a 40% reduction means there were at least 40% before.

Cost was also mentioned. Running this whole system is unaffordable for an average company. One developer replied that they are pushing to raise the AI R&D subsidy to 3,000 per month.

At the end of the article there’s an implementation checklist. A quick summary:

Before the PR: write runnable checks into CLAUDE.md, configure hooks, run /code-review and /security-review locally, and create REVIEW.md to record recurring problems.

For every PR: enforce CI. Add three columns to the PR template: how it was tested, risk, and how to roll back. Add an AI reviewer and automated security review. All review threads must be resolved before merging. Routine changes go through quickly; high-risk areas get deeper review.

Approval: the risk level is determined by the change. Start strict and relax after you have data. Only the trusted list gets relaxed requirements. Bot approvals don’t count. Use CODEOWNERS to lock down sensitive paths.

Merging: use a merge queue. Feature flags. Internal trial first. Staged rollout. One-click rollback. Use incidents and reverts as evals to keep iterating.

One developer gave a fitting summary: Claude writes code, Claude reviews code—this is the closest the software industry has come to a “self-cleaning oven.”