Don't Read the Code? Verifying AI-Written Code

Robert C. Martin, “Uncle Bob”, wrote Clean Code, a book built on the idea that code is written for humans to read. So it stopped me in my tracks to see him arguing, in recent posts and talks, that humans should stop reading AI-written code line by line. Hearing one of the field’s elder statesmen take that view, alongside similar noises from Martin Fowler and perhaps Kent Beck, says a lot about how fast the ground is moving.

The argument

Coding agents write code far faster than anyone can review it. Reviewing every line throws away the speed that made the agent worth using. So the engineer’s job shifts: define what “correct” means, let the agent implement, and let machines check the result.

As I understand it, his playbook has three rules:

1. Surround the agent with an automated gauntlet. Unit and integration tests, Gherkin-style specifications, code quality and complexity metrics (cyclomatic complexity, module size, dependency structure), test coverage, change-risk scores, and mutation testing, which injects deliberate bugs to prove the tests actually catch them.
2. Use deterministic tools, not AI guesses. Never ask a model to estimate coverage or compute a metric. Use tools that give exact answers, and if a procedure must be followed, encode it in software rather than hoping a prompt holds.
3. Keep humans responsible for specifications and final sign-off.

The pushback

Critics worry about architecture quietly decaying, “vibe-coded” technical debt, edge cases nobody validated, and test suites so heavily mocked that they prove nothing. Those are fair: a gauntlet is only as good as what it checks.

Where I land (for now)

• Rule 2 is already how I work. This site is fed by a pipeline where a model rewrites my notes for publishing, but a plain, deterministic script decides what’s allowed out. The same night I read this, that script caught a formatting bug the model had missed.
• Metrics as the review invite gaming. Once the numbers are the gate, agents will optimise for them (Goodhart’s Law). Mutation testing is the honest counterweight: it tests the tests.
• Specs become the craft. If humans stop reading implementations, the skill moves to writing precise specifications and good tests, which is very close to TDD as a Feedback Loop.
• It connects to a question I keep asking about low-code platforms: if people stop reading code, maybe the platform becomes the place where we describe and pilot software.

I’m not ready to stop reading code. But I’m reading less of it, and checking more of it automatically. See also mutation testing and feedback sensors for coding agents on my radar.

Sources: Uncle Bob on X · Uncle Bob on X (2)