AI Code Review: Which Changes Still Need a Human?
Anthropic’s review process makes the approval decision depend on the change, its author, and the path back.
More agent-written pull requests make merge policy more important. I would tie human approval to the change’s risk, the author’s eligibility, and the path back if the patch fails. Anthropic’s October 15 account of code review on the Claude Code team gives a concrete example of that approach.
Anthropic says Claude writes about 90% of Claude Code’s own code. That figure measures code written. It does not measure how many pull requests merge without human approval. The team describes separate approval requirements for changes at different risk levels.
Separate the finding from the approval
An automated reviewer can identify a possible bug, point to the relevant lines, and ask the author to address it. A passing test can show that a particular check succeeded. Someone still has to decide whether that evidence is enough for this change to merge.
Anthropic’s public Code Review documentation says the product posts findings and a check run. It does not approve or block a pull request on its own. The October engineering account describes an additional policy used in Anthropic’s repositories: automated bug and security reviews produce findings that must be resolved, while the number of required human approvals varies with risk. A team adopting the product would need to set its own merge rules.
This distinction matters when a review comes back clean. The result tells me what the reviewer reported about the code it examined. I would also want the test output, the scope of the change, and an account of what those checks could miss. A green review cannot answer whether the team meant to change this behavior in the first place.
Classify the change before counting reviewers
Anthropic’s published risk table gives low-risk changes, such as documentation and copy, a path with no required human approval after automated review and security checks pass. Ordinary product changes and certain sensitive areas require one person. Its highest-risk code and a small set of designated paths require two. A second classifier can still require another person when the assigned risk tier would otherwise allow a lighter path. For an agent-written PR, the person directing the agent can count as one of the required human reviewers. The agent itself cannot count toward a human-review slot.
The lighter paths have another condition: they apply only to authors on the repository’s trusted list. Anthropic says other authors need a second person’s approval. It also says owner-designated sensitive paths and CI workflow files always need a person, even if a classifier assigns a lighter tier. Those conditions are part of the policy; the three-row table alone would give a team an incomplete rule.
If I were setting this policy for a repository, I would begin by listing changes whose failure could expose data, interrupt releases, alter authentication, or make recovery difficult. The list should reflect that repository’s actual paths and deployment process. I would then decide who can approve each category and what checks must pass. The author’s familiarity with an agent does not tell me what the resulting patch can do.
A harmless-looking patch can touch a sensitive path
A help-page correction and a CI workflow permission change can each fit in one line. The help text needs to be accurate and appear in the right place. The workflow change may let a job write where it previously could only read.
Get Felix Anderson’s stories in your inbox
Join Medium for free to get updates from this writer.
I would send the CI change to a person responsible for that workflow and make the new permission and its reason visible in the review. Anthropic’s policy also requires a person for CI workflow files. The two changes take roughly the same space in a diff, but their failure costs are different.
Tie approval to the reviewed commit
An approval can go stale when another commit lands. An agent might push a fix for an automated finding after a person has approved the pull request. That person reviewed the earlier version; the fix may alter the behavior they signed off on.
Anthropic says an approval in its process covers a specific commit and must be given again when a later change cannot be vouched for. I would record which commit received the required human approval, rerun relevant checks after a change, and ask for fresh approval when the reviewed behavior may have changed.
Make failure ownership part of the decision
A lighter approval path transfers more work to the checks before merge and to the people who watch the change after release. Before I would allow one, I’d want three names or roles on the pull request: who notices a bad outcome, who can stop further rollout, and who restores the affected service. “Revert the PR” is only a useful instruction when a revert actually restores the previous behavior.
Anthropic describes merge checks, staged releases, flags, on-call response, and reverts as parts of its process. Its account also says the person who directed an agent-written change remains accountable for the outcome. Those practices explain why its approval table should be read alongside its release and recovery process.
A feature flag might quickly disable a new interface. It cannot necessarily undo a destructive data migration that has already rewritten records. For a migration, I would ask for a tested recovery route and a person who can execute it before reducing the approval requirement. I would keep human approval when the effect on existing data or the path back is unclear.
The same reasoning applies to a change that is easy to deploy but hard to detect when it fails. If no one can describe the signal that would reveal a regression, a promised fast rollback offers little comfort.
Start with a policy you can evaluate
I would pilot any lighter rule in one repository and one bounded class of changes, with the existing approval rule as the starting point. For each pull request, record its proposed tier, changed paths, author eligibility, checks, reviewer findings, approval, and reviewed commit. Then record how long it waited for a person and how many review rounds it took.
The outcome measures matter as much as the time saved. Track reverts and incidents, and examine any missed risk: was the change classified too lightly, did a check lack the right context, or did the team fail to notice the problem after release? An agent and reviewer repeatedly editing the same patch should also count as a cost, even if the pull request eventually passes.
Anthropic reports its own improvement in pull request volume and revert share, but those figures describe its repositories and process. They do not predict a pilot’s result elsewhere. I would loosen the rule only after the team has observed enough of its own changes to judge both review time and failures. If the sample is small or recovery has not been exercised, keep collecting evidence.
I would retain human approval wherever the consequences or reversibility remain unclear. A well-defined, lower-risk category can earn a lighter path when its checks, owners, and observed outcomes support that decision. That is a policy a team can revise as it learns; the presence of an AI reviewer alone is no reason to change who may approve a merge.
