Spec-Driven Development

Spec-driven development is a methodology that emphasizes the specification as the central artifact of the development process.

Spec-Driven Development

Recently, we've seen the rise and popularization of what's been called vibe-coding. This involves quick sessions with AI models, successive prompts, and prototypes that seem to appear out of nowhere. It's a very fluid way of working, great for exploring ideas or validating hypotheses. However, it starts to show cracks when you need to maintain, scale, or align development with quality standards, architecture, and consistency.

In contrast, spec-driven development proposes placing the specification—what the system should do, with clear acceptance criteria, technical design, and broken-down tasks—as the central artifact. All other aspects, including design, implementation, testing, and maintenance, revolve around it.

Recent tools like Kiro (Amazon's intelligent IDE) or Spec-Kit (GitHub's open-source toolkit) have started operating under this paradigm. This allows the workflow to go from intent to code, with checkpoints, traceability, and fewer hidden assumptions.

It may seem like a battle of hippies versus yuppies. But it's just the natural result of the trial and error we've gotten into with AI.

---

The AI Development Cycle

Software engineering has evolved alongside AI tools. In general, I've found that a number of tasks and methodologies have become common to all development processes. In some cases, this is implicit, and in others, it's much more visible.

0 Steps Specification

This refers to the implicit specification in the initial prompt and in successive refinements during a vibe-coding session.

There are no files, and the session history isn't saved in the repository (maybe in the editor, if at all).

idea -> prompt -> implementation -> review
           ^                           v     
           |                           |
           └             <-            ?

This is the default strategy used by Cursor or Copilot; everything is done in the chat.

1 Step Specification

In this approach, formal business and technical specifications are written in a single file that serves as the basis for the code generator.

Each feature should have its own specification file (or a ticket/issue if using a specification management system). In any case, it allows for team review as it's part of a repository.

• 1.my-feature.spec.md (all details from all viewpoints)

idea -> spec file -> prompt -> implementation -> review
           ^                                        v     
           |                                        |
           └                <-                      ?

These files contain the problem definition, the technical solution, and acceptance tests. So, if they grow, it's normal for them to be broken down into multiple files.

AIDDbot implements this simple and very effective strategy if the business problem is broken down into multiple small features.

2 Steps Specification

A logical evolution is to separate the business vision from the technical specification. This way, the business specification is agreed upon first in its own file, and then a technical solution is generated to implement it in another file. It's this latter file that's used to generate the code.

Now, for each feature, two specification files are generated.

• 1.my-feature.spec.md (from the business problem's perspective)
• 1.my-feature.plan.md (from the technical solution's perspective)

idea -> spec file -> plan file -> prompt -> implementation -> review
           ^             ^                                      v
           |             |                                      |
           └           <-?               <-                     ?

This gives you more flexibility. It even allows for exploring different solutions to the same problem. However, if the planning is very complex, it can complicate code generation. In that case, it's broken down into multiple task files.

AIDDbot can be easily changed to adopt this strategy.

3 Steps Specification

This is the definitive implementation of the specification. In this case, after defining the solution, an intermediate step is taken to detail the tasks required to implement the solution. This way, the final generator is a mere runner of these tasks.

For each feature, three specification files are generated.

• 1.my-feature.spec.md (from the business problem's perspective)
• 1.my-feature.plan.md (from the technical solution's perspective)
• 1.my-feature.tasks.md (a list of tasks to perform to implement the solution)

idea -> spec file -> plan file -> tasks file -> implementation -> review
           ^             ^           ^                              v
           |             |           |                              |
           └           <-?         <-?               <-             ?

Since each step generates an evaluable artifact, it can be used for partial refinement or review. The price paid for these intermediate steps is recovered the more complex the feature or project architecture is.

Kiro and Spec-Kit opt for this strategy.

---

Conclusion

In the current landscape of AI-driven software development, two completely opposite philosophies have emerged: "vibe coding" and spec-driven development.

Tools like AIDDbot, Kiro, and Spec-Kit emphasize intent-driven development where specifications define the "what" before the "how," and they are leading this transformation toward more structured and predictable development.

As a promoter of AI-Driven Development, my preference is clearly in favor of SDD, regardless of the level of detail and phasing you choose.