I read Robert Martin’s tweet and felt a betrayal so visceral it made me close the browser. This is the guy who wrote the bible of software craftsmanship. The guy who preached that code is for humans first, machines second. And now he’s telling us he doesn’t read his agents’ code? That he just surrounds them with tests and constraints?
Then I spent the next hour seething, pacing, and finally—finally—I realized he’s right. And that’s terrifying and liberating at the same time.
Martin’s tweet is a grenade thrown into the heart of every software team that still believes code review is sacred. He says: “I’m significantly older than you. I started coding in the late 60s. My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a plethora of others. In the end, I have very high confidence in the code they produce because they’ve had to run the gauntlet of all of my constraints and tests.”
Read that again. The man who wrote Clean Code—a philosophy built entirely on human readability and craftsmanship—now refuses to read his own agents’ output. Clean code is dead. Long live the gauntlet.
Let’s be honest: the industry has been in denial. We’ve been treating AI-generated code like a junior developer whose pull requests we need to review. But that’s a losing game. AI writes code faster than we can review it. The bottleneck isn’t writing—it’s verification. Martin’s insight is that you don’t need to understand the code if you can prove it satisfies the constraints. And that’s a radical shift in what it means to be a software developer.
One commenter on HN nailed the practical implication: “The expensive bugs are usually gaps in the spec itself.” Not typos in the code. Not missing semicolons. The real bugs live in the invisible space between what we say and what we mean. The shift to constraint-based development forces us to be brutally explicit about what we want. That’s a harder skill than writing elegant loops.
Another commenter pointed out the irony: “The author of clean code (who makes his living consulting on how to write software) has pivoted to AI in a spectacular tweet about how to set up automated software development just in time to make his living consulting about how to set up automated software development.” Yes, it’s self-serving. But it’s also a sign of the times. Martin is reading the market, and the market is telling him that the old religion of human-readable code in a human workflow is losing relevance.
So what’s the new religion? The most valuable skill in 2025 is not writing code—it’s defining constraints that code cannot escape. You become a warden, not a craftsman. You design the prison of tests, metrics, and specifications that the AI must survive. The code becomes a transparent artifact—something that passes through the gauntlet and is forgotten. It’s not beautiful. It’s not elegant. It’s just correct.
This is the moment where the definition of ‘clean code’ itself has to change. Clean code in the agentic era is no longer code that a human can read and understand in a single glance. It’s code that complies to the specs, the design constraints, and the exhaustive scenario test suite. It’s code that is verified, not reviewed.
If you’re a developer who finds comfort in the artistry of a well-placed abstraction, Martin’s tweet is a cold shower. But if you’re a developer who wants to survive the next five years, start investing in your ability to write ironclad specs, design mutation tests, and build gauntlets that make code prove its worth. The code doesn’t need to be beautiful. It needs to be bulletproof.
Martin is old, but he’s not senile. He’s the first to admit that the old rules don’t apply. The question is: will you listen, or will you keep reading code until the AI writes it faster than you can scroll?
FAQ
Q: What does Robert Martin's tweet mean for the future of code review?
A: Code review as we know it is dying. If the AI writes code faster than you can review it, you pivot to verifying it through automated constraints. The human's job becomes defining the rules of the game, not checking each move.
Q: Is this approach safe for critical systems?
A: It's only as safe as the constraints you define. The expensive bugs will always be gaps in the spec. Martin's approach forces you to think harder about the spec upfront, which is actually safer than relying on human review to catch logic errors.
Q: Should I stop reading my own code now?
A: Not yet. But start shifting your skills toward writing tests, specs, and constraints. If you're still manually reviewing each line of AI output, you're wasting your time. The leverage is in the gauntlet, not the code.