How Claude Fixes Its Own Code: Inside Anthropic's Internal Review Process

When AI agents write code faster than humans can review it, code review itself must be rewritten. The changes that Anthropic's Claude Code team experienced in their own repository offer a rare sample for all engineering teams: from PRs piling up every second to using Agents to review Agents, they figured out a process that reserves human attention for truly critical issues.

A Change Forced by Necessity

According to the Anthropic team cited in the video, Claude currently writes about 90% of Claude Code's own code. This proportion was about 85% a year ago, and as model capabilities improved, the number of merged PRs within the team more than doubled from June to September, while the proportion of PRs requiring rollback during the same period dropped by over 40%.

A more striking figure comes from Anthropic's main repository: code changes landing daily grew from 2,500 in May to over 30,000 in September. At this scale, line-by-line manual review is not just difficult—it's impossible. The team's judgment was direct: they handed most code reading to machines and reserved human time for problems only humans can solve.

Reframing the Goals of Code Review

The Claude Code team split code review into two goals: first, finding and fixing issues before merging; second, building shared understanding of the codebase within the team. The video author believes the latter has long been underestimated—reading a colleague's diff is how you understand how the system fits together.

But the team admits they don't have a formal process to guarantee the second part. No one on the team maintains a complete mental model of Claude Code. The alternative: when you need to understand a piece of code, just ask Claude to write an explanation document for that slice, and within minutes you get a description reflecting the current state. Reading a module-level explanation is far more valuable than reading line-by-line through PDF-style trivial changes.

From "Has Anyone Read It?" to "Which Layer Can Catch It?"

The team proposed a key shift: stop asking "has a human read this code" and instead ask "what could go wrong with this change, and is automated or human inspection the right tool to catch it?"

The video author resonates deeply with this. He states that in the regression issues launched on T3 Chat and T3 Code, whether or not he reviewed the code, these were not issues that could be found during code review. Today's defect types cannot be found by staring at code for a long time.

A detail from the author's perspective: most Agents' code review capabilities now exceed most humans. If this isn't the case on your own codebase, the problem lies in the codebase itself.

Layered Defense: From Local Validation to Merge Queue

Typical changes in the Claude Code team go through multiple layers of review.

Layer 1: Validation Before the PR Exists

Most review happens before the PR is created. The team provides Claude with runnable validation targets—tests, build artifacts, screenshots compared against design mockups—and requires it to show output rather than claim completion. Then a sub-Agent reviews the diff in a fresh context.

The author adds his own approach: using T3 OS to allocate a separate window for each thread, letting the Agent launch the Electron dev server, record a demo video of changes, and attach it to the PR. He also added preset fake model selections so the Agent can run full end-to-end tests without consuming extra tokens.

According to Boris (the original author of Claude Code), providing Agents with validation methods can improve final results by two to three times.

Layer 2: AI Review and Security Check

Each PR first goes through Claude Code review: multiple Agents are launched in parallel to hunt for bugs, a verifier votes on findings, and they are sorted by severity. Then comes an independent security check pass, followed by a classifier that determines the risk level to decide whether zero, one, or two approvals are needed.

The team published a set of data: after the review research preview launched, the proportion of internal PRs receiving substantive review comments rose from 16% to 54%. PRs over a thousand lines mostly find issues, while small PRs mostly return clean.

Verifier Voting is a noise-reduction mechanism where multiple parallel Agents independently judge the same candidate defect, and a majority vote decides whether the finding is credible. Its value lies in the high false-positive rate of large model review: a single judgment easily mistakes stylistic preferences or misreadings for bugs. Parallelization plus voting trades inference cost for accuracy, and naturally fits horizontally scalable Agent architectures. The cost is increased token overhead, and when multiple Agents share the same model bias, voting cannot correct systematic misjudgments. Therefore, sorting by severity is still needed to reserve human attention for high-risk findings.

Security review pass and risk classifier typically refer to a separate round of checks run after functional review, focusing on security dimensions like privilege escalation, command injection, key leakage, and dependency introduction. These differ from logical correctness review in focus, and running them separately avoids mutual interference. Then a classifier assigns a risk level based on signals like files involved, scale, and sensitive modules, routing approvals to different levels of human effort. The classifier itself should remain conservative: better to escalate a change to manual approval than to misjudge a high-risk change as low-risk and let it through.

Layer 3: Risk-Tiered Approval

Low-risk changes can be merged directly when CI is all green, medium-risk requires one person, and high-risk requires at least two. Approval looks at risk level, not a specific designated reviewer.

An important boundary: only authors on the repository's trusted list can take the lightweight path, and Agent approval can never replace a human approval slot.

Layer 4: Merge Queue and Gradual Rollout

Changes first enter the merge queue, then are hidden behind feature flags for internal use, and then gradually rolled out. When issues arise, fix or roll back quickly. The team emphasizes that the last layer is key: failures should affect as few people as possible, and rollback costs should be as low as possible.

Merge Queue is a queue maintained by the CI system for pending merges before actual merging. It temporarily combines each PR with the changes ahead of it in the queue, reruns required checks on the post-merge target branch state, and ensures tests target the real merge result rather than an outdated baseline. This is especially critical in repositories with tens of thousands of daily changes: the main branch moves extremely fast, and validating each PR against an old state almost inevitably leads to semantic conflicts. The merge queue blocks conflicts and failures from the main branch, makes rollback granularity smaller and localization faster, and is a prerequisite for supporting high-risk automated merges.

Feature flags and gradual rollout are means of decoupling code deployment from feature enablement: changes enter the main branch in a disabled state, then are opened in order of internal users, small traffic percentages, and gradual expansion. Combined with one-click rollback, the blast radius of failures can be limited to the smallest group, and rollback requires no reverse-merging of code—just turning off the flag. This layer is often seen as the lowest-cost, highest-benefit part of layered defense, because all other layers can only reduce the probability of errors, while this layer determines how much it costs when errors occur.

Making the Review Loop Converge

Layered review has a side effect: each layer may add unnecessary content to the diff. The author mentions seeing changes that should have been fifty lines bloated to eight hundred or even two thousand lines because intermediate Agents incorporated feedback from every layer.

Round Limits and Scoring Mechanisms

The Claude Code team found that when doing git blame on code repeatedly flagged by reviewers, about 60% was code the reviewer had seen in the first round and that had stayed there—reviewers rarely found new bugs. They introduced a three-round limit; beyond that, the author must step back and reconsider the approach. After the change, PRs passing with one review round plus fixes increased by 13%, PRs requiring five or more rounds dropped from 9% to 1.5%, and the average number of rounds to pass dropped from 2.08 to 1.32.

The author tried another approach: having the review Agent give a score from 1 to 10, using a score threshold rather than comment count to decide whether to continue. A PR with only one comment but a score of 6 is more worth fixing than a PR with twenty trivial nits.

He also paid a price: a change that should have been simple ran for four days in council review, and the PR grew to 80,000 lines of code. Anthropic also encountered CLs with over fifty review rounds. His reflection: review must converge, must be able to end.

Review loop convergence is a new problem that emerged after Agents joined review: reviewers raise opinions, authors revise, reviewers review again, and each round may introduce new changes and trigger new opinions, creating positive feedback inflation. Common engineering measures include setting maximum rounds, setting score thresholds, requiring reviewers to flag only blocking issues, and forcing authors to rewrite the approach rather than continue patching when limits are exceeded. Metrics for measuring convergence effectiveness are typically average rounds to pass, one-round pass rate, and the proportion of PRs with excessively long rounds. When designing, "when to stop reviewing" should be treated as a first-class parameter of the process, not an ad-hoc fallback rule.

Where Humans Should Stand Guard

After machines take over most reading, the human position is redefined: deciding whether something is worth doing, grasping direction, taste, and scope; reviewing high-risk code like billing, auto-updates, and CI workflows; reviewing architectural decisions that set patterns and will be copied by others; reading evidence rather than reading code—test output, command returns, screenshots, review findings.

If you cannot articulate what automated checks would miss, you should request a real review rather than a quick pass.

The ownership principle is repeatedly emphasized: whoever submits the PR is responsible, and who generated the code does not affect this. Whoever prompts is the responsible party.

Cross-Team Shared Context

The Claude Code team's approach: don't pursue having someone master all the code, but enable quick explanations when understanding is needed. The team also relies on open Slack channels so members can see what each other is building, and feedback comes from people who don't own the code.

The author strongly agrees and hopes T3 Code can also solve team collaboration and visibility issues.

ReviewMD and Agent instruction files (like ClaudeMD) are carriers where teams distill recurring review comments into reusable rules, so Agents automatically apply them in subsequent reviews. But such files are essentially prompt instructions for models, easily stacking into lengthy behavioral constraints, and cannot fix defects in the code structure itself. A more robust approach is to layer the rules: what can be solved through type systems, interface constraints, and test coverage should be solved at the code layer first; what can only be intercepted at the process layer should be written as lint or CI checks; only lastly should it go into instruction files. This way rules have verifiable execution locations rather than relying on the model to faithfully follow them every time.

A Practical Checklist Worth Adopting

The video concludes with practices that can be directly migrated:

• Before PR: give the Agent runnable checks; run review and security check skills locally; distill recurring review comments into ReviewMD; fix code first, then lint, and only then touch Agent instruction files.
• During PR: CI must block; the PR template clearly states how to test, what the risks are, and how to undo; connect an AI reviewer; enable automated security review and require all threads resolved; match review intensity to risk; set review round limits.
• After merge: use merge queues, feature flags, internal-first, gradual rollout, one-click rollback; turn incidents and rollbacks into eval sets; re-score reviewers to verify whether changes are actually effective.

The author explicitly opposes one of the recommendations: Anthropic suggests putting fixes into ClaudeMD or skills when review misses issues. He believes the order should be reversed—if you can change the code structure, do that first; if not, add checks; only when checks can't stop it should you touch instruction files. "Don't keep giving the model instructions before it enters the room; make the room itself easier to navigate."

Conclusion

The core of this process is not letting AI replace human review, but shifting human attention from "line-by-line confirmation" to "judging direction, taking ownership, and handling truly new problems." The author also points out a reverse risk: if the solution is just to slow down, that doesn't really solve the problem—slowing down reduces error rates, often simply because less is being done. What's really needed is to discover and fix problems faster.