The most useful line about AI code review this week is not about tooling. It is about the question we use to decide a change is safe. Addy Osmani, Morgan Westlee Lunt and Qing Wang, writing about how the Claude Code team does code review, argue that “did a human read the code?” is a poor proxy for the thing we actually care about - and Simon Willison collected it on 16 October 2026. Source: https://simonwillison.net/2026/Oct/16/code-review/
Key facts
| Fact | Detail |
|---|---|
| Question answered | Code Review Moves Left: The Claude Code Team’s Test for Agent-Written Code |
| Short answer | In a quotation collected by Simon Willison, Addy Osmani, Morgan Westlee Lunt and Qing Wang argue that ‘did a human read the code?’ is an imprecise proxy for the real question: what could go wrong with this cha… |
| Reading time | ~5 min |
| Last updated | 2026-10-17 |
The quote, in full
“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?’ Asking that question also changed when review happens. Before, review was a gate at the end of the road: write the code, open a PR, wait for your colleague. Now, review runs continuously, more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny.”
Two things are being claimed, and they are separable. First, the metric is wrong: a signature on a diff does not tell you whether the diff is safe. Second, the timing changes as a consequence - if the check you need is a specific automated one, you can run it continuously instead of convening a meeting at the end.
Why “a human read it” stopped being a useful proxy
The proxy worked when reading was the expensive part. If a person had to load the diff into their head, reading it was the review, and their comprehension was a decent stand-in for coverage.
Agents break that assumption in a specific way: they produce diffs faster than anyone can read them, and the diffs are usually boring. A human skim of forty agent-generated changes mostly measures stamina. Worse, the skim is not targeted - it spends the same attention on a renamed variable and on a changed retry policy.
The replacement question is narrower and answerable: for this change, what are the plausible failure modes, and which check catches each one? That framing immediately sorts changes into three buckets - things a test can pin down, things a review should look at, and things that need neither because they are mechanically verifiable.
Review as spellcheck, not as a gate
The second claim is the operational one, and it is the part teams underestimate. Moving review earlier is not just “review sooner”; it changes what review is for:
- A gate exists to stop a release. Its natural output is a yes/no at the end, and its cost is latency.
- Spellcheck exists to remove noise while you type. Its natural output is a smaller, cleaner diff, and its cost is near zero per keystroke.
If most changes have already been through one Claude review pass, the human’s job shifts from “find the typos” to “is this the right change, in the right place, with the right blast radius.” That is a better use of senior attention, and it is also the part agents are worst at, because it depends on context that is not in the diff.
The failure mode this creates
Continuous review has its own pathology, and the authors’ framing hints at it: if Claude has “reviewed” everything, a human approval can become ceremonial. The signature returns, now with a machine’s name in front of it.
Three habits keep that from happening:
- Name the checks, not the readers. For each PR, write the one or two failure modes worth worrying about. If nothing maps to them, you have not thought about the change yet.
- Keep an adversarial pass for risky diffs. Auth, migrations, money, deletion, anything that touches a build or release path - there the human should read with the same suspicion as before, and should be able to say what they verified.
- Record what was actually verified. “Reviewed” is not evidence. “Ran the migration against a copy, checked rollback, confirmed the retry cap” is.
What this looks like on a Windows desktop agent
Most people running agents locally do not have a review team; they have themselves. The reframing still helps, because it converts a vague guilt (“I should read all of this”) into a checklist:
- Split the diff by risk. Files an agent touched that only add content are low risk; anything touching startup, installers, credentials or scheduled tasks is not.
- Automate the boring checks first. Build, type-check, a smoke run. If those are red, reading is wasted effort.
- Do the risky read yourself, out loud. Explain the change in two sentences; if you cannot, you have not reviewed it.
- Keep the evidence next to the change. A short note of what ran and what you checked is worth more than a thumbs-up.
MOOGH is built for that loop - it runs on your machine, shows each action, and keeps you in the approval path for the steps that matter: [download MOOGH].
The uncomfortable part
If the question is “which check is right for this change,” then the honest answer for many changes is that we do not have that check yet. The quote is not a claim that review is solved; it is a claim that counting human eyeballs was never measuring safety. Teams that take it seriously end up writing more tests and more explicit risk notes - which is more work up front and less rework later.
FAQ
Is this an argument for removing human review? No. It is an argument for pointing human review at the questions automation cannot answer, and for running the automatable checks continuously instead of at the end.
Does it apply to solo developers? Yes, and it is easier there. The “team attention” being saved is your own, and the discipline - name the failure modes, run the checks, read the risky parts properly - is the same.
Where can I read the original? Simon Willison’s quotation links to the Claude Code team’s post on code review; the quote itself is from Addy Osmani, Morgan Westlee Lunt and Qing Wang.
Related reading: