# Claude Code had to teach its AI reviewers when to stop **Summary:** One Claude Code PR went through more than fifty review rounds overnight. I would cap and narrow AI review before using it to justify fewer human approvals, while tracking the defects and repair work that escape. - Canonical: https://markhuang.ai/news/claude-code-review-rounds-stop - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-16 - Section: News - Tags: Claude Code, Code Review, Coding Agents, Developer Productivity, Software Reliability - Source: [Claude Developer Blog](https://claude.dev/blog/solving-code-review-at-anthropic/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![Translucent circuit tiles circle beneath two inspection lenses on a metal track with an open exit and an amber stop control](https://cdn.markhuang.ai/news/claude-code-review-rounds-stop/hero.webp) *Conceptual artwork: an automated review loop needs a way to stop and reconsider.* One Claude Code pull request went through more than fifty rounds of review and fixes overnight before its author stopped it. That detail, in [Anthropic's October 15 account of its code review process](https://claude.dev/blog/solving-code-review-at-anthropic/), interests me more than the claim that agents can handle most of the reading. The agents kept finding work for each other until a person interrupted them. I would put that stopping rule in place before using AI review to justify fewer human approvals. Automated review can save attention, but an agent author can also turn every comment into another edit and another review. I want the loop to converge on a change somebody can own. Anthropic reports that, after changes to make review converge, mean reviews to pass fell from 2.08 to 1.32. The share needing five or more rounds fell from 8.9% to 1.5%. I find those internal results useful because they measure how much review it took to finish a PR. Finding more bugs is only part of that job. ## The reviewer kept discovering the old code The team investigated what its reviewer kept flagging. About 59% was code that had already been there at the first pass. Each round was uncovering more existing problems rather than mostly finding bugs introduced by the latest fix. That does not make those findings false positives. An existing bug can be serious. But it changes the job: a review of one proposed change can expand into an audit of everything nearby. If the author automatically fixes each finding, the patch can keep growing while its original purpose gets harder to see. Anthropic changed the review rules. After three rounds, the reviewer asks the author to step back and reconsider the approach. After the first few passes, re-review focuses on the new diff. The reviewer flags a class of bug so the author can fix all its instances, and it avoids repeating findings already posted. Nightly reviews still examine existing code. I like that separation. I would keep an unrelated finding visible and give it an owner, then decide whether it must block this change. A review bot should not quietly enlarge the task just because it found something else worth fixing. ## Who gets to merge still matters The strongest case for this workflow is that Anthropic kept several checks around the model. The team describes required CI, a separate security pass, and a merge queue that checks the change against the latest main. Open review findings must be fixed or resolved with a reason. Human approval depends on risk. Trusted authors can take lighter paths for low-risk changes; sensitive paths still require people. An agent's approval cannot fill a required human slot, and approval covers a particular commit. I would keep those constraints when deciding which changes can skip another human reader. The public product has a narrower role. The [Code Review documentation](https://code.claude.com/docs/en/code-review) says it posts findings and never approves or blocks a pull request. It reads the diff and surrounding code without building or running it. Buying the reviewer does not give a team Anthropic's whole verification and release process. > **Info:** > > I would use a round cap to trigger a decision: narrow the change, investigate the disagreement, or ask a person to review it. Reaching the cap should never clear an unresolved defect. That distinction matters when the agents disagree repeatedly. Another pass might find something useful, but it might also be a reason to inspect the requirement or the proposed design. I would want the author to explain what remains uncertain before asking the machines to keep going. ## Fewer reverts leave questions open Anthropic says merged PRs in Claude Code's codebase more than doubled between June and September, while the share reverted fell by more than 40%. I take that as encouraging evidence for the combined process. The account does not give the absolute revert rates or isolate which changes caused the improvement. In the [Hacker News discussion](https://news.ycombinator.com/item?id=50122951), commenters question whether change volume translates into user value. One also points out that improved revert rates could coexist with security problems. Those comments do not establish that Anthropic's process is unsafe. I share the concern about what those numbers leave out. [Alex Ewerlöf's critique of the "coding is solved" claim](https://blog.alexewerlof.com/p/coding-is-not-solved) presses on the operational cost: who fixes what cheap generation leaves behind? Anthropic addresses that by keeping a human accountable for every shipped change. Its stated goal counts time spent repairing failures alongside time spent reviewing. I want to count both costs too. One control the team wants is still missing. It says it does not yet have circuit breakers that automatically tighten approval when revert or incident numbers worsen. Detection still depends on the author, on-call engineers, and dashboards. I would resolve who can tighten the rules, and when, before expanding merges without human approval. ## What I would copy first In [my earlier argument about the cost of proving a patch](https://markhuang.ai/news/coding-agents-patch-proof-cost), I put verification ahead of cheap output. Anthropic's account gives me another thing to check: whether review stays within the task or keeps expanding it. I would start by measuring rounds to pass and the human effort behind accepted or rejected findings, then check what escaped into production. I would cap repeated review, narrow later passes to the changes they need to examine, and assign old bugs separately when they do not block the current work. If that saves time without increasing repair work, I would consider reducing human approvals for the changes that qualify. But when a PR needs another round, I want to know what that round is meant to resolve and who takes over if it cannot.