Notes
Why I’ve stopped using Spec-Driven Development
I stopped using Spec-Driven Development because planning the entire architecture and task list upfront encouraged overengineering, delayed feedback, and made code reviews harder to manage. Now I work with one refined user story at a time and build vertical slices across the database, API, and frontend, so I can test each increment and keep the AI focused on working software.
2 min read
A few months ago I started using Spec-Driven Development: you write a detailed specification, hand it over to the agent, and it takes care of implementing it from start to finish. Proposal, specification, design, tasks, and code. On paper, it sounds good, and for quite a while I wanted to believe it was the way.
After months of use, I reached the same conclusions as the programmer who explained the same experience. And I’m not the only one: people like Kent Beck, Matt Pocock, and Dave Farley have raised objections too. I don’t like it, and I want to explain why.
The problem isn’t planning
Planning is necessary. The problem is planning everything at once. When you define the architecture, data model, and task list at the point when you know the least about the problem, you’re returning to the waterfall approach from twenty years ago. And the agent, unless someone tells it to keep things simple, fills the gaps with overengineering: interfaces you don’t need, database fields that make you wonder why they’re there, and abstraction layers designed for a future that will never arrive.
You ask for a login, and it gives you a three-page document with requirements, an architecture plan, twenty-seven tasks, and four layers. And you still can’t log in.
Nothing works until the end
The tasks come out layer by layer: first the entire database, then the API, and then the frontend. You can’t test a database without an API, and you can’t use an API without a frontend. The result is that nothing works until the final day, and when it does, the review consists of 3,000 lines of code to read through. The agent spent fifteen minutes fixing it, and you spend three hours reviewing it. Then you keep requesting changes until you break down and accept the whole thing as is. Familiar enough.
How I work now
What has worked for me is much older than AI: a backlog of short user stories, one at a time. As a user, I want to sign up with an email address and password. It is refined before it is built: cases, acceptance criteria, and, above all, what is out of scope.
Each story is then built as a vertical slice: it spans the database, API, and frontend, and when you’re done, you have something you can test by using it rather than reading it. If something is wrong, you find out within thirty minutes, not three days later.
The AI writes; you steer. You decide what gets built, what doesn’t, when to refactor, and when not to. And every small step is committed: if the agent touches a test to make it pass, you see it immediately.
In summary
Spec-Driven Development isn’t designed for programming; it’s designed for delegating the specification. The technical implementation is better handled in small steps, with the AI writing the code and you steering. Fewer documents, fewer layers, and more software that works.