The Problem with Spec-Driven Development

I’ll admit I’ve used the term “spec-driven development” myself when describing how I work with AI agents to analyse problems and generate initial solution representations. But I’m increasingly concerned about the implications of this terminology, especially as someone cheekily abbreviates it to “SDD”.

In traditional software engineering, a “specification” meant a comprehensive, detailed document that captured all requirements upfront - a contract written in stone before any code was written. It was the cornerstone of Waterfall, where business analysts would throw specs “over the wall” to developers who were expected to implement exactly what was written, no questions asked. And Waterfall is a dysfunction; not a model for software.

When I use AI agents in my workflow, it’s fundamentally different. I’m using them to explore and understand problem spaces, then iteratively refine solutions through ATDD/TDD cycles with continuous red-green-refactor loops. It’s exploratory, adaptive, and collaborative - the antithesis of Waterfall.

By calling it “spec-driven development,” we risk validating the worst instincts of organisations that have always viewed engineers as “obedient executors” rather than creative problem-solvers. I can already hear certain executives thinking: “Finally! We can just write our ideas in natural language, feed them to the AI, and skip those pesky engineers altogether!”

This couldn’t be more wrong. The value of engineering isn’t in translating specs to code - it’s in understanding problems deeply, questioning assumptions, proposing alternatives, and building solutions that actually work in the messy real world.

Words shape thinking. Let’s not accidentally resurrect the ghosts of waterfall past just when we’ve finally learned how to work better.

Originally posted on LinkedIn.