Boris Cherny, who leads Claude Code at Anthropic, posted a line today that I have been chewing on since:
Production code written by Claude should have a higher bar than if it was written by a human.
Attached to it is a list of what Anthropic runs to hold that bar: lots of lint rules, lots of tests, Claude-driven end-to-end tests, Claude-powered fuzzers running daily, automated code reviews, automated security reviews, automated refactoring. Without them, Cherny says, you end up with a mess that is hard to maintain later.
Why higher, not equal
The obvious objection: code is code. If it works, it is tested and someone read it, who wrote it should not matter.
That objection holds for one piece of code. It does not hold for volume. Produce five times as much in a day and review cannot keep up - and review was already the bottleneck, not typing. A sampling habit that worked at twenty pull requests a week covers almost nothing at a hundred.
Then there is the shape of the mistakes. You know the human ones: someone misses an edge case they have never seen, and they do not produce three hundred tidy-looking lines that quietly do the wrong thing in one spot. Models occasionally do exactly that, in a form that reads as correct when skimmed. A tired reviewer at 5pm does not catch that. A test does.
The list is the real news
Look at what is on it. Lint rules and tests, nearly every team has those. But daily fuzzers, automated security reviews and automated refactoring? Very few do - and Anthropic runs them because a large share of its own code comes from Claude.
The uncomfortable part: if you speed up production, you have to speed up control with it. And that only works mechanically. Human review does not scale along, however disciplined the team.
It also rhymes with what Simon Willison and Alex Garcia did to Datasette this week: an audit across three models, with every finding confirmed by a test before anyone fixed it. Same movement from two directions. Models write more code, so models have to check more of it.
What I am taking from it
Reading it, I felt caught out. My safeguard with Claude Code is that I read the diff. On small projects that is enough. On anything that lives longer, it is exactly the sampling habit that does not keep up with volume.
Three things that cost almost nothing:
- Make tests a condition, not a bonus. No feature without a test, even when Claude writes both.
- Have a second model look over it - different blind spots, and it takes minutes.
- Turn lint and type rules up. Whatever the machine rejects automatically, you do not have to read.
The line works as a rule of thumb even for one-person projects: if you relax your review because the model sounds confident, you have lowered the bar rather than raised it.
Sources: Boris Cherny on X, Simon Willison