Robert C. Martin wrote the book that taught a generation to make code readable by other humans. In July he posted that he does not read the code his own agents write.
That is not hypocrisy. It is a concession, and a larger one than it first looks. Readable code was never the product. It was a cheap proxy for the thing anyone actually wanted, which is confidence. Martin has stopped buying the proxy and started buying the thing directly. So has most of the industry, whether or not it has noticed.
The question worth asking is not whether he is right. It is what that trade lets you see, and what it quietly stops showing you.
The concession
What he described is not laziness. It is a replacement:
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.
The word gauntlet is doing real work there. Martin did not abandon the discipline he has argued for since Clean Code shipped in 2008. He moved it. It used to live inside the code, in names and function sizes and structure a reader could follow. Now it lives in the machinery around the code, and the code itself is nobody’s reading material.
It is worth being fair about how strong this position is. Martin replaced reading with something expensive and deliberate. The common practice in the industry right now is to replace reading with nothing at all, and to call the result productivity.
What the gauntlet can’t see
Grady Booch had already objected. In April, answering an earlier version of the same claim, he drew the line precisely — metrics tell you the thing works, and nothing else:
Unlike Bob, I review all code generated by agents. Test coverage and similar metrics will give me confidence of functionality, but they offer me no confidence whatsoever that those agents have not introduced vulnerabilities…
That is an objection about a category, not an audit of Martin’s particular setup. And the category is the interesting part. A gauntlet is assembled out of failures somebody already knows about. Every gate in it is a mistake made once, by someone, who then decided to check for it forever. The gauntlet is a memory of past pain. It has nothing to say about pain nobody has had yet.
There is a number for this now. In August, Z.ai reported that its GLM-5.3 model found 2,436 vulnerabilities across 269 open-source projects, 1,097 of them medium-to-high severity, with an average latent lifetime of 26.6 years. The oldest traced back to 1981. Those are the vendor’s own figures for the vendor’s own model, and you should discount them the way you discount any vendor benchmark.
Discount them and the shape still holds. Those flaws sat in widely used software for decades, and whatever checks were run on it in that time did not stop them. Not because the checks were careless. Because nobody had thought to build the gate that would have caught them.
A gauntlet is not judgment. It is a list of the mistakes you already thought of.
The version that reaches your invoice
None of this is unfamiliar. You accept the same trade everywhere else in your business. You do not read your accountant’s working papers. You rely on an audit, and you are right to. The difference is that you know roughly what an audit covers, there is a profession that argues in public about where its boundary sits, and somebody signs their name to it.
Software has no equivalent settlement. When a supplier tells you their AI-assisted work is high quality, what they usually mean is that it cleared their gauntlet. They rarely say what the gauntlet checks. You rarely ask.
So the question you put to a supplier has changed. Show me the code was never a real request — you were never going to read it, and now neither are they. Show me the gauntlet is a real request, and it is one a non-technical owner can judge the answer to.
- Ask what it checks, on one page. If nobody can write the list down, there is no list.
- Ask what it has caught. A gauntlet that has never stopped anything is decoration, not control.
- Ask who adds a gate when something gets through. The honest measure of a gauntlet is what happens on the day it fails.
- Ask what it does not cover, in writing. Every gauntlet has a boundary. A supplier who cannot describe theirs has not gone looking for it.
None of those questions require you to read a line of code. All of them are harder to answer with a slide.
What you’re actually buying
The discipline that decides whether any of this pays off is still verifying what comes out. What changed is that the thing being verified is no longer something anyone reads.
Martin’s answer is defensible, and for his own work it is very likely correct. He has spent nearly two decades thinking about what is worth checking, which is exactly the qualification that makes a gauntlet worth trusting. The risk was never in his answer.
The risk is in the copy of his answer that travels without the constraints attached — the team that heard you don’t have to read the code, skipped the eight disciplines that came after it, and shipped. That team also has very high confidence. Confidence is the one output a weak gauntlet produces reliably.
The 1981 bug cleared every gate anyone thought to build. For forty-five years, that was indistinguishable from quality.