Spec-Driven Development is becoming popular, especially in the context of AI-assisted software development. But when I look at what people mean by it, I see at least two very different interpretations. Both use the word “spec.” Both integrate AI deeply into the workflow. And yet they optimize for very different things.
Over the last months, I have spent a lot of time thinking about this distinction, because it fundamentally influences how we build systems.
The Task-Driven Interpretation
One interpretation of Spec-Driven Development is what I would call task-driven and developer-centric. Tools like Amazon Kiro or GitHub Spec-Kit are good examples of this direction. The workflow usually starts with a feature description. From there, a specification is generated, decomposed into tasks, and then translated into code with the help of AI.
In this model, the specification acts as a structured intermediate artifact between idea and implementation. It is primarily there to improve automation. The center of gravity is the developer, and the goal is acceleration. The question being optimized is: how can we get from idea to working code as efficiently as possible?
There is nothing wrong with that. In fact, for prototypes, internal tools, or well-scoped features, this approach can be extremely effective. AI shines when it can decompose technical tasks and generate consistent code across iterations.
However, in my experience, this interpretation of “spec” often emerges from implementation thinking. The specification describes what we intend to build in technical terms. It is closely tied to tasks, components, and code structure. As a result, the boundary between problem space and solution space becomes blurred very early in the process.
For simple systems, this may not matter. For long-lived systems with multiple stakeholders, it matters a lot.
The Stakeholder-Centric Interpretation
The other interpretation starts from a different place. Instead of beginning with features or tasks, it begins with system use cases. These describe interactions between actors and the system at a behavioral level. They focus on observable outcomes rather than technical decomposition.
In this approach, the specification is not an auxiliary artifact to guide code generation. It is the central artifact of the project. It represents shared understanding between stakeholders and the development team. It captures intent before implementation decisions are made.
The workflow, therefore, feels different. It moves from vision to requirements, from requirements to system use cases, and from there to an entity model and architectural constraints. Only after these artifacts are stable does implementation begin.
AI still plays a major role, but its role changes. It operates within clearly defined artifacts. The memory of the project is not stored in the model’s context window. It is stored in version-controlled documentation. AI becomes a powerful executor and assistant, but not the source of truth.
The AI Unified Process (AIUP) exactly follows this approach.
What I Care About
My preference is clearly with the stakeholder-centric approach.
Most of the systems I work on are not short-lived experiments. They are business-critical systems in domains like public administration or wholesale and retail. They evolve over many years, often across teams and generations of developers. In such environments, misalignment between stakeholders and implementation is far more expensive than slow code generation.
Task-driven workflows optimize for developer speed. Stakeholder-centric workflows optimize for alignment and longevity. For me, alignment wins.
If we start from tasks, we risk becoming extremely efficient at building the wrong thing. AI makes this risk even greater because it amplifies whatever structure we give it. A vague or technically biased specification will lead to large amounts of confident but misaligned output.
If we start from precise system use cases, AI becomes an amplifier of clarity instead of confusion. It can generate tasks, propose queries, create UI components, and write tests. But all of that follows from a stable description of the problem space.
How I See Them Working Together
Ido not see these two flavors as mutually exclusive. Task-driven AI workflows are extremely valuable once a solid, stakeholder-centric specification exists. After system use cases are defined, AI can help derive implementation tasks, generate code, and support refactoring.
The difference lies in where the direction comes from. In my view, the direction should come from the system description, not from a feature prompt.
For me, Spec-Driven Development is not about better prompt engineering. It is about making the problem space explicit and durable. It is about creating artifacts that outlive any single AI session and any single developer.
AI is an extraordinary tool. But it should operate within a clearly defined specification that reflects stakeholder intent. It should not define that intent itself.
That is why, when I speak about Spec-Driven Development, I mean the stakeholder-centric flavor. Not because the other one is wrong, but because for the kinds of systems I care about, it is not enough.
