I No Longer Read My Agents' Code
(Published on October 16, 2026 - Version française)
Put like that, it sounds reckless, and yet Robert C. Martin wrote on X that he no longer reads a single line of the code his agents produce. This is the same Martin who wrote Clean Code, the book that convinced a whole generation of developers that clean code reads like well-written prose.
I only came across his post recently, while this text had been sitting in my drafts for a long time, because I first wanted to put my practices to the test on a real project. Martin surrounds his agents with very strict constraints and I do roughly the same, but these few months have mostly shown me what my confidence rests on. It rests on the specification, that document nobody reread after the first implementation, and on the tests derived from it. They serve twice, today for the agent that implements and tomorrow for the one that will evolve the project.
Tests tell the agent what to produce
The agent is like the subcontractor of old, competent but unfamiliar with the business, who fills every gap in the specification by guessing. That is who we used to hand detailed specifications to, and acceptance tests now play that role, by example. The specification says what the application must do, and the tests show what it must answer in a specific situation, so the agent no longer has to guess.
From each specification, the agent derives these tests in natural language, written before the code, and I push it to make them as deep as possible, with as many cases as it can find and above all the edge cases. During implementation, it replays them and knows right away whether what it just wrote works, which makes it far more autonomous.
The agent then compiles these tests into a script that queries the application without going back through the LLM, so the verdict can no longer be hallucinated, even if it is only as good as the test. Unit tests, static analysis and coding rules complete the setup and keep the code readable by a human, for the day someone has to read it after all.
The specification is an investment in the project's future
When the time comes to return to the application for a change, everything depends on what was written down.
Without a specification, the agent first has to understand how the application works. It reverse-engineers it and greps its way to the code it will have to modify, at the risk of changing one place without seeing that another, further away, depended on it. With an up-to-date specification, it knows where it is stepping: it has the information it needs to carry on without reconstructing intentions from the code.
A developer does no differently when taking over a colleague's work, or their own code after months away. So the specification does more than frame the implementation, it is the project's memory, and it is what will let the project evolve over the long term.
As the project grows, contradiction threatens this memory far more than volume. The agent only loads what it needs, but when two files contradict each other, it no longer knows which one to believe. That is why every change to a specification comes with a search for contradictions. This rule may seem trivial, but it is in fact decisive for how the project ages.
This memory is what separates a developer who masters agentic development from the vibe coder, meaning someone who just prompts and watches the result run. When they come back to their project to evolve it, they prompt again, the agent redoes its reverse engineering, and as soon as the project gets complex, it breaks things. I think the companies that code fast this way will come to regret it, the day their bug rate explodes.
For the first time, the specification stays up to date
A wrong specification or tests that cover the cases poorly existed long before AI and will go on existing, because the problem has always been elsewhere.
In many companies, the statement of needs, the specifications and the acceptance tests were written by people other than those who implemented them. Along the way, we found anomalies and clarified points, but the developer almost never fed those decisions back into the specification, because developers don't like writing. Over time, the specification ended up describing software that no longer existed, to the point that "don't bother looking in the spec, it's out of date" had become a running joke. Why do you think one of the four values of the Agile Manifesto is "working software over comprehensive documentation"? With an agent, which starts cold at every session, this documentation becomes the project's memory.
With AI, the specification, the tests and the code are updated in moments, but in order: the specification first, validated by a human, then the tests derived from it, and the code last. One could see it as a return to the V-model, except that these documents are no longer frozen before the code: they are rewritten with every change. Every mistake and every bad experience thus enriches the specification and the tests instead of getting lost in the code.
A developer on the team once had to change a simple port number, and found it rather heavy to go through the specification first. Along the way, we discovered that our "primary" and "replica" hosts pointed to the same HAProxy and that only the port separated writes from reads, an architectural constraint written down nowhere, which now is, in the specification.
What I read instead of the code
So I no longer read the code, because the specification and its tests say better than the code what the application must do. My review hasn't disappeared, it has moved to the specification, just as code review changed floors, and that is where decisions are now made.
I'm not the only one on this path, and the approach is starting to be formalized under the name spec-driven development, with its own tools and specification formats designed for agents. Yet most of these tools treat the specification as the starting point of an implementation, without saying what becomes of it afterwards, whereas its value shows mostly months later, the day the project has to evolve.
It remains to be seen how many teams will accept this detour through the specification for a simple port number, when it is precisely what protects the project.
This article is the third in a series on working with agents, after I Stopped Running Several Agents and Those Who Removed Code Review Are Right.
Follow me on Bluesky: @bouchery.fr
