In a post dated 16th October 2026, Simon Willison collected a quotation from Addy Osmani, Morgan Westlee Lunt, and Qing Wang describing how the Claude Code team approaches code review. According to the quoted passage, the team treats the question 'did a human read the code?' as what it calls an imprecise proxy for a different question: 'what could go wrong with this change, and which check—automated or human—is the right one to catch it?' The authors describe a shift in timing. Previously, they say, review functioned as 'a gate at the end of the road: write the code, open a PR, wait for your colleague.' In their current approach, review 'runs continuously, more like spellcheck while you write.' The passage states that most changes 'have been reviewed and fixed by Claude at least once before a human is asked to look,' which they say catches routine mistakes and reserves human attention for higher-level questions. The excerpt is a quotation from a longer piece titled 'How the Claude Code team does code review,' as surfaced by Willison. The claims describe one team's internal practice and are not accompanied by independent metrics in the excerpt provided.
- Quotation collected by Simon Willison, posted 16th October 2026
- Attributed to Addy Osmani, Morgan Westlee Lunt, and Qing Wang on the Claude Code team
- Describes moving review from an end-of-process gate to a continuous check
- States most changes are reviewed and fixed by Claude before a human looks
What it means for you
This is one software team sharing how they reorganized their review process — they stopped asking 'did a human read this?' and started asking 'what could go wrong, and what's the right check to catch it?' The useful idea here isn't the AI tool; it's the reframe. It applies to almost any review or approval step in an organization, not just code: the point is to match each check to the actual risk it's meant to catch, rather than treating one blanket human sign-off as a stand-in for quality.
Try this
Pick one approval or review step in your operations — invoice sign-off, content approval, a QA checklist. Write down what could actually go wrong at that step, then ask whether your current review is the right check for that specific risk, or just a habit. You may find some checks are missing and others are theater.
Who should care
Engineering leads and anyone who owns a review, approval, or quality-gate process where things pile up waiting for a single person to look.
Skip this if
You don't run software development and your approval steps are already mapped to specific risks, or you're reading this expecting a product to buy — it's a practice note, not a tool.
Sources: Simon Willison — read the original