Las formas de pedirle a la IA que programe se están diversificando rápidamente.
En un extremo está el vibe coding: construir de forma improvisada mediante conversación. En el otro, el tema de este artículo: Spec Driven Development (SDD).
En una frase: SDD fija primero la especificación (spec) en un documento antes de pedir código.
Ese documento se convierte en la única fuente de verdad y guía a la IA durante la planificación, la implementación y la validación.
Este artículo explica cómo funciona SDD, sus herramientas representativas, spec-kit y Kiro, y cuándo usarlo en lugar del vibe coding. La información de las herramientas corresponde a agosto de 2026.
Empecemos por el resumen clave.
- SDD define primero «qué construir» en un documento spec y trata el código como su resultado.
- El flujo tiene cuatro etapas: spec (requisitos) → plan (diseño técnico) → tasks (desglose del trabajo) → implementación.
- spec-kit de GitHub y Kiro de AWS son herramientas representativas que implementan este flujo.
- La división habitual es vibe coding para prototipos y SDD para código de producto que se mantendrá durante mucho tiempo.
Por qué las especificaciones han vuelto
La idea de escribir documentación antes de desarrollar no es nueva. Las especificaciones de requisitos de la época de la cascada hacían exactamente eso, pero Agile las desplazó por ser demasiado pesadas.
La aparición de los agentes de IA cambió la situación. Los desarrolladores humanos hacen preguntas y completan el contexto incluso cuando reciben requisitos ambiguos.
En cambio, la IA rellena los huecos con suposiciones plausibles cuando recibe un prompt ambiguo. El resultado no coincide con los requisitos, pero parece correcto: el tipo de defecto más problemático.
Así surgió la necesidad de «eliminar primero la ambigüedad para asignar trabajo a la IA», y las especificaciones volvieron como respuesta. Esta vez el documento sirve como criterio de ejecución para la IA, no solo como documento para personas.
La canalización de cuatro etapas, de spec a tasks
Los nombres varían un poco según la herramienta, pero la estructura es la misma.
| Etapa | Resultado | Qué se fija |
|---|---|---|
| Specify | spec.md | Qué construir y por qué (requisitos · escenarios) |
| Plan | plan.md | Cómo construirlo (pila tecnológica · arquitectura) |
| Tasks | tasks.md | En qué orden construirlo (desglose en unidades de trabajo) |
| Implement | Código | Implementar cada task en orden |
Hay dos reglas fundamentales.
Primero, solo se pasa a la siguiente etapa después de que una persona revise y apruebe el resultado anterior. Así, la ambigüedad se filtra en la documentación antes de llegar al código.
Segundo, si cambian los requisitos durante la implementación, se modifica spec, no el código, y se rehacen las etapas posteriores. spec debe ser siempre la verdad más reciente.
Visto al revés: el código ya no es el original, sino el resultado de compilar spec. La fuente real es la documentación.
Dos herramientas: spec-kit y Kiro
spec-kit de GitHub es un toolkit de código abierto que no depende de un agente concreto.
Añade los comandos de barra /specify, /plan y /tasks sobre Claude Code, Copilot, Gemini CLI y otros, y así impone la canalización anterior.
También se caracteriza por incluir un documento constitution con los principios inmutables del proyecto.
Kiro de AWS es un IDE agéntico diseñado desde el principio alrededor de SDD. Crea tres documentos: requirements.md, design.md y tasks.md.
Su fortaleza es la notación de requisitos. Estructura los requisitos mediante EARS (Easy Approach to Requirements Syntax).
El método los organiza en frases como «El sistema debe ~ en una situación ~».
Si ya usas un agente generalista como Claude Code, añadir spec-kit tiene un coste de adopción menor. Si buscas una experiencia integrada en el IDE, Kiro encaja mejor.
La frontera frente al vibe coding
SDD no siempre es lo correcto. Crear y revisar tres documentos tiene un coste real, así que aplicarlo a un prototipo de fin de semana o a un script puntual puede resultar excesivo.
El criterio es la vida útil del código. Si puedes desecharlo esta semana, itera rápido con vibe coding.
Si el código se mantendrá y ampliará durante varios meses o más, eliminar primero la ambigüedad con SDD reduce el coste total.
También hay un punto que vigilar en producción: el drift, cuando spec y el código quedan desalineados.
En cuanto se rompe la regla «los cambios de requisitos deben empezar siempre por spec», spec se convierte en un documento en el que nadie confía. Entonces todo SDD queda reducido a un trámite formal.
Resumen
En última instancia, SDD sostiene que «el verdadero lenguaje de programación de la era de la IA son las especificaciones en lenguaje natural». Eleva la comunicación de intención, antes resuelta con una línea de prompt, a un documento revisable.
Antes de escribir un prompt para tu próxima funcionalidad, prueba a redactar primero un documento spec. En un día podrás decidir si esta metodología encaja con tu trabajo.