With 90% of the code written by AI, who will be responsible for the review? Claude Code rolls out 6 checkpoints!

About 90% of Claude Code's own code has been written by Claude itself.

With AI taking over coding work, the volume of changes has skyrocketed: from June to September, the number of PRs merged into the codebase more than doubled.

Across Anthropic, the number of daily merged changes to the main codebase jumped from around 2500 in May to over 30000 in September.

With such a massive volume of code, can humans still review all of it? If even the review work is handed over to AI, who will judge whether it makes mistakes?

On October 15, the Claude Code team made public their internal code review process, disclosing that while the number of PRs doubled, the proportion of PRs that needed to be rolled back decreased by more than 40% relatively.

To achieve this, they rely on six layers of checks, plus a fallback mechanism for rapid problem detection and fast rollback.

The Claude Code team concluded that:

At this scale, manual line-by-line review is no longer feasible.

But they did not cancel reviews entirely. Instead, they assigned most of the code reading work to machines.

Before release, a piece of AI-generated code will first run tests, go through AI review and security review, then decide whether human approval is required based on its risk level.

From the perspective of the Claude Code team, the question "has anyone read this piece of code" is not precise enough.

The real question should be:

What errors could this change cause, and which check layer is supposed to block the error if it occurs?

Before Manual Review, AI Presents Verification Results First

One single change needs to pass six layers of checks, with an extra safety net at the end.

The first checkpoint comes before you create a Pull Request (PR).

Claude needs to run tests and complete the build process; for UI-related changes, it also needs to generate screenshots to compare with the design drafts.

After that, a sub-agent with a completely new context will be assigned to review the code diff. This sub-agent did not participate in writing the code, and is dedicated to finding flaws.

The official requirement is very clear:

Claude must present all executed commands and their outputs. A simple reply saying "all tests passed" is not acceptable.

Ordinary developers can also follow this practice: when assigning tasks to AI, clearly state the acceptance criteria together with the task requirements.

The second checkpoint is the AI review on the PR page.

Multiple agents run in parallel to find bugs, then another group of agents will vote to verify the issues. Only when enough votes are cast will the issue be posted to the PR.

Comments that only involve code style, diagnostic prompts or code cleanup will not be sent to the PR, and will be filtered directly.

When this review system was first launched in March, the proportion of internal PRs that received substantive review comments rose from 16% to 54%.

The third checkpoint is security review.

Within the team, as long as findings left by code review or security review are not closed, the PR cannot be merged: you either fix the issue, or state the reason to close the finding.

The fourth checkpoint is Continuous Integration (CI) checks, including code specification verification, type checking, cross-platform testing, and build packaging.

A regular Command Line Interface (CLI) change may need to run dozens of checks before it is sent for human review.

Recurring issues will also be added as the basis for future checks.

The CLAUDE.md file records project conventions, and the REVIEW.md file tells the reviewer what to focus on and what can be skipped, so that problems found this time become the experience for the next review.

If the same comment is mentioned for the third time, it should be written into the formal rules.

The fifth checkpoint is manual approval, which is the most critical step, and we will elaborate on it in the next section.

The sixth checkpoint is merging and release.

After passing all the previous checks, the change will enter the merge queue and wait in line.

When it is its turn, the system will place it on the latest version of the main branch, and run all checks again.

This step is designed to prevent the scenario where "each individual part works fine, but errors occur when they are combined".

After merging, new features will not be pushed to all users immediately.

They will be hidden behind feature flags first, and only accessible to internal Anthropic employees. Employees use these features with high intensity every day, and usually encounter problems earlier than external users.

The feature flag works like a master switch: you can turn the feature on or off without modifying any code or releasing a new version.

The last part is the fallback mechanism.

If a problem occurs, pull the master switch first.

The team takes turns on duty every week. After every incident, the post-mortem review will ask: at which checkpoint should this incident have been blocked?

Therefore, review has not disappeared. It has evolved into layers of checks running through the entire development, merging and release process.

What Is the Boundary of Zero-Human Approval

After the first four checkpoints all pass, the fifth checkpoint will determine how many people are required to approve this change based on risk classification.

Changes to documents, copywriting, features only visible internally, and new changes hidden behind feature flags are classified as low-risk. After passing automated review and security checks, they can be exempted from manual approval.

Regular product changes, as well as sensitive areas like caches, auto-updaters, and system prompts, require approval from one person.

Highest-risk code, plus a small number of specified paths, require approval from two people.

It seems that low-risk changes have already achieved "fully autonomous operation"?

It is not that simple.

The risk level is determined by the change itself: the first classifier reads the code to determine the risk, and the second classifier judges whether additional manual approval is required.

Sensitive paths marked by code owners, and all CI workflow files must be reviewed by a human.

The lightweight approval channel also has thresholds: it is only open to people on the "trusted authors" list of the repository. People outside the list must find another person to approve their changes.

The person who directs AI to write code is a reviewer themselves, and they are responsible for this change just as if they wrote the code by hand.

Zero-human approval does not mean no one is responsible.

Humans need to decide whether a feature should be built, whether the architecture is reasonable, and judge whether existing checks can cover all risks of this change.

Therefore, the Claude Code team has a rule: if problems occur in the code you merged, you are usually the one to fix it.

Before clicking approve, the reviewer must make clear: what have these checks verified, and what risks are not yet covered.

If you cannot explain clearly, do not click pass in a hurry. Complete the necessary review first.

AI Review Can Also Malfunction

Automated review can also get stuck itself.

A PR for a CLI project went through more than 50 rounds of review and fixes overnight, until the author manually stopped the process.

A human can ignore a minor flaw in a second, but AI cannot. It will honestly try to fix the flaw, generate a new commit after the fix, and trigger a new round of review.

The team used git blame to trace back, and found that about 59% of the problems repeatedly flagged by the reviewer were old code that existed before the first round of review. The reviewer rarely found new bugs, it just dug up a few more old issues in each round.

Later they modified four rules:

If the change still fails to pass after three full rounds, remind the author to step back and rethink the solution;

After the first few rounds, only review the newly added changes;

Point out all similar problems at one time;

Do not repeat issues that have already been mentioned.

The effect was immediate.

The proportion of internal PRs that passed after one round of review and fix rose from 65% to 78%; the proportion of PRs that needed five or more rounds dropped from 8.9% to 1.5%; the average number of review rounds fell from 2.08 to 1.32.

After adjusting the re-review rules, the pass rate after one round of review and fix rose from 65% to 78%, and the average number of review rounds dropped from 2.08 to 1.32.

The skill of review lies half in finding problems, and half in knowing when to stop.

Does multi-layer review mean absolute safety?

Anthropic itself once gave a counterexample.

On March 26, Claude Code launched an optimization: when a session is idle for more than an hour, the system will clean up old inference records.

But a bug made it run the cleanup process in every round after the conversation was resumed. As a result, Claude became forgetful, started to repeat itself, and behaved abnormally when using tools. This bug was not fixed until April 10.

After being idle, the system was supposed to clean up old inferences only once, but it kept cleaning in every subsequent round; the red box marks the incorrectly deleted content.

The official post-mortem review published on April 23 admitted:

This change passed multiple rounds of manual and automated review, and neither unit tests, end-to-end tests, nor internal beta testing blocked it. It took more than a week just to confirm the root cause.

The turning point came during the post-mortem review.

The team re-reviewed the problematic PR with Code Review. When provided with full context of related repositories, Opus 4.7 found this bug, while Opus 4.6 did not.

This retest showed that both model capability and context completeness will affect the detection result. Therefore, they allowed the reviewer to import more repositories for context.

Now, every incident will be turned into a test question.

The team collects PRs, and engineers who are familiar with the code confirm the bugs in them one by one, and organize these cases into a test set.

The reviewer runs benchmarks against this test set every day. Every time they adjust the prompts, tools or models, they will use this test set to verify the effect: if the performance does not improve, this adjustment will not be adopted.

The team did not overpromise either.

After changes are released, developers and on-duty staff still need to discover anomalies by referring to data dashboards.

The "circuit breaker" mechanism that automatically tightens approval rules based on indicators such as rollback rate has not been built yet. The engineers hope to complete this safety measure first, before allowing more changes to go through the zero-human approval process.

Review will inevitably miss some issues, so rapid detection and remediation must also be in place.

A member of the Claude Code team explained this way: Slowing down can indeed reduce errors, but that is mainly because you do much less work overall. So they prefer to put their effort into finding problems faster and fixing them faster.

What Should You Acceptance When One Person Uses AI to Write Code

AI review only provides suggestions, you are the one who makes the final decision.

Therefore, do not rush to pursue the state of "no need to check at all". Instead, ask AI to answer three questions every time it delivers work.

First, how was the work verified?

What checks were run, what are the results, and what scenarios are not yet covered.

Boris Cherny, the creator of Claude Code, once said that giving Claude a way to verify its own work is probably the most important thing. He estimates that this can make the quality of the final result reach 2 to 3 times of the original level.

Boris Cherny suggests letting Claude verify its own work to form a feedback loop; he estimates that the quality of final results can be improved to 2-3 times of the original level.

Second, what areas will this change affect?

Which users, data and permissions are involved in the change.

If you ask AI to add a sharing function to a reporting tool, you need to make clear: who can open the link, and what can they see after opening it.

Third, how to roll back if something goes wrong? Can you turn off the new feature with one click and revert to the previous version.

Commit and archive your work before you start, and keep each change as small as possible. Make sure you can roll back first, then talk about reducing review work.

In addition to these three questions, develop three more habits.

First, re-review with a different "mind".

The session you used to write code is most likely to turn a blind eye to its own bugs.

Open a new session, or let a sub-agent re-review with a completely new context. You can also run the local /code-review and /security-review commands directly.

Second, classify changes by risk level.

For changes to copywriting and style adjustments, merge them after passing checks and confirming the actual effect; for changes involving login, payment, and data deletion, conduct careful manual review of key logic, and add targeted tests.

Be stricter at the beginning. After the verification and rollback process runs smoothly, gradually reduce manual review for low-risk changes.

Third, if it still does not pass after three rounds, change your mindset.

If AI has made three rounds of fixes but is still stuck, do not push it to do a fourth