Adam Tornhill published a piece today that I found myself nodding along to almost paragraph by paragraph. His argument: Spec-Driven Development, in its strong form, is a replay of the Model-Driven Architecture dream from the 1990s — and it will fail for the same reasons. Implementation is not the execution of a known scope. It is the discovery of scope that wasn’t known yet.
He’s right. And I want to pick up where he stops.
Where I agree completely
Tornhill’s core claim maps almost exactly onto something I wrote about earlier this year when thinking through why full specification fails with AI.
The temptation is understandable. If a senior engineer can articulate a problem clearly enough, why shouldn’t an agent just execute it? The answer is Glass’s requirements explosion: every explicit requirement generates a cascade of implicit ones. A spec that looks complete is usually covering maybe 20% of the actual decisions that need to be made. The rest gets made during implementation — through friction, surprise, and the slow accumulation of understanding.
When humans do this, they carry that understanding forward. When an agent does it unsupervised, the understanding evaporates. You’re left with working code and no one who knows why it works the way it does.
I’ve seen this dynamic accelerate in the past year. The codebases that are hardest to work with right now are not the legacy systems written a decade ago. They are systems built in the last twelve months with aggressive agent usage and no deliberate ownership structure. The code is often clean. The knowledge of it is almost nowhere.
The part Tornhill leaves open
Where I want to extend his argument is on what to do about it — not just what to avoid.
Tornhill’s closing is correct but general: predictable progress comes from domain expertise, intention-revealing design, automated safeguards, and rapid feedback. All true. But I think there is a more specific pattern worth naming.
The failure mode in strong SDD is not that specs exist. It’s that the spec becomes the primary artifact, and the human disappears from the loop between spec and running system. The fix is not less structure — it’s keeping humans in the right places within the structure.
What works, in my experience, is treating architecture as a set of deliberately small contracts between components, not as a comprehensive description of what the system does. You define the interface. You leave the implementation open. The agent fills in the implementation, the human reviews the boundary behaviour, and the feedback loop stays tight. This is what I described in Why AI Cannot Handle Full Specifications — not as a criticism of AI, but as a design principle for working with it well.
The spec is the interface. Not the system.
The ownership problem nobody is talking about
There is a second consequence of removing humans from the discovery process that I haven’t seen discussed much: knowledge evaporation at scale.
When implementation becomes fully delegated — whether to junior developers in 1995 or to agents in 2026 — the organisation loses the ability to answer a deceptively simple question: who actually understands this?
In the MDA days, that question was at least still answerable in principle. You could find the developer, sit down with them, and extract the knowledge.
With agents at scale, there may be no one to sit down with.
This is something I’ve been thinking about since we analysed MongoDB’s codebase and found that knowledge concentration persists even in well-maintained, professionally managed projects. The problem isn’t that people don’t care. It’s that knowledge distribution doesn’t happen automatically — it requires deliberate structure and visibility.
If SDD accelerates the removal of humans from the implementation loop, it accelerates exactly the dynamic that makes codebases hard to maintain, extend, and hand over. Tornhill calls this “constantly being in a legacy reverse engineering position.” I think that’s the right framing. And the answer to it has to include knowing — at all times — who understands what, and where the gaps are forming.
What this means in practice
None of this is an argument against AI-assisted development. I’m fully in favour of it. What I’d push back on — alongside Tornhill — is the idea that the answer to AI’s stochasticity is more upfront specification.
The answer is faster feedback. Tighter loops. And enough visibility into the codebase that you notice when understanding is disappearing, before it’s too late to recover it.
A spec is a hypothesis. Code is the experiment. The learning is the point.
This post is a response to Adam Tornhill’s A Blast from the Past: SDD and the Illusion of Known Scope (May 28, 2026).
This post is part of an ongoing series on working with AI in software and system architecture.