Anthropic's Claude Code team has moved most of its code review to machines, and the company says the results hold up. From June to September, merged pull requests to Claude Code's codebase more than doubled, while the share that had to be reverted fell by more than 40 percent. The team says Claude writes about 90 percent of Claude Code's own code.

The volume is what forced the change. In Anthropic's main monorepo, the number of changes landing each day rose from about 2,500 in May to more than 30,000 in September. Claude Code sits in its own repository, separate from the monorepo, but the team says it faces similar pressure. "When you are shipping this fast, manual, line-by-line code review is incredibly difficult if not impossible," the team wrote.

The team's stated goal is not to eliminate human review but to spend human attention where it matters most. Most pull requests should merge with no more than one person involved, and that person can be the author, with no increase in reverts or incidents. The team tracks human approvals per pull request, human comments and how long a pull request waits on a person. Revert and incident rates act as a guardrail. If they climb, the team has not saved time. It has only shifted the work to later cleanup.

Review now starts before a pull request exists. Engineers give Claude something it can run, such as tests, a build or a screenshot to compare against a design, and ask it to show the output rather than simply say the work is done. A subagent then reviews the diff with fresh context. Boris Cherny, who created Claude Code, has said that giving Claude a way to verify its own work is probably the most important factor in getting good results. He estimates it makes the final result two to three times better.

Once a pull request is open, Claude reviews every one before a person looks at it. The reviewer reads the change against the full repository and the stated purpose of the pull request. Anthropic's public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans. When the team first tested the internal reviewer, the share of pull requests getting substantive comments rose from 16 percent to 54 percent. Most pull requests over 1,000 lines receive findings, while most small ones come back clean.

Findings are checked by other agents before a human sees them. Several agents look for bugs at once, and a separate group votes on each finding. Only findings that enough agents agree are real get posted. Style, diagnostic and cleanup comments are dropped. Every remaining comment must be either fixed or resolved with a reason, and a pull request cannot merge while a bug or security finding remains open.

Human approval depends on risk. Low-risk changes, such as documentation fixes or additive features behind a flag, need no human approval once automated checks pass. Medium-risk changes need one person. The highest-risk code requires two. A classifier sets the tier based on the change itself, not the author, and some sensitive paths always require a person. An agent's approval never counts as a human's. The person who asked the agent for the change is one of the required reviewers.

The system is not perfect, and the team says so. Some mistakes still get through. The merge queue re-runs checks against the main branch with each change applied. New behavior typically ships behind a flag to Anthropic employees first, and feature flags can be turned off without a deploy. The team has a weekly on-call rotation, but it does not yet have automated circuit breakers that tighten approvals when revert or incident numbers rise. Engineers want those before more code moves to merges with no human involved.

The team also found a problem with its own reviewer. One command-line pull request went through more than 50 rounds of review and fixes overnight before its author stopped it. When the team examined what the reviewer kept flagging, about 59 percent involved code that had been there since the first review pass. The reviewer was rarely finding new bugs. In the team's words, it was finding a few more old ones each round. In response, the team capped review rounds at three, after which the reviewer asks the author to reconsider the approach, and it now re-reviews only new changes after the first few passes.

Humans still handle decisions machines are poor at. Engineers decide whether a feature should be built at all, review risky code such as billing, the auto-updater and continuous integration workflows, and weigh in on architecture that others will copy. They also read the evidence behind a change and remain accountable for everything that ships. The team's norm is simple: if you land a change and something breaks, you usually fix it.

Dieser Artikel wurde mit Unterstützung von KI verfasst.
News Factory APP - agentische News für besseres SEO & AEO.