Cuando un equipo oye hablar de Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, la primera pregunta suele ser si es otra metodología más que añadir a la lista. Ya tenían TDD, ya habían probado BDD, y ahora llega una tercera sigla con «Driven» en medio.
La pregunta tiene sentido, pero parte de una premisa equivocada: que las tres compiten por el mismo sitio. No es así. Cada una responde a una pregunta distinta, y cuando el código lo escribe un agente, las tres preguntas siguen ahí. Lo que cambia es quién lee la respuesta.
La tesis de esta pieza: SDD no sustituye a TDD ni a BDD; los necesita. BDD aporta la forma de escribir los criterios, con ejemplos concretos. TDD aporta el ciclo que demuestra que se cumplen, con un test que falla antes de que exista el código. SDD añade que esa especificación es lo que lee el agente y la fuente de verdad del trabajo. Quitar cualquiera de las tres deja un hueco que el agente no va a rellenar por su cuenta.
Tres preguntas distintas
Antes de compararlas, conviene separar qué pregunta contesta cada una. Las tres se pueden confundir porque las tres hablan de especificar antes de programar.
| Práctica | Pregunta que responde | Qué produce | Qué aporta cuando escribe un agente |
|---|---|---|---|
| BDD (Behaviour-Driven Development) | ¿Cómo describimos lo que el sistema debe hacer? | Ejemplos concretos, legibles por personas y por máquinas | Criterios sin ambigüedad, que se pueden convertir en escenarios |
| TDD (Test-Driven Development) | ¿Cómo demostramos que el código cumple? | Un test que falla primero y pasa después | Una comprobación que el agente no controla |
| SDD (Spec-Driven Development) | ¿Qué lee el agente antes de escribir? | Una especificación que es la entrada del trabajo y la fuente de verdad | El contexto y el alcance de la tarea, escritos y revisables |
Elaboración propia de onext, a partir de Cucumber, la especificación de spec-kit y el análisis de Birgitta Böckeler (consultados el 10 de octubre de 2026)
BDD: la forma de escribir el criterio
Cucumber, la herramienta que nació para apoyar BDD, lo organiza en tres prácticas. En el descubrimiento, conversaciones estructuradas alrededor de ejemplos reales del sistema desde el punto de vista del usuario. En la formulación, cada ejemplo se escribe como documentación estructurada, en un medio que pueden leer «tanto personas como máquinas». En la automatización, esa especificación ejecutable guía la implementación.
Esa forma de escribir no ha desaparecido con los agentes: ha vuelto. Birgitta Böckeler, de Thoughtworks, analizó tres herramientas de SDD y describe que Kiro estructura los requisitos como historias de usuario con criterios de aceptación en formato GIVEN… WHEN… THEN…, el que popularizó BDD. Un criterio escrito así se puede leer en una reunión y también ejecutar en una prueba.
El mismo análisis trae el aviso contrario: en una de sus pruebas, el documento de requisitos convirtió una corrección pequeña en cuatro historias de usuario con dieciséis criterios. El formato ayuda a precisar; no decide cuánto hay que precisar. Esa decisión sigue siendo de una persona, y la defendimos con más detalle en MVP frente a especificación.
TDD: la prueba de que se cumple
Aquí está la parte que más se pierde cuando se habla de SDD. La especificación de spec-kit, el kit de GitHub para trabajar con SDD, la llama «Test-First Imperative» y la escribe como regla: toda implementación sigue TDD estricto, y no se escribe código de implementación hasta que los tests están escritos, «validados y aprobados por el usuario» y comprobados en rojo, es decir, fallando. En otro punto lo resume en una frase: los escenarios de aceptación se convierten en tests.
Kent Beck, que popularizó TDD, cuenta en «Augmented Coding: Beyond the Vibes» cómo intentó que su agente trabajara así. Sus instrucciones eran explícitas: seguir siempre el ciclo rojo, verde, refactorizar; escribir primero el test más simple que falle; un test cada vez. Y enumera tres señales de que el agente se estaba desviando: bucles, funcionalidad que no había pedido y cualquier indicio de que hacía trampa, por ejemplo desactivando o borrando tests.
Riesgo Un agente que puede editar los tests puede hacer que «pasen» sin cumplir nada. Los cambios en los tests son cambios en el criterio con el que se juzga el resto del código: merecen una revisión aparte, y antes que la del código.
Hay un matiz que no conviene saltarse: que un test exista no significa que pruebe lo que debe. Un test escrito mirando el código que ya hay describe lo que hace ese código, no lo que debería hacer; lo explicamos en los tests generados por IA no prueban, describen. Por eso el orden importa: el test sale del criterio y falla antes de que el código exista.
SDD: lo que cambia cuando el lector es un agente
Lo que SDD añade a las otras dos no es una técnica nueva de pruebas. Es un cambio de lector. En TDD y en BDD, el que lee el criterio es una persona que va a programar. En SDD, quien lo lee es un agente, y la especificación pasa a ser la entrada del trabajo: el contexto, el alcance y lo que se considera terminado.
Böckeler distingue tres niveles. En el primero, la especificación se escribe antes y se usa para la tarea (spec-first). En el segundo, se conserva después para seguir evolucionando esa funcionalidad (spec-anchored). En el tercero, la especificación es el archivo principal y la persona ya no toca el código (spec-as-source). Para un equipo que empieza, el primero es el punto de partida natural, y es donde más rinde la combinación con TDD.
Y aquí está la razón de fondo de la tesis. Böckeler lo dice con sus palabras: incluso con todos esos archivos, plantillas, flujos y listas de comprobación, vio con frecuencia que el agente acababa sin seguir todas las instrucciones. También lo vio pasarse de celo con alguna. Una especificación que el agente lee pero que nada comprueba depende de que el agente la siga. Un test que falla mientras el comportamiento no exista no depende de eso.
Cómo encajan en una tarea
Puestas en orden, las tres prácticas no se pisan: cada una ocupa un tramo. Esta secuencia es una propuesta de criterio, no una norma de ninguna de las fuentes:
- Ejemplos antes que requisitos. Negocio y desarrollo acuerdan dos o tres casos concretos de lo que debe pasar, incluido uno que no debe pasar (BDD, descubrimiento).
- Criterios en la especificación. Cada ejemplo se escribe como criterio de aceptación verificable, en GIVEN/WHEN/THEN o en un formato equivalente, dentro de la especificación que leerá el agente (BDD, formulación; SDD).
- Tests que fallan, aprobados por una persona. De cada criterio sale un test; alguien comprueba que prueba lo que dice el criterio y que falla (TDD, rojo).
- El agente implementa. Con la especificación como contexto y los tests como meta, sin permiso para cambiarlos sin revisión (SDD y TDD, verde).
- Revisión de lo que no cubre el test. Lo que pasó en verde no se revisa otra vez línea a línea; se revisa lo que ningún criterio cubría y cualquier cambio en los tests.
El tercer paso es el que convierte la especificación en una puerta y no en un documento: lo desarrollamos en tu spec ya es un eval. Y el punto en el que una persona firma esa especificación, antes de que el agente genere nada, en la especificación es donde se firma.
La discrepancia: ¿se parece más a TDD o al MDD?
Sería más cómodo presentar SDD como la evolución natural de TDD y BDD. Böckeler no lo ve así del todo. Admite que mucha gente dibuja la analogía con TDD y BDD, pero propone mirar otro paralelo, sobre todo para el nivel spec-as-source: el Model-Driven Development (MDD), en el que los modelos eran las especificaciones y un generador producía el código. El MDD no llegó a cuajar en las aplicaciones de negocio, y ella se pregunta si ese nivel de SDD acabará con los inconvenientes del MDD y de los modelos de lenguaje a la vez.
Su cierre es todavía más incómodo: se pregunta si algunas herramientas no están trasladando los flujos existentes a los agentes de forma demasiado literal y amplificando problemas que ya existían, como la sobrecarga de revisión. Usa una palabra alemana para describirlo, Verschlimmbesserung: empeorar algo al intentar mejorarlo.
No hay por qué resolver aquí esa discusión, pero sí sacar una consecuencia práctica. El riesgo que describe crece cuanto más se aleja la especificación de algo que se pueda comprobar: muchos archivos, mucha prosa, ningún test que falle. La combinación con TDD es justo lo que mantiene a SDD en el lado verificable. Es el mismo argumento con el que empezamos a hablar de Spec-Driven Development y código bajo control.
Y si esa especificación vive en un repositorio con un asistente como Claude Code, la otra mitad de la pregunta es qué reglas se le sugieren al agente y cuáles se le imponen; lo contamos en CLAUDE.md es contexto, no control.
Preguntas frecuentes
¿Qué diferencia hay entre SDD, TDD y BDD?
Responden a preguntas distintas. BDD (Behaviour-Driven Development) trata de cómo se describe el comportamiento esperado: con ejemplos concretos, acordados entre negocio y desarrollo y escritos de forma que los lean personas y máquinas. TDD (Test-Driven Development) trata de cómo se demuestra que el código cumple: se escribe primero un test que falla y después el código mínimo que lo hace pasar. SDD (Spec-Driven Development) trata de qué lee el agente que escribe el código: la especificación es la entrada del trabajo y la fuente de verdad.
¿SDD sustituye a TDD?
No. La propia especificación de spec-kit, el kit de GitHub para SDD, incluye TDD como regla: ningún código de implementación antes de que los tests estén escritos, aprobados por el usuario y comprobados en rojo. Sin un test que falle primero, la especificación orienta al agente, pero nada demuestra que la haya cumplido.
¿Hay que escribir las especificaciones en formato GIVEN/WHEN/THEN?
No es obligatorio, pero ayuda. Birgitta Böckeler describe que Kiro estructura los requisitos como historias de usuario con criterios de aceptación en formato GIVEN… WHEN… THEN…. Es el formato que popularizó BDD, y su ventaja es que cada criterio se puede convertir en un escenario ejecutable. El riesgo es el contrario: Böckeler vio cómo una corrección pequeña se convertía en cuatro historias de usuario con dieciséis criterios.
¿Por qué un agente puede saltarse la especificación?
Porque leerla no garantiza seguirla. Böckeler cuenta que, incluso con plantillas, flujos y listas de comprobación, vio con frecuencia al agente no seguir todas las instrucciones, y también lo vio pasarse siguiendo alguna demasiado al pie de la letra. Por eso hace falta algo que el agente no controle: un test que falla mientras el comportamiento no exista.
¿Qué hago si el agente modifica o borra los tests para que pasen?
Tratarlo como una señal de alarma, no como un detalle. Kent Beck la incluye entre las tres señales de que el agente se está desviando: cualquier indicio de que hace trampa, por ejemplo desactivando o borrando tests. En la práctica, los cambios en los tests deberían revisarse aparte del código y con más atención, porque son el criterio con el que se juzga todo lo demás.
¿SDD es lo mismo que el Model-Driven Development?
No, pero hay quien ve el parecido. Böckeler apunta que, sobre todo en el nivel en el que la especificación es la única fuente que edita una persona (spec-as-source), otro paralelo importante es el MDD: los modelos eran especificaciones de las que se generaba el código. El MDD no llegó a cuajar en las aplicaciones de negocio, y ella se pregunta si ese nivel de SDD acabará con los inconvenientes de los dos mundos.
Fuentes
- Birgitta Böckeler (Thoughtworks), «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 de octubre de 2025.
- GitHub spec-kit, «Specification-Driven Development (SDD)» (sin fecha visible; consultada el 10 de octubre de 2026).
- Kent Beck, «Augmented Coding: Beyond the Vibes», Software Design: Tidy First?, 25 de junio de 2025.
- Cucumber, «Behaviour-Driven Development» (consultada el 10 de octubre de 2026).
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →