TL;DR: SDD puts the specification at the center: well-written specifications can be used to generate code via AI agents. Fewer misunderstandings, faster iteration.

Definition of the concept

Imagine the specification is the recipe and the code is the final dish. In Specification Driven Development (SDD), the recipe is not a poor note in the margin; it's the manual that the chefs (including robot chefs—LLMs) use to cook the application.

SDD emerges as a philosophy in response to LLM-based agents and vibe coding: instead of writing code first and then documentation, well-written and executable documentation becomes the "source of truth" and guides code generation.

Quick example: you write a specification: "When button X is pressed, send notification Y to the user with conditions Z". An agent can transform that specification into endpoints, tests, and minimum viable deployment. Simple, repeatable, and traceable.

Source of truth

• Agile / Waterfall: Code rules. Specs often become outdated notes.
• SDD: The specification rules. Code is a temporal expression of that specification: if something is off, the spec is the source to correct.

In SDD, the specification functions as a contract: when the spec and code differ, the spec is the truth until we decide otherwise (and document it).

Change management (by analogy)

Think of changes as updating a recipe, not re-making the dish by hand every time:

• Before: a change in requirements causes chaos: code editing, PRs, hotfixes.
• With SDD: change the spec, regenerate implementations and tests. Experiment what-if at low cost.

---

	Traditional Methodologies (Agile / Waterfall)	Spec-Driven Development (SDD)
The Source of Truth	Code is King. Specs fall behind.	The Specification is King. The PRD generates the implementation.
Spec-Code Relationship	The specification is usually static and deviates from the code.	The specification is an executable artifact; code is its expression.
The Gap	Ambiguities and misunderstandings are inevitable.	Automatic transformation reduces or eliminates the interpretation gap.

Why now? (trends pushing SDD)

1. More capable AI: natural language specs generate functional code reliably.
2. More complex software: maintaining consistency manually is increasingly expensive.
3. Accelerated pace of change: pivots are the norm and you need to iterate quickly and safely.

This also enables an interesting game: generate multiple implementations from the same spec and compare advantages (performance vs. cost vs. maintainability).

Fundamental principles (one sentence each)

1. Specifications as lingua franca — the spec is the central artifact.
2. Executable specifications — precise, complete, and unambiguous.
3. Continuous refinement — validation and ambiguity detection all the time.
4. Research-driven context — agents collect context and technical options.
5. Bidirectional feedback — production feeds back into the specification.
6. Branching for exploration — generate alternatives to optimize different objectives.

Small exercise (try it!)

Take a user story and turn it into a minimal spec (3–5 lines) that's clear and unambiguous. Then ask yourself:

• Can an agent generate endpoints and tests from this?
• What ambiguities remain?

If you answered yes and there's little ambiguity, you've taken a big step toward SDD.

Final reflection

SDD doesn't come to replace the developer: it comes to turn them into a specification architect, orchestra conductor, and curious critic. It's a powerful way to accelerate iterations, improve traceability, and minimize technical debt when properly implemented.

---

Sources and references

• SDD definition provided by GitHub Spec Kit: github.com/github/spec-kit

TL;DR: SDD pone la especificación en el centro: unas buenas especificaciones pueden usarse para generar código mediante agentes de IA. Menos malentendidos, iteración más rápida.

Definición del concepto

Imagina que la especificación es la receta y el código es el plato final. En Specification Driven Development (SDD), la receta no es una nota perdida en el margen: es el manual que usan los chefs (incluidos los chefs robot — los LLMs) para cocinar la aplicación.

SDD surge como filosofía en respuesta a los agentes basados en LLM y al vibe coding: en lugar de escribir primero código y luego documentación, una documentación bien escrita y ejecutable se convierte en la "fuente de verdad" y guía la generación de código.

Ejemplo rápido: escribes una especificación: "Cuando se pulse el botón X, enviar la notificación Y al usuario con las condiciones Z". Un agente puede transformar esa especificación en endpoints, pruebas y un despliegue mínimo viable. Sencillo, repetible y trazable.

Fuente de verdad

• Agile / Waterfall: manda el código. Las especificaciones suelen quedarse como notas desactualizadas.
• SDD: manda la especificación. El código es una expresión temporal de esa especificación: si algo no cuadra, la fuente a corregir es la spec.

En SDD, la especificación funciona como un contrato: cuando la spec y el código difieren, la spec es la verdad hasta que decidamos lo contrario (y lo documentemos).

Gestión del cambio (por analogía)

Piensa en los cambios como actualizar una receta, no como rehacer el plato a mano cada vez:

• Antes: un cambio de requisitos genera caos: editar código, PRs, hotfixes.
• Con SDD: cambias la spec, regeneras implementaciones y pruebas. Experimentas what-if con bajo coste.

---

	Metodologías tradicionales (Agile / Waterfall)	Specification Driven Development (SDD)
Fuente de verdad	El código manda. Las especificaciones se quedan atrás.	La especificación manda. El PRD genera la implementación.
Relación spec-código	La especificación suele ser estática y acaba desviándose del código.	La especificación es un artefacto ejecutable; el código es su expresión.
La brecha	Las ambigüedades y los malentendidos son inevitables.	La transformación automática reduce o elimina la brecha de interpretación.

¿Por qué ahora? (tendencias que empujan SDD)

1. IA más capaz: las especificaciones en lenguaje natural generan código funcional de forma fiable.
2. Software más complejo: mantener la consistencia manualmente es cada vez más caro.
3. Ritmo de cambio acelerado: los giros son la norma y hay que iterar rápido y con seguridad.

Esto también abre un juego interesante: generar varias implementaciones a partir de la misma spec y comparar ventajas (rendimiento vs. coste vs. mantenibilidad).

Principios fundamentales (una frase cada uno)

1. Las especificaciones como lengua franca — la spec es el artefacto central.
2. Especificaciones ejecutables — precisas, completas y sin ambigüedades.
3. Refinamiento continuo — validación y detección de ambigüedades todo el tiempo.
4. Contexto guiado por investigación — los agentes recopilan contexto y opciones técnicas.
5. Retroalimentación bidireccional — la producción vuelve a alimentar la especificación.
6. Ramificación para explorar — generar alternativas para optimizar distintos objetivos.

Pequeño ejercicio (¡pruébalo!)

Toma una historia de usuario y conviértela en una spec mínima (3–5 líneas) que sea clara y sin ambigüedades. Después pregúntate:

• ¿Puede un agente generar endpoints y pruebas a partir de esto?
• ¿Qué ambigüedades siguen ahí?

Si la respuesta es sí y apenas hay ambigüedad, ya has dado un paso importante hacia SDD.

Reflexión final

SDD no viene a reemplazar al desarrollador: viene a convertirlo en arquitecto de especificaciones, director de orquesta y crítico curioso. Es una forma potente de acelerar iteraciones, mejorar la trazabilidad y minimizar deuda técnica cuando se implementa bien.

---

Fuentes y referencias

• Definición de SDD proporcionada por GitHub Spec Kit: github.com/github/spec-kit