With Claude writing about 90% of its code, the Claude Code team stopped asking whether a human read the code and started asking what could go wrong. From June to September, merged pull requests more than doubled, while the share that had to be reverted fell by more than 40 percent. The team laid out how in “How the Claude Code team does code review,” published on the claude.dev blog on October 15. Under the Anthropic post I covered last time in “At 30,000 merges a day, Anthropic left git behind,” the Hacker News thread with the most replies asked exactly this question: how do you review at that speed? I read the team’s answer alongside an Ask HN from a few days later about shipping AI-written code you don’t understand, and picked out the rules a small team could actually use.
No longer asking “did a human read it?”
The post says code review does two jobs: finding and fixing issues before they ship, and building shared understanding of the codebase across the team. At this volume, it admits, manual line-by-line review is incredibly difficult if not impossible, so the team started by changing the question behind the first job.
We think “did a human read the code?” is an imprecise proxy for “what could go wrong with this change, and which check—automated or human—is the right one to catch it?”
The Claude Code team, “How the Claude Code team does code review”
The scarce resource, then, is human time and attention. That covers both the time people spend reviewing and the time they spend fixing what bad code breaks; cutting the first doesn’t help if it just reappears in the second. The goal is for most pull requests to merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. So the team tracks human approvals per PR, human comments and how long a PR waits on a person, with revert and incident rates as the guardrail.
Layers of checks instead of one gate
Most review now happens before a PR exists. The team gives Claude something it can run, like tests, a build or a screenshot to compare against the design, and asks it to show the output instead of saying it’s done. Then a subagent with fresh context reviews the diff. Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results, and estimates it makes the final result two to three times better.
Every pull request gets a Claude review before a person looks. Several agents hunt for bugs at the same time, a separate group votes on each finding, and only findings enough of them agree on get posted. Findings that are only about style or cleanup are dropped; the rest are tagged Important, Nit or Pre-existing, so a bug the PR didn’t introduce doesn’t look like the author’s fault. Every finding has to be answered, either fixed or resolved with a reason. When the team launched this review as a research preview, the share of internal PRs getting substantive review comments went from 16% to 54%.
Security gets its own automated review, and a PR can’t merge while any finding from the bug review or the security review is still open. Behind that stand lint, type checks, tests on every platform and a build. The PR template asks how the change was tested and how to undo it. Claude can fill that in, but the person who asked for the change signs off on it.
Human approval, scaled by risk
A docs fix and an auto-updater change carry different risk, so they get different review, and the change sets the tier, not the author. A classifier reads the change and picks its tier; a second one asks whether this particular change needs another person even when its tier says it doesn’t. Docs, copy, internal-only features and additive changes behind a flag are low risk and need no human approval once automated review and security checks are green. Ordinary product changes, and sensitive areas such as caching, the auto-updater or system prompts, need one person; the highest-risk code needs two. Only authors on the repo’s trusted list get those lighter paths.
A few more rules sit on top. An agent’s approval never counts as a person’s. On an agent-written PR, the person directing the agent counts as one of the required reviewers, the same as if they’d typed the code themselves. An approval covers one specific commit, so if a commit arrives that the system can’t vouch for, like an agent’s push, the approval has to be given again. Anything owners have listed as sensitive, and any CI workflow file, always needs a person.
When a PR arrives, a classifier reads the change and picks a risk tier.
A second classifier asks whether this particular change needs another person even when its tier says it doesn’t.
Low-risk changes merge without a human approval once automated review and security checks pass.
Medium needs one person; the highest-risk code needs two.
Rules sit on top. An agent’s approval never counts as a person’s, and whoever prompted the agent counts as one reviewer.
An approval covers one commit, and the lighter paths are open only to authors on the trusted list.
The merge queue re-runs every check against main with the change applied, so two PRs that pass separately can’t combine into a broken main. New behavior usually ships behind a flag to Anthropic employees first, and public releases reach the latest channel before stable. Flags turn off without a deploy. One colleague said slowing down does lower your error rate, but mostly because you’re doing less of everything; the team would rather get faster at noticing and fixing problems. The post is also candid about what’s missing: there are no circuit breakers yet that tighten approval when revert and incident numbers move, and engineers want them before more code moves to zero-human merges.
The reviewer gets reviewed too
The AI reviewer takes an exam every day. The team collected past PRs that caused incidents and had engineers who know that code confirm each bug and where it lived, turning them into an eval set. Every change to the reviewer is scored against all of it. Noise is measured too: every comment the reviewer leaves is sorted by how the person on the PR responded, whether they fixed it, said it was wrong, said the behavior was intentional or decided it didn’t matter. Noise costs more when the author is an agent. A person can wave off a nit in seconds; an agent fixes it, which means another commit and another round of review.
An agent author and an agent reviewer can keep each other busy indefinitely. One CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it. When the team ran git blame on what the reviewer kept flagging, about 59% of it was code that had been there since the reviewer’s first pass: it wasn’t finding new bugs so much as a few more old ones each round. So reviews now have a cap. After three rounds, the reviewer asks the author to step back and reconsider the approach. After the first few passes it re-reviews only the new diff, flags the whole class of a bug rather than one line, and doesn’t repeat findings already posted.
So who knows the code?
What about review’s second job, spreading understanding of the code? The post says plainly that there is no formal process. Someone who wants to understand a part of the codebase asks Claude to write an explainer for exactly that slice; it takes minutes and reflects the code as it is today. A one-line copy change teaches you almost nothing, the argument goes, while an explainer for the module you’re about to change teaches you a lot. In return the team keeps a norm: you land it, you own it. If a small or medium change goes wrong, whoever landed it usually fixes it. That isn’t blame; they simply have the most context.
Nobody on the team keeps a complete mental model of Claude Code in their head, and we don’t think anyone needs to.
The Claude Code team, “How the Claude Code team does code review”
Three days later, 615 comments of unease
Three days after that post reached Hacker News, “Ask HN: How to deal with shipping AI-written code you don’t understand?” went up (484 points). The author quoted a LinkedIn post by an engineer at Meta: writing code these days feels like a black box, and you understand the high level but not every detail. The answers that stood out fell into three camps.
People decide the design. The comment with the most replies (41) said they don’t let the LLM design the code at all. Decide the abstractions and responsibilities first, have the model fill in the gaps, and you may not know how each unit is implemented, but you know what each one does and how they interact.
Hand-write only what’s risky. One commenter lets the model write the UI wholesale but still writes the SQL schema by hand, because getting that wrong is far more catastrophic. Another said the time they used to spend coding now goes into testing.
Read it anyway. On the other side, one commenter said you must read the code before shipping it to production, and at least one person in your company should be able to explain it.
My point is that this is less a matter of quality and more a matter of responsibility.
The same commenter on Ask HN
The 479 comments on the Claude Code team’s post weren’t all kind either. One recalled smaller teams learning bitter lessons by copying Google-scale processes because “this is how Google does it,” and said Anthropic can afford this because it has virtually unlimited tokens. Another said their SOC 2 reviewer had stated that all code needs to be reviewed by at least one other human before it goes to production, and asked how this approach got approved. The post doesn’t address cost or audit rules. “AI saves the time of coding, but 100% of the responsibility remains on you,” wrote another.
A tool, or automation?
The same two weeks brought a more fundamental objection. Rich Hickey, who created Clojure, argued in “‘AI’ Is Not a Tool” (318 points on HN) that LLMs are not wielded; they are automation. A drive-thru, in his comparison, is not a tool for cooking but automation for avoiding it, and if you don’t do the writing and reading yourself, you miss learning how to think. Huahai replied almost at once with “AI Is a Tool. Using It Well Takes Skill.” (805 points): picking up a saw does not guarantee a straight cut, and using an LLM well takes skill too. purplesyringa, who has spent about eight years on low-level code, wrote in “Grieving the loss of details” (506 points) that LLM-driven development optimized out every part that made programming bearable for them. On the 18th came Sphinx (252 points), a hook that quizzes you on whether you understand the code you’re about to ship.
Tools are implements with which you do something, they do not do things for you.
Rich Hickey, “‘AI’ Is Not a Tool”
What a small team can take from it
The post ends with a list for other teams. I kept only the items a small team without an unlimited token budget can do right away.
Write down your risk tiers. Set them from what the change touches rather than who wrote it, and, as the post advises, start strict and loosen with evidence. Use CODEOWNERS and branch protection so auth, billing, CI and release workflows, and installers always need a person.
Add three fields to your PR template. Testing, Risk and How to revert.
Keep a REVIEW.md. Say what failure looks like in that repo; the post’s examples are “it lies” for docs and “it misroutes” for config. Cap the nits and ask for a file and line as evidence. When the same review comment keeps coming back, move it into this file.
Cap review rounds. After the first few, re-review only the new diff.
Never let a bot’s approval stand in for a person’s. Dismiss approvals when new commits land.
Measure human time, with the revert rate as the guardrail. Turn incidents and reverts into an eval set for the reviewer.
In the Scion post, Anthropic said the engineers’ role was very often to tell Claude “no.” What this post leaves to people looks similar: deciding whether to build something, reviewing risky code like billing and the auto-updater, reading the evidence and owning the outcome. If the 615 comments on Ask HN were asking who knows this code, the Claude Code team answered with who owns this change. Nobody knows yet whether those are the same question. But the first step for a small team seems clear: write down where a person really has to look.
Sources (numbers as of October 20, 2026)
The Claude Code team, How the Claude Code team does code review · 483 points, 479 comments on HN
Ask HN: How to deal with shipping AI-written code you don’t understand? · 484 points, 615 comments
Huahai, AI Is a Tool. Using It Well Takes Skill. · 805 points on HN
purplesyringa, Grieving the loss of details · 506 points on HN
Show HN: Sphinx – A hook that quizzes you on your AI’s code before shipping · 252 points on HN