About 90 per cent of Claude Code’s own code is written by Claude. Handing the writing to a model did not reduce the volume of change. It multiplied it. Between June and September the number of pull requests merged into the codebase more than doubled.
Across Anthropic, the main repository went from roughly 2,500 merged changes a day in May to more than 30,000 a day in September.
Which raises the question the team had to answer. Can humans still read this much code? And if review is also handed to AI, who decides whether the AI is wrong?
On 15 October the Claude Code team published its internal review process. The headline finding is that while pull request volume doubled, the share of PRs requiring a rollback fell by more than 40 per cent in relative terms. Six layers of checking, plus a fast-detect and fast-revert mechanism, produced that.
The team’s judgement is that at this volume, reading every line by hand is no longer realistic. Review was not cancelled. Most of the reading was handed to machines.
A change written by AI now runs tests, passes AI and security review, and then gets human approval only where risk requires it. In the team’s framing, whether a human read the code is the wrong question. The right one is what could go wrong with this change, and which check should stop it.
Six gates, in order
The first gate fires before a pull request exists. Claude runs the tests and completes the build, and for interface changes it screenshots the result against the design. A sub-agent with an entirely fresh context then reviews the diff. It did not write the code, so its job is to find fault. The requirement is explicit: Claude must show the commands it ran and their output. Replying that all tests pass does not count.
The second gate is AI review on the PR itself. Several agents hunt for bugs in parallel, and a second group votes to verify. A finding is posted only when the votes clear. Comments limited to style, diagnostics or cleanup are filtered out entirely. When this system launched in March, the share of internal PRs receiving substantive review comments rose from 16 per cent to 54 per cent.
The third gate is security review. Inside the team, any finding left open by code review or security review blocks the merge. It has to be fixed, or closed with a written reason.
The fourth is continuous integration: lint, type checking, per-platform tests, packaging. An ordinary change to a command-line tool may run dozens of checks before it reaches a human. Recurring problems become the basis of the next check. CLAUDE.md records project conventions, REVIEW.md tells the reviewer what to look for and what to skip, so that a problem found once becomes a rule the next time. If the same comment is raised a third time, it goes into the rules.
The fifth gate is human approval, and it is tiered. Documentation, copy, internal-only features and new changes hidden behind a flag are low risk, and can ship without a human once automated review and security pass. Ordinary product changes, and sensitive areas such as caching, the auto-updater and system prompts, need one approver. The highest-risk code and a small set of designated paths need two. Two classifiers do the sorting: the first reads the code and assigns risk, the second decides whether extra human approval is needed. Paths marked by code owners and all CI workflow files always require a human. The light approval lane is restricted to a trusted-author list, and authors outside it must find another approver.
The person directing the AI counts as a reviewer and carries the same responsibility as if they had typed the code themselves. Zero approvals does not mean zero accountability. A human still decides whether a feature should exist, whether the architecture is sound, and whether the existing checks cover this risk. The team’s rule is blunt: if your merge breaks something, you fix it. Before approving, the reviewer has to say what the checks verified and which risks remain uncovered.
The sixth gate is merge and release. Once a change clears everything it joins a merge queue, gets rebased onto the latest main, and runs every check again. That catches the case where each change is fine alone and the combination is not. After merge, new features are hidden behind a flag and opened to Anthropic staff first, on the theory that heavy internal use finds problems before external users do. The flag is the master switch, and pulling it requires no code change and no redeploy.
The safety net sits underneath all of it. When something breaks, pull the switch first. The team runs a weekly on-call rotation, and every postmortem asks which gate should have caught the failure.
The reviewer that would not stop
Automated review can also jam itself. One pull request in a command-line project went through more than fifty review and fix rounds overnight before the author stopped it by hand. A human ignores a small blemish in a second. The AI dutifully fixes it, which produces a commit, which produces another review.
Using git blame, the team found that roughly 59 per cent of the issues the reviewer kept flagging were old code that existed before the first review. It was rarely finding new bugs. Each round simply excavated a few more old ones.
Four rules followed. After three failed rounds, prompt the author to step back and rethink the approach. After the early rounds, review only new changes. Raise a class of issue once. Never repeat a comment already made. The effect was immediate: the share of internal PRs passing after one review and fix round rose from 65 per cent to 78 per cent, the share needing five or more rounds fell from 8.9 per cent to 1.5 per cent, and mean reviews per PR fell from 2.08 to 1.32.
Half of review skill is finding problems. The other half is knowing when to stop.
The bug that passed everything
Anthropic has its own counterexample. On 26 March Claude Code shipped an optimisation that would clear old reasoning records once a session had been idle for an hour. A bug made it clear those records on every turn after a conversation resumed. Claude became forgetful, began repeating itself, and used tools oddly. The bug was not fixed until 10 April.
The postmortem on 23 April conceded that the change had passed multiple rounds of human and automated review, unit tests, end-to-end tests and internal dogfooding. Confirming the root cause took more than a week. When the team re-ran review on the offending PR with enough repository context, Opus 4.7 found the bug and Opus 4.6 did not, which showed that both model capability and context completeness change detection outcomes. Review was subsequently allowed to pull in more of the repository.
Every incident now becomes an exam question. The team collects PRs, has engineers who know the code confirm the bugs in them, and builds a test set. The reviewer is scored against it daily, and any change to prompts, tools or models has to beat the existing score or it is not adopted.
They have not oversold it. After deployment, developers and on-call staff still have to find anomalies in the dashboards. The circuit breaker that would automatically tighten approval requirements based on rollback rates has not been built. The engineers want that insurance in place before more changes go through with zero approvers.
One team member’s explanation of the trade-off is the most useful line in the whole disclosure. Slowing down does reduce errors, but mainly because you do less. The team would rather spend the effort on detecting and fixing faster.
What to require of an AI that writes your code
AI review offers opinions. The decision remains human. Claude Code’s creator, Boris Cherny, has said that giving Claude a way to verify its own work may be the single most important thing you can do, and he estimates it lifts final quality to two or three times what it would otherwise be.
Three questions make that concrete. How was this verified, meaning which checks ran, what they returned, and what remains uncovered. What does it affect, meaning which users, data and permissions the change touches. And how is it reversed, meaning whether the feature can be switched off and the previous version restored.
Three habits follow. Re-review with a different brain, because the session that wrote the code is the worst judge of its own bugs. Tier the changes, so copy and styling merge after checks pass while login, payment and deletion get detailed human inspection. And after three failed rounds, change the approach rather than prompting a fourth time.
The most important point is the least technical. AI saying it passed is not acceptance. You asked for the code, and the result in production is yours. The team’s goal is for most pull requests to need at most one human while holding the rollback and incident rates. Human attention goes to judging risk, confirming the checks are sufficient, and deciding how to recover. Nobody has to read every line, but every release still needs someone accountable for it.
Editor’s note: This is an adapted translation of the original 36Kr report. It has been trimmed and restructured for readability for an international business audience. The full original (in Chinese) is at https://36kr.com/p/4060672855757954.