Mapa práctico de metodologías Spec-Driven Development

1. Qué es SDD

1.1. Definición y pasos

En SDD, el código se escribe a partir de una especificación que se ha escrito y revisado antes. La especificación se actualiza cuando el sistema cambia. Los pasos habituales son:

1. Intención
2. Especificación
3. Resolver dudas
4. Plan técnico
5. Tareas
6. Implementación
7. Validación
8. Actualizar la spec

Figura 1. Pasos de SDD. La spec se actualiza cuando el sistema cambia.

Una buena especificación responde a seis preguntas:

• Qué debe hacer el sistema.
• Para quién.
• Con qué reglas de negocio.
• Con qué limitaciones (técnicas, legales, de rendimiento).
• Qué queda fuera del proyecto.
• Cómo se comprueba que funciona.

1.2. Tres niveles de SDD

Birgitta Böckeler (Thoughtworks) clasifica SDD en tres niveles según qué se hace con la spec después de programar (martinfowler.com, 15 de octubre de 2025). Sirve para no comparar herramientas que buscan cosas distintas.

• Nivel — Qué se hace con la spec — Herramientas (según Böckeler, oct. 2025)
• Spec-first — Se escribe antes de programar y se usa para esa tarea. Después puede quedar sin actualizar. — Kiro; Spec Kit en su estado actual
• Spec-anchored — Se conserva y se actualiza cada vez que la funcionalidad cambia. — Tessl (es su objetivo); Spec Kit quiere llegar a este nivel; OpenSpec (clasificación de este documento)
• Spec-as-source — La spec es lo único que se edita. El código se genera a partir de ella y no se toca a mano. — Tessl lo está probando (en beta privada en oct. 2025; estado actual (?))

Böckeler no analiza OpenSpec. Lo situamos en spec-anchored porque guarda las specs y las actualiza con cada cambio.

1.3. Qué no es SDD

• No es escribir documentación antes de programar. Si nadie usa la spec para decidir, programar o probar, es solo documentación.
• No es tener un contrato técnico. Un fichero OpenAPI describe una API, pero no explica el objetivo del producto, las reglas de negocio ni cómo se acepta el resultado.
• No sustituye al diseño técnico. Primero se decide qué hay que hacer, después cómo hacerlo y por último se programa.
• No garantiza que el agente haga lo que dice la spec. Hay que comprobarlo con tests y revisión (sección 7).

1.4. Problemas conocidos

Böckeler señala estos problemas al usar herramientas SDD:

• Demasiado proceso para cambios pequeños. Escribir spec, plan y tareas para corregir un error menor cuesta más de lo que aporta.
• Mucho texto que revisar. Spec Kit genera muchos ficheros Markdown repetitivos. Böckeler dice que prefiere revisar código antes que todo ese texto.
• No está claro qué va en cada documento. No siempre se sabe qué va en la spec funcional y qué en la técnica.
• El agente puede no seguir la spec. Aunque la spec esté bien, el agente puede saltarse instrucciones o entenderlas de otra forma.
• Resultados distintos con la misma spec. Cuando el código se genera a partir de la spec, dos ejecuciones pueden producir código diferente.

En la práctica: para cambios pequeños, un proceso corto; para funcionalidades importantes, el proceso completo.