How the Claude Code team does code review

來源原標題

How the Claude Code team does code review

機構

Anthropic

原始標籤

Best practices

原始連結

https://claude.dev/blog/solving-code-review-at-anthropic/

摘要原文

We've said before that Claude writes about 90 percent of Claude Code's own code. So how do we review code at the volume we produce it? Does anyone read code anymore? And if something breaks, who catches it? This post covers the code review flow on the Claude Code team and how it has evolved. 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. We didn't remove review. But we did move most of the reading to machines, optimized for human time and attention, and invested heavily in making it fast and easy to undo mistakes. RETHINKING THE PURPOSE OF CODE REVIEW When agents write code, the number of changes goes up, fast. In Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September this year. Claude Code lives in its own repository, separate from the monorepo, but it's seeing a lot of pressure too. When you are shipping this fast, manual, line-by-line code review is incredibly difficult if not impossible. Code review does two jobs: Find and fix issues before they ship Build shared context and codebase understanding across the team This article mainly focuses on finding and fixing issues, but we will come back to the second job near the end. We think "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check—automated or human—is the right one to catch it?" Asking that question also changed when review happens. Before, review was a gate at the end of the road: write the code, open a PR, wait for your colleague. Now, review runs continuously, more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny. THE SCARCE RESOURCE: HUMAN TIME AND ATTENTION We want to preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest. At our current rate of change, there is still an incredible amount of work for humans to do, and our team encounters new and novel challenges almost daily. Human time covers both sides of review's cost: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first doesn't help if the time just shows up in the second. So the goal is that most pull requests in the Claude Code repos (the CLI, the desktop and web apps, and the mobile apps) merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. To measure human time, we track human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, we haven't saved human time, we've only moved it. THE LIFE OF A CHANGE A typical change, from an engineer's laptop (or a Claude session in Slack), goes through multiple layers of code review. The life of a change png A typical Claude Code change, from the author's machine to users BEFORE THE PULL REQUEST The work is verified Claude runs the tests, build and linter; a second agent reviews the diff in a fresh context ON EVERY PULL REQUEST Required CI Lint, types, tests across platforms, build and packaging. Red blocks the merge Claude code review Agents hunt for bugs in parallel, verifiers vote on each finding, survivors ranked by severity Security review A separate pass. Open findings from either review block the merge Risk-based approval A classifier sets the tier: no person, one, or two. Some paths always need a person MERGING Merge queue Checks run again on the latest main with the change applied AFTER THE MERGE Behind a flag, used internally first Anthropic employees run it before it reaches everyone Gradual release The latest channel first; the stable channel trails it Watch, fix forward or roll back The author and on-call watch; flags turn off quickly, broken builds get reverted automated a person decides, scaled by risk recovery BEFORE THE PULL REQUEST The work is verified Claude runs the tests, build and linter; a second agent reviews the diff in a fresh context ON EVERY PULL REQUEST Required CI Lint, types, tests across platforms, build and packaging. Red blocks the merge Claude code review Agents hunt for bugs in parallel, verifiers vote on each finding, survivors ranked by severity Security review A separate pass. Open findings from either review block the merge Risk-based approval A classifier sets the tier: no person, one, or two. Some paths always need a person MERGING Merge queue Checks run again on the latest main with the change applied AFTER THE MERGE Behind a flag, used internally first Anthropic employees run it before it reaches everyone Gradual release The latest channel first; the stable channel trails it Watch, fix forward or roll back The author and on-call watch; flags turn off quickly, broken builds get reverted automated a person decides, scaled by risk recovery FIG A Most of the path is automated; a person's attention goes where the risk is LAYER BY LAYER Layers, not one gate png Six layers of checks, with rollback under them problems in verification required CI AI review security review human approval merge queue + flags fast rollback problems in verification required CI AI review security review human approval merge queue + flags fast rollback FIG B Each layer catches some problems and misses others. Few get through all of them, and rollback handles the rest. 1. The work is verified before anyone else looks Most review now happens before a PR exists. We give Claude something it can run—like tests, a build or a screenshot to compare against the design—and ask it to show the output instead of saying it's done. Then a subagent reviews the diff with fresh context. Both habits come from our best-practices guide . Before opening a PR, many of us also run a few internal skills: one hunts for bugs, one simplifies the diff, and one checks the behavior end to end. UI changes also get checked against our design guidelines. Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results. He estimates it makes the final result two to three times better, and writes, "Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator." When the automated reviewer keeps flagging the same thing, we fix it at the source: in the skill, with a lint rule, or with updates to instructional files such as: CLAUDE.md tells Claude what the project is: the stack, the conventions, the goals and the non-goals. Every review loads it, so in a large codebase we keep it short and point to other docs from there. The reviewer also flags code that breaks a convention in it, and changes that make a line in it out of date. REVIEW.md , written by code owners, tells the reviewer what matters in their part of the code. We check separately whether the reviewer actually follows it. The good ones are short. They say what failure looks like in that repo (for docs it's "it lies," for config it's "it misroutes"), cap the nits, list paths to skip, and ask for a file and line as evidence instead of a guess from a name. They also ask for a summary that starts with a count and says plainly when there's nothing to fix. 2. AI review on every pull request Every pull request gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent, and asks: does the change solve its problem, fit the system, or break something else? On a bug fix, it looks for the root cause. The public version, Code Review for Claude Code , is now generally available on Team and Enterprise plans, and /code-review runs a lighter version locally.