Claude Code’s continuous review: which errors move to machines, and which decisions stay with people?

Question and brief (October 17, 2026). When review runs before and during a PR, what evidence reaches the human, and what survives merge? Good evidence would pair finding→disposition→risk-tier decision→release gate→field repair with reviewer and author minutes. Scion establishes a different Anthropic source-control setting; SQLFluff shows an agreed warning followed up after merge. Sub-questions: automated detection and convergence; human authorization and release boundary; measured quality/time and contradictory evidence. Three initial primary-source searches and focused searches for the original announcement and other teams’ mechanisms led to the original below and existing primary comparisons. No further generic query answers the unreported human minutes or independent customer acceptance.

Original operator account. Addy Osmani, Morgan Westlee Lunt and Qing Wang, “How the Claude Code team does code review,” October 15, 2026 (14-minute authored engineering account). Willison’s October 16 quotation is an excerpt, not another team outcome. The October 15 product announcement confirms external availability for Team and Enterprise but must not be counted as evidence the internal workflow works at a customer site. The independent 718-firm observation, Meta’s randomized UI attention trial, and the primary GitHub documentation and SQLFluff trace supply comparisons of different endpoints, not replications.

What actually runs. Before PR, agents run checks and a fresh-context diff review. On every PR, an agent reads the intent and repository, parallel agents look for bugs and independent verifiers vote on findings; style-only reports are filtered, survivors ranked and posted inline. An independent automated security pass and required build/type/lint/platform tests block merge while red. An open bug or security-review finding must be fixed or the author closes the thread with a reason; later corrective commits may clear it. The PR template asks how it was tested and how to undo it; the person who requested the change signs off. A classifier assigns low/medium/high risk from the change, plus a second question about need for another person. Low-risk trusted-author changes may merge without a second human; one or two people approve higher-risk changes, and certain paths/CI workflows always need a person. The human who directed an agent counts as a required reviewer; an agent approval never counts. A new commit not covered by an approval requires reapproval. A merge queue tests the combined mainline; flags, internal use, latest release then stable, human on-call and reversions supply post-merge control. The article calls this continuous review, not no human accountability.

The limits of disposition and of the oracle. Closing an inline thread with a short reason is recorded disposition, not independently proving that the concern was false, fixed or safe to ship. Low-risk automation puts much of the decision on the author’s risk judgment and the classifier; unlike a customer acceptance check, internal users and on-call do not tell us every requester’s requirement is met. Anthropic has no automatic circuit breaker tightening the risk tier if reverts/incident rates rise. Human engineers still decide whether to build at all, architecture, high-risk changes and what the check output actually says; early discussion sometimes closes or reshapes cheap-to-start PRs. The authors explicitly lack a formal way to replace the context-sharing benefit of peer diff reading: engineers request module-specific explanations from Claude and work in public channels. This is an untested substitute for direct review as a way of learning code.

Measured but not the full denominator. In the Claude Code repository (separate from Anthropic’s monorepo) merged PRs more than doubled June→September and the share reverted fell more than 40%; the account gives neither the absolute reverted PR count nor incident rate nor parallel counterfactual, and does not demonstrate that review caused either change. Their tracked internal human-work proxies are approvals per PR (median and 95th percentile), comments and time waiting for a person, not published active reviewer/author minutes. An internal preview raised PRs with substantive review comments 16%→54%, which is findings coverage, not proven true-positive rate. One PR cycled through more than 50 agent review/fix rounds. After a three-round step-back trigger, diff-only re-review and de-duplication, their before/after figures say first-round pass 65%→78%, five-or-more rounds 8.9%→1.5%, mean review rounds 2.08→1.32; cohorts, task mix and control are not given. Their own analysis of that looping case found ~59% of later flagged code had been present on its first pass. Every confirmed incident/revert becomes an expert-checked daily reviewer eval, but eval coverage and how often benign code is damaged by over-correction are not published. The GA product announcement’s ~20-minute→6–10-minute review turnaround is not human active time or field-defect rate.

Where evidence disagrees without a contradiction. Chen–Stratton observes longer submission→merge calendar time after agent adoption across ordinary firms with no detectable Jira-closure rise, versus a first-party team with its own queue, staged channels and model budget; neither measures the other’s population or endpoint. Meta’s trial shows reviewer-visible AI patches can increase review-page attention, which is a warning about where output is surfaced, not a refutation of Anthropic’s process. Scion is a monorepo with post-merge/pre-deploy integration checks and no global locked merge queue; Claude Code is a separate repo with a merge queue. Do not combine 30,000 monorepo changes/day with Claude Code PRs or pretend both use the same merge design.

Next useful test. Prospectively log same-request review findings (including dismissed and missed), owner disposition, author and reviewer active minutes, risk-tier decisions, checks on real behavior and staged field incidents over 30 days, including effects of fixes the agent made in response to false positives. Hold out seeded and real customer failures so the eval cannot learn only the team’s past incidents. Until such a cohort exists, this is a strong process account and hypothesis about attention allocation, not a demonstrated reduction in total human work or customer defects.