Spec Driven Development: qué es, de dónde viene y para qué sirve

Si llevas unos meses siguiendo el ruido de Twitter/X, LinkedIn y los blogs de las grandes plataformas, habrás visto que el término Spec Driven Development aparece cada vez más. GitHub lo usa para presentar Spec Kit. Microsoft lo menciona en su documentación de Azure Verified Modules. InfoQ le dedicó un artículo largo a principios de 2026.

Detrás del buzz hay algo concreto. SDD no es un invento reciente ni un eufemismo para “escribir documentación”. Tiene historia, tiene una mecánica clara y, con los agentes de código actuales, cobra un sentido que antes era difícil de aprovechar.

De dónde viene todo esto #

La idea de usar especificaciones como fuente principal de verdad no es nueva. Wikipedia documenta que la metodología fue formalizada académicamente en 2004 como síntesis entre el desarrollo guiado por pruebas (Test-Driven Development, TDD) y el diseño por contrato (Design by Contract, DbC). Antes de que nadie hablara de LLMs ni de agentes de código.

En paralelo, Martin Fowler publicó ese mismo año su análisis de Specification by Example, donde planteaba que los ejemplos podían ser el artefacto principal en la especificación, no solo documentación auxiliar. Esa idea conecta directamente con lo que hoy se llama SDD.

El concepto dormitó durante una década. No porque fuera malo, sino porque la complejidad de mantener especificaciones formales sincronizadas con el código real era tan alta que los equipos acababan abandonándolas. La documentación se desactualizaba, las specs se quedaban obsoletas en semanas y el esfuerzo de mantenerlas no compensaba.

Lo que ha cambiado con los LLMs es que ahora hay una capa de ejecución que puede consumir esas especificaciones directamente, generando código y validando contra ellas de forma continuada. De repente, el coste de mantener una spec tiene una contrapartida clara: el agente que la usa para no inventarse cosas.

Qué es exactamente SDD #

Spec Driven Development es un enfoque donde la especificación pasa a ser la fuente principal de verdad del sistema. No documentación auxiliar que se escribe después, ni un README que se actualiza cuando alguien se acuerda. Una fuente de verdad verificable y ejecutable a partir de la cual se genera, valida y vuelve a generar el código.

GitHub lo explica con bastante claridad en el artículo de presentación de Spec Kit: en vez de empezar programando y documentar después, se empieza por una spec que describe qué debe hacer el sistema y esa spec se convierte en el artefacto que guía la generación, la validación y la revisión del resultado. El código deja de ser el punto de partida y pasa a ser la expresión final de una intención previamente formalizada.

Eso cambia algunas cosas importantes:

• La conversación pasa de “cómo implemento esto” a “qué quiero conseguir y bajo qué restricciones”.
• La arquitectura deja de ser orientativa y se vuelve validable.
• El agente tiene menos margen para improvisar, porque opera con una guía más precisa de qué tiene que construir.

La conexión con TDD es directa: igual que en TDD escribes el test antes que el código para definir qué debe hacer la función, en SDD escribes la especificación antes que el código para definir qué debe hacer el sistema. La diferencia es que la spec puede ser mucho más rica en contexto, restricciones y decisiones de arquitectura que un test unitario.

El ciclo de cuatro fases #

La implementación moderna de SDD que documentan tanto GitHub como Wikipedia sigue un ciclo de cuatro fases:

Specify — Se define qué se quiere construir y por qué. Qué requisitos funcionales hay, qué restricciones técnicas y de negocio existen, qué no debe hacer el sistema. En el Spec Kit de GitHub esto se traduce en el comando /specify, que ayuda a estructurar ese pensamiento antes de pedir que se genere nada.

Plan — La intención se traduce en arquitectura técnica: qué componentes hay, cómo se relacionan, qué stack se usa, qué decisiones de diseño se toman. El plan no es código; es la descripción de la solución antes de implementarla.

Tasks — El plan se descompone en unidades pequeñas, atómicas y revisables. Cada tarea debe ser suficientemente acotada para que el agente la ejecute con precisión y la persona pueda revisarla con criterio.

Implement — El agente ejecuta las tareas usando la especificación y el plan como guardrails. Aquí está el detalle crítico: hay un checkpoint humano en cada paso. No se genera todo de una tacada y se revisa al final. Se revisa en cada tarea, mientras el contexto aún es manejable.

Ese checkpoint no es un trámite burocrático. Es el mecanismo que evita que el agente construya kilómetros de código en la dirección equivocada. La diferencia entre revisar cada tarea y revisar al final puede ser la diferencia entre corregir un párrafo y reescribir el capítulo.

Las herramientas que lo hacen viable #

No existe una plataforma única de SDD. Hay un ecosistema de piezas que se combinan según el contexto.

GitHub Copilot y Spec Kit #

GitHub Copilot actúa como capa de ejecución. Spec Kit es el marco que organiza el proceso en los cuatro comandos: /specify, /plan, /tasks, /implement. La especificación resultante se convierte en el artefacto central que orienta al agente en cada fase.

Como describe el GitHub Blog: “instead of reviewing thousand-line code dumps, you review focused changes that solve specific problems. The coding agent knows what it’s supposed to build because the specification told it. It knows how to build it because the plan told it.”

Azure Verified Modules (AVM) #

Microsoft plantea AVM como base de conocimiento validada para infraestructura Azure. La idea no es solo reutilizar módulos; es capturar buenas prácticas, seguridad y patrones de arquitectura en artefactos estándar que luego la IA puede consumir para generar infraestructura conforme. Donde mejor se ve el enfoque SDD hoy es precisamente en IaC: Bicep y Terraform tienden a ser artefactos generados desde especificaciones de más alto nivel, no el primer lugar donde se codifica la intención.

Especificaciones versionadas #

El punto de partida real es tener especificaciones en formato reutilizable y verificable: requisitos, constraints, decisiones de arquitectura, contratos de API, reglas de naming, seguridad, observabilidad. Sin eso, no hay SDD. Solo prompts largos con contexto informal.

Validación continua #

Generar no es suficiente. También hay que comprobar que el resultado sigue cumpliendo la especificación: tests, contract tests, validaciones de esquema, checks de compliance, revisiones automatizadas. La spec solo funciona como fuente de verdad si se verifica con frecuencia. Es lo mismo que apuntaba Specification by Example según Wikipedia: una fuente única de verdad que, cuando se valida con frecuencia, puede convertirse en documentación viva.

Cuándo merece la pena la inversión inicial #

SDD requiere trabajo al principio. Escribir una buena spec lleva tiempo y en proyectos con requisitos borrosos o cambiantes puede resultar frustrante. Hay que ser honesto al respecto.

Dicho eso, el GitHub Blog documenta tres escenarios donde ese coste inicial se recupera con creces:

Proyectos desde cero: una pequeña inversión en especificación antes de empezar evita que el agente construya una solución genérica basada en patrones comunes que no encajan con las restricciones reales. Sin spec, la IA hace lo que cree que probablemente quieres. Con spec, hace lo que le dijiste que querías.

Trabajo incremental sobre sistemas existentes: la especificación fuerza claridad sobre cómo debe encajar la nueva funcionalidad con la arquitectura actual. Sin esa claridad, el agente tiende a resolver el problema de forma aislada y a crear inconsistencias.

Modernización de código legado: permite capturar la lógica de negocio esencial y reconstruir sin arrastrar deuda técnica accidental. La spec documenta el qué, no el cómo, lo que da libertad para reimplementar limpio.

El patrón común en los tres casos es el mismo: cuanto más clara sea la intención antes de pedir implementación, más útil y revisable es el resultado.

Lo que SDD no resuelve solo #

Hay una trampa fácil: creer que con una buena spec el agente ya funciona en piloto automático.

No funciona así.

SDD gobierna la intención. Pero el agente también necesita contexto operativo: saber qué archivos son relevantes, qué convenciones usa el equipo, qué ejemplos representan el patrón correcto. Una spec impecable sobre un repositorio con convenciones implícitas y sin ejemplos representativos no garantiza buen resultado. El problema, en ese caso, no está en la spec.

Eso tiene su propio nombre y su propia disciplina. Va en el siguiente artículo: Context Engineering: el término que realmente describe lo que estás haciendo.

Fuentes: Azure Verified Modules — SDD, Azure — AI-Assisted IaC Solution Development, GitHub Blog — Spec Kit, Wikipedia — Spec-driven development, Wikipedia — Specification by example, Martin Fowler — Specification By Example, Leigh Griffin & Ray Carroll — Spec Driven Development (InfoQ)