Spec-Driven Development(SDD): Vibe Coding With Extra Steps, or a Legitimate Framework?

What is SDD?

Generated by ChatGPT

https://github.com/github/spec-kit

AI coding has created a strange split in software engineering.

On one side, there’s the speed camp: open an editor, describe a feature in natural language, and let the model produce code. If it works, keep going. If it breaks, patch it with another prompt. This is what people loosely call vibe coding.

On the other side, a new class of workflows has started to emerge around structure. Instead of prompting directly for code, these systems ask you to define requirements, clarify ambiguities, generate implementation plans, derive tasks, and only then move into code generation.

That is the promise of Spec-Driven Development.

At first glance, it is easy to dismiss SDD as vibe coding with extra ceremony. A spec, then a plan, then tasks, then implementation?

I was pretty skeptical when I read about SDD but after spending time with the workflow, I think SDD is legitimate — but only for a specific reason.

It is legitimate because it changes where decisions are made and how intent is preserved.

Why vibe coding breaks down

Vibe coding is not hard to understand. It works because large language models are very good at turning loosely phrased intent into implementation. If your goal is speed, prototyping, or creative exploration, it is genuinely useful.

But it has a failure mode that becomes obvious on any non-trivial project.

The model starts making decisions that were never explicitly made.

That might mean:

• choosing a data shape you never approved
• assuming an authentication model
• inventing edge-case handling
• collapsing multiple user scenarios into one
• selecting a technical architecture because it is statistically common, not because it is correct

This is the core issue with ad hoc AI-assisted development: the output often looks coherent before the reasoning behind it has actually been stabilized.

That problem compounds quickly. Once code exists, it gains authority. The implementation starts to define the requirements retroactively. Teams begin discussing “what the system does” by looking at generated code instead of looking at a deliberate statement of intent. At that point, speed has become a liability.

This is where SDD becomes interesting.

What SDD actually changes

SDD is built around a simple inversion:

The specification is primary. Code is downstream.

In practice, that means the workflow does not begin with implementation prompts. It begins with a chain of artifacts that progressively transform intent into execution.

A typical SDD flow looks like this:

1. Constitution— define global project rules and engineering principles

2. Specification — define the feature in terms of behavior, user value, and success criteria

3. Clarification — identify and resolve ambiguity before technical design begins

4. Plan— translate the requirement into technical decisions

5. Tasks— break the plan into executable, dependency-aware work units

6. Analysis — detect inconsistencies, gaps, and violations before implementation

7. Implementation — execute against the artifact chain rather than a loose conversation

In a good SDD workflow, the feature specification is explicitly about what the system should do and why it matters. It is not supposed to contain implementation detail. That comes later, in the plan.

This matters because AI models are naturally eager to collapse those layers. If you ask for a feature, they tend to produce a combined output: requirements, architecture, implementation strategy, and code all at once. That feels efficient, but it is actually a form of decision leakage.

SDD puts hard boundaries around those decisions.

For example:

• spec.md captures user stories, requirements, assumptions, and success criteria

• plan.md captures technical context, architecture choices, and implementation direction

• tasks.md turns the design into execution steps, often grouped by user story and mapped to concrete files

That separation is not just process theater. It gives both humans and models cleaner reasoning scopes.

When the AI is writing the spec, it should not be inventing infrastructure. When it is writing the plan, it should not be inventing product requirements. When it is implementing tasks, it should not be renegotiating the feature definition.

That is a real improvement over freeform prompting.

The clarification stage is where SDD earns its keep

If there is one part of the workflow that makes SDD feel legitimate, it is the clarification stage.

Most AI coding workflows treat ambiguity as tolerable. The model will infer what you probably meant and keep moving. That works until the inferred detail turns out to be the most important part of the system.

SDD treats ambiguity as something to surface deliberately.

A proper clarification pass forces questions like:

• Who exactly is the actor in this scenario?
• What happens on failure?
• What are the performance expectations?
• Are there privacy or security constraints?
• What assumptions are acceptable?
• What counts as successful completion?

A huge portion of my time is spent on this phase, I keep clarifying and refining the specification until it is up to standard before any line of code is generated.

How the user is supposed to work with SDD

In the Spec Kit implementation, the flow typically looks like this:

1. Initialize the project

The workflow starts by bootstrapping the repository with the framework:

specify init .

This installs the project structure, templates, scripts, and agent-specific command files needed to drive the workflow.

2. Define the constitution

The constitution is the project’s top-level governance document. It defines the engineering rules the rest of the workflow must respect. That can include:

• architecture principles
• quality gates
• testing expectations
• design standards
• and project-wide constraints.

This is important because the system does not treat every feature as a blank slate. The constitution acts as a persistent steering mechanism. For mono repos with a clear project structure and framework, the constitution can be written to follow the framework and structure and not deviate from it. This ensures that the generated code can be integrated seemlessly with an exisiting project.

3. Write the feature specification

Next, the user describes the feature in structured form. This usually includes:

• functional requirements
• user stories
• assumptions
• key entities
• measurable success criteria

At this stage, the goal is to define the feature clearly without prematurely jumping into frameworks, schemas, or implementation details.

4. Clarify ambiguity

The clarify phase forces the workflow to identify what is still underspecified. Instead of letting the model silently guess, the user is asked targeted questions around scope, roles, edge cases, integrations, performance, security, and failure handling.

This stage is one of the biggest reasons the framework produces better outputs than ad hoc prompting.

5. Generate the technical plan

Once the feature definition is stable, the workflow creates a technical plan. That plan can include artifacts such as:

• plan.md
• research.md
• data-model.md
• contracts
• quickstart.md

This is where requirements become engineering decisions.

6. Generate task breakdowns

From the plan, the framework derives a set of tasks. Good task generation in SDD is not just a checklist. It creates dependency-aware work grouped by user story and tied to concrete implementation areas.

That means the AI or developer is no longer improvising from a vague feature prompt. They are executing a defined plan.

7. Analyze the artifacts

Before implementation, the workflow can perform a read-only analysis pass to identify:

• contradictions
• coverage gaps
• duplicated requirements
• constitution violations
• unresolved ambiguity

This acts as a quality control stage before code is written.

8. Implement deliberately

Only after all of that does implementation begin.

At this point, the AI is not inventing the feature from scratch. It is implementing from a stable chain of artifacts. That makes the coding phase more predictable and far easier to review.

Where SDD is strongest

In my experience, SDD is most useful when:

1. The feature is too large for a single prompt
2. Architectural decisions matter — most repositories have frameworks or structure that have been set up previously and you have to use them

That is where the framework stops feeling ceremonial and starts feeling practical.

Where SDD can still fail

To be fair, SDD is not a magic solution. Even when defining the spec as clearly as possible, there are times where the implemented code has bugs or does not meet the required standards. A better spec improves the odds of a better implementation, but it does not guarantee one. However, I find that compared to vibe coding, the results produced by SDD were significantly better. Most of the code could be deployed and productionalized after minor adjustments and manual debugging.

Final verdict

After using it, I do not think SDD is just vibe coding with extra steps.

I think it is a legitimate framework for one specific reason:

It converts AI-assisted development from improvisation into artifact-governed execution.

That does not mean every project needs it. For prototypes, throwaway tools, and early experiments, direct prompting is often the right tradeoff.

But once the work needs durability — once the code has to survive beyond a single session, a single contributor, or a single burst of prompting — SDD starts to make a lot more sense.

Disclaimer

All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.