//Desarrollo Guiado por Especificaciones
SDD: La IA genera el código a partir de especificaciones
El spec-driven development es una metodología que refuerza la especificación como el artefacto central del desarrollo.|Desarrollo Guiado por Especificaciones
En los últimos tiempos hemos visto surgir y popularizarse lo que se ha dado en llamar vibe-coding: sesiones rápidas con modelos de IA, prompts sucesivos, prototipos que “aparecen” casi de la nada. Es una forma de trabajo muy fluida, ideal para explorar ideas o validar hipótesis, pero que empieza a mostrar grietas cuando se busca mantener, escalar o alinear el desarrollo con estándares de calidad, arquitectura y coherencia.
Frente a esto, aparece spec-driven development, un enfoque que propone situar la especificación —lo que debe hacer el sistema, con criterios claros de aceptación, diseño técnico y tareas desglosadas— como el artefacto central, sobre el que gravitan diseño, implementación, pruebas y mantenimiento.
Herramientas recientes como Kiro (el IDE inteligente de Amazon) o Spec-Kit (toolkit open source de GitHub) han empezado a operar bajo este paradigma, permitiendo que el flujo vaya desde la intención al código, con puntos de control, trazabilidad y menos supuestos ocultos.
Parece una batalla de hippies contra yuppies. Pero no es más que el resultado natural de la prueba y error en la que nos hemos metido con la IA.
El ciclo de desarrollo con IA
La ingeniería de software ha evolucionado a la par que las herramientas de IA. Pero, en general, he comprobado que una serie de tareas y metodologías se han establecido comunes a todos los desarrollos. En algunos casos de manera implícita, y en otros de forma mucho más visible.
0 steps specification
Se trata de la especificación implícita en el prompt inicial y en los sucesivos refinamientos durante una sesión de vibe-coding.
No hay ficheros y no se guarda el historial de la sesión en el repositorio. (Quizá, si acaso, en el editor)
idea -> prompt -> implementation -> review
^ v
| |
└ <- ? Esta es la estrategia que usan Cursor o Copilot por defecto; todo al chat.
1 step specification
En este caso las especificaciones formales tanto de negocios como técnicas se escriben en un fichero que sirve de base al generador de código.
Cada funcionalidad debería tener su propio fichero de especificación (o si se usa un sistema de gestión de especificaciones, un ticket o issue). En cualquier caso permite su revisión en equipo al formar parte de un repositorio.
- 1.my-feature.spec.md (todos los detalles desde todos los puntos de vista)
idea -> spec file -> prompt -> implementation -> review
^ v
| |
└ <- ? Estos ficheros contienen la definición del problema, la solución técnica y las pruebas de aceptación. Así que si crecen es normal que se desglosen en varios ficheros.
AIDDbot implementa esta estrategia sencilla y muy eficaz si se desglosa el problema de negocio en multiples funcionalidades pequeñas.
2 steps specification
Una evolución lógica consiste en separar la visión del negocio de la especificación técnica. De esta forma se acuerda antes la especificación del negocio en un fichero propio y luego se genera una solución técnica que la implemente en otro fichero. Será este último el que se use para generar el código.
Ahora por cada funcionalidad se generan dos ficheros de especificación.
- 1.my-feature.spec.md (desde el punto de vista del problema de negocio)
- 1.my-feature.plan.md (desde el punto de vista de la solución técnica)
idea -> spec file -> plan file -> prompt -> implementation -> review
^ ^ v
| | |
└ <-? <- ? Esto ya da más margen. Incluso permite explorar distintas soluciones al mismo problema. Pero, si la planificación es muy compleja, puede complicar la generación de código. En ese caso se desglosa en varios ficheros de tareas.
AIDDbot puede cambiarse fácilmente para adoptar esta estrategia.
3 steps specification
Es la implementación definitiva de la especificación. En este caso, tras la definición de la solución se realiza un paso intermedio en el que se detallan las tareas a realizar para implementar la solución. De esta forma el generador final será un mero runner de dichas tareas.
Por cada funcionalidad se generan tres ficheros de especificación.
- 1.my-feature.spec.md (desde el punto de vista del problema de negocio)
- 1.my-feature.plan.md (desde el punto de vista de la solución técnica)
- 1.my-feature.tasks.md (una lista de tareas a realizar para implementar la solución)
idea -> spec file -> plan file -> tasks file -> implementation -> review
^ ^ ^ v
| | | |
└ <-? <-? <- ? Como cada paso genera un artefacto evaluable, se puede usar para para refinar o revisar de manera parcial. El precio a pagar con estos pasos intermedios se recupera cuanto más compleja sea la funcionalidad o la arquitectura del proyecto.
Conclusión
En el panorama actual del desarrollo de software impulsado por IA, han emergido dos filosofías completamente opuestas: el “vibe coding” y el spec-driven development.
Herramientas como AIDDbot Kiro, y Spec-Kit enfatizan el desarrollo dirigido por intenciones donde las especificaciones definen el “qué” antes del “cómo” y están liderando esta transformación hacia un desarrollo más estructurado y predecible.
Como difusor de AI-Driven Development, mi apuesta es clara en favor de SDD cualquiera que sea el nivel de detalle y faseado que escojas.