How the Claude Code Team Does Code Review: Risk Tiers and a Cap on Review Rounds

Anthropic recently disclosed the code review process used by the Claude Code team in high-output agent scenarios. Faced with large volumes of AI-generated code changes, traditional line-by-line human review has become unsustainable. The team's approach: layered checks, human approval scaled by risk, a cap on review rounds, and converting incidents into evaluation cases. This methodology has direct reference value for any engineering team scaling up its use of AI coding assistants.

Layered checks: let automation filter out most problems first

The Claude Code team's review process is not a single gate but a layered filtering system. The bottom layer is handled by automated tooling — static analysis, type checking, test suites, and other routine measures run first, keeping mechanical issues out of human review. Only changes that pass automated checks proceed to the next layer.

The key to this layered approach is acknowledging a reality: when agents commit code at high frequency, human reviewers' attention is the scarcest resource. If problems that automation could catch consume human time, the whole process quickly clogs. Automation's job, then, is not to replace people but to ensure people only see the parts that genuinely require judgment.

For teams using Claude Code or other AI coding tools, this means first building solid CI pipeline infrastructure. Without reliable automated checks as the first line of defense, the risk tiering and human approval that follow have no foundation.

Static analysis, type checking, and test suites primarily serve as quality gatekeepers in traditional CI, but in scenarios where agents commit at high frequency, their role shifts: from "last line of defense" to "first layer of filters." Static analysis inspects syntax structure, data flow, and common defect patterns without executing code; type checking catches interface mismatches at compile time; test suites verify that behavior matches expectations. Combined, the three can intercept large numbers of mechanical errors at very low marginal cost, leaving only semantic judgment questions in the human review queue. This is also why the article stresses building CI infrastructure first — the coverage and reliability of automated checks directly determine whether the subsequent layers are effective.

Risk tiering: human approval intensity scales with risk

After layered checks, changes that reach human approval are not treated uniformly. The Claude Code team scales the intensity of human review according to the risk level of the change — high-risk changes require stricter human confirmation, while low-risk changes can go through a lighter-weight process.

The logic behind this design: if all changes require the same intensity of human review, either the review becomes a formality or the team's throughput gets bottlenecked by review. Risk tiering concentrates review resources on changes that could genuinely cause harm. Although Anthropic did not disclose the specific dimensions used for risk tiering, from an engineering practice perspective they typically involve factors such as the sensitivity of the modules touched, the scope of impact, and whether security boundaries are involved.

You may not have noticed that this tiering is not a static label but a dynamic mechanism matched to the scale of agent output. As agent submissions rise, the tiering rules act as a distribution valve, preventing the human review queue from expanding without limit.

Risk tiering is not a new concept in software engineering — change advisory systems, code ownership (CODEOWNERS) mechanisms, and release approval processes all reflect similar thinking. Common dimensions include: whether the change touches sensitive paths such as authentication, payments, or data deletion; the size and impact surface of the diff; whether public interfaces or configuration are modified; and the trustworthiness of the change's source. In high-output agent scenarios, these dimensions need to be explicitly encoded as rules or scoring models to automatically route changes into approval channels of different intensity. For risk tiering to remain effective, it must also be recalibrated periodically as the system evolves; otherwise the rules gradually drift out of sync with the actual risk distribution.

Round cap: setting a hard boundary on the review loop

In agent-involved code review, an easily overlooked problem is that the review loop can continue indefinitely: the agent revises based on feedback, the revision is reviewed again, revised again… without a boundary, a change can cycle repeatedly between review and rework, consuming large amounts of time and tokens.

The Claude Code team's response is to set a cap on review rounds. Once the cap is reached, the process must make a decision — either accept the current state or escalate — rather than continuing to iterate endlessly. This mechanism seems simple but strikes directly at a pain point in agent workflows: agents are highly capable of revising, but without a termination condition, that strong revision capability becomes an excuse for delay.

For teams building similar processes, the specific number of rounds needs to be set according to their own business tolerance, but the core principle is clear — the review loop must have a hard termination condition and cannot rely on the agent or the reviewer to decide when to stop.

A review round cap is essentially a termination condition design, isomorphic to retry limits in distributed systems and maximum iteration counts in workflow engines. Without an explicit termination condition, an agent's self-correction loop can fall into a local oscillation of "revise—feedback—revise again": each round looks like an improvement, but overall it does not converge, while continuously consuming tokens, reviewer attention, and calendar time. Once a cap is set, the handling strategy at the boundary is equally important — accepting the current state means acknowledging "good enough," while escalating hands the decision to a higher-level judge. Both paths need to be defined in advance during process design to avoid a stalemate where no one decides when the cap is triggered.

Incidents as evals: turning production problems into test cases

The most long-term valuable part of this process is converting incidents into evaluation cases (evals). Whenever a problem occurs in production, the team does not stop at fixing it but distills the problem scenario into part of the evaluation set, used to subsequently verify the agent's behavior.

This practice turns code review from passive gatekeeping into active capability building. Incidents are no longer just fires to be put out but inputs for improving the quality of agent behavior. As the evaluation set accumulates, the team's ability to control the quality of agent output continuously strengthens. This also echoes a consensus in the AI engineering field: an evaluation-driven development loop is key to making AI systems reliable, and real incidents are the evaluation material closest to the actual distribution.

Evaluation cases (evals) are standardized test sets for measuring the behavioral quality of AI systems, typically composed of input samples and criteria for judging expected behavior. In agent coding scenarios, evaluation sets can cover dimensions such as code generation correctness, instruction following, and edge-case handling. The value of converting production incidents into evaluation cases lies in this: incidents represent failure modes in the real distribution, closer to actual risk than manually constructed synthetic tests. This practice is in the same lineage as the regression testing philosophy in software engineering — every bug fix should come with a test that can reproduce the bug. The difference is that agent evaluation verifies not only code results but also whether the agent's behavior in a specific situation is acceptable, so the accumulation of the evaluation set directly constitutes a mechanism for continuously constraining and improving agent capability.

Implications for teams scaling up AI coding

The Claude Code team's process can be summarized as four reusable principles: use layered automation to filter out mechanical problems, use risk tiering to allocate scarce human attention, use a round cap to prevent the review loop from spiraling out of control, and use the incident-to-eval conversion to achieve continuous improvement.

The common foundation of these principles is acknowledging that the scale of agent output has exceeded the design capacity of traditional review processes. Copying the specific rules may not be appropriate, but the approach to process design — putting people where judgment is genuinely needed and making boundary conditions explicit — is worth learning from for any team expanding its use of AI coding tools.

One-line Summary

Anthropic is not disclosed in this article; the Claude Code team discloses a four-layer code review methodology for high agent output.

Paragraph Summary

Anthropic disclosed the Claude Code team's code review process in high-output agent scenarios, centered on layered filtering and risk scaling. The process first uses automated means such as static analysis, type checking, and test suites to intercept mechanical problems, then scales human approval intensity by change risk level, concentrating scarce human attention on high-risk changes. It also sets a cap on review rounds to prevent the rework loop between agent and reviewer from continuing indefinitely. The most long-term valuable part is distilling production incidents into evaluation cases, turning code review from passive gatekeeping into agent capability building. The premise of this methodology is acknowledging that agent output scale has exceeded the capacity of traditional review processes, and it has direct reference value for teams scaling up their use of AI coding tools.