Qué es Spec-Driven Development (SDD) y cómo se aplica
Spec-Driven Development (SDD) es un enfoque de desarrollo de software en el que una especificación estructurada y versionada actúa como fuente de verdad para planificar, implementar y validar el código, especialmente cuando trabaja con agentes de IA. En lugar de pedirle a un agente que escriba código desde un prompt conversacional, primero se acuerda qué hay que construir, bajo qué restricciones y cómo se demostrará que funciona; después el agente implementa contra esa spec.
¿Qué es Spec-Driven Development?
Significa escribir una especificación estructurada antes de que un agente construya, de modo que construya lo correcto en lugar de una suposición plausible. La spec define:
- Qué debe hacer el sistema: requisitos y criterios de aceptación.
- Bajo qué restricciones: arquitectura, seguridad, convenciones.
- Qué no debe hacer: límites y casos fuera de alcance.
La diferencia clave con la documentación tradicional es que en SDD la especificación es un artefacto activo y versionado: viaja con el código en cada pull request y se usa para revisar el resultado, no es un documento que se escribe una vez y se abandona.
Por qué SDD importa en la era de la IA generativa
Con agentes de codificación capaces de generar mucho código en poco tiempo, la calidad de la especificación determina directamente la calidad del resultado. SDD responde a problemas habituales:
- «La IA escribió código, pero terminó siendo algo diferente de lo que esperaba».
- «Empezó bien, pero al añadir más funcionalidades el resultado se fue desviando».
- Prompts vagos que llevan a implementaciones ambiguas o incompletas.
El cierre de esa brecha consiste en poner la especificación como artefacto principal alrededor del cual el equipo construye, revisa y versiona; el código pasa a ser el output que se produce a partir de esa spec.
Flujo de trabajo: spec → plan → tasks → implement
El ciclo central de SDD tiene puntos de revisión humanos entre fases. Cada fase produce un artefacto concreto:
| Fase | Qué se hace | Output | Checkpoint humano |
|---|---|---|---|
| 0. Constitución (opcional) | Principios no negociables: arquitectura, testing, seguridad | Archivo de constitución versionado | Aprobación antes de Specify |
| 1. Specify | Requisitos, criterios de aceptación y restricciones sin ambigüedad | Spec gobernada (SPEC.md, PRODUCT.md) | Revisión de criterios antes de planificar |
| 2. Plan | Mapear la spec sobre el codebase y stack reales | Plan de arquitectura y dependencias | Corrección del plan antes de generar tareas |
| 3. Tasks | Dividir el plan en unidades discretas y ordenadas | Lista de tareas con dependencias explícitas | Revisión del desglose antes de implementar |
| 4. Implement | El agente ejecuta cada tarea contra la spec | Código trazable a un artefacto gobernado | Verificación del output por tarea |
La ventaja de este flujo es que el código queda trazable a un artefacto gobernado, no a una sesión de chat suelta.
SDD vs TDD, BDD y vibe coding
SDD vs TDD (Test-Driven Development)
| Aspecto | SDD | TDD |
|---|---|---|
| Punto de partida | Resultado deseado del sistema | Test automatizado que falla |
| Alcance | Funcionalidad y sistema | Comportamiento pequeño o unidad |
| Valor principal | Alineación y trazabilidad | Feedback de diseño y protección contra regresiones |
SDD define qué importa y por qué; TDD convierte el comportamiento seleccionado en feedback ejecutable a nivel de código. Usados juntos, conectan la intención con evidencia en el código.
SDD vs BDD (Behavior-Driven Development)
SDD cubre especificación amplia: requisitos, arquitectura, modelos de datos, restricciones de seguridad y criterios de aceptación en un documento gobernado. BDD se centra en ejemplos de comportamiento (escenarios Given-When-Then). SDD es más amplio y estructural; BDD es más específico en comportamientos observables.
SDD vs vibe coding
| SDD | Vibe coding | |
|---|---|---|
| Restricciones | Explícitas, en una spec versionada | Implícitas, en la conversación |
| Revisión | Formal, contra criterios de aceptación | Poca o ninguna |
| Trazabilidad | Cada cambio se conecta a la spec | Difícil de reconstruir |
| Cuándo conviene | Producción, proyectos críticos | Prototipos y experimentación |
Si quieres profundizar en el enfoque conversacional, ver qué es el vibe coding.
Herramientas y marcos SDD en 2026
Varias herramientas están adoptando o promoviendo SDD como patrón central para trabajar con agentes de IA:
- GitHub Spec Kit: marco de trabajo que describe SDD como hacer las especificaciones ejecutables, con intención definida antes del «cómo», refinamiento en múltiples pasos y guardarraíles explícitos.
- AWS Kiro: IDE con agentes que integra flujos tipo SDD para desarrollo asistido por IA.
- Claude Code: agente de terminal que se beneficia de specs claras para evitar «falsos verdes» y entregas poco fiables.
- Cursor / Windsurf: editores AI-native donde se puede seguir el flujo spec → plan → tasks → implement con agentes multiarchivo (ver comparativa de IA para programar).
- Superpowers: marco open source que impone desarrollo orientado a especificaciones, del brainstorming al TDD, en Claude Code y otros agentes.
- Tessl, Conductor y OpenSpec: herramientas emergentes que tratan la spec como artefacto central versionado.
Buenas prácticas para aplicar SDD
- Empieza pequeño: elige una funcionalidad real pero acotada para probar el flujo.
- Escribe la spec corta primero: requisitos, criterios de aceptación, modelos de datos, contratos de API y límites.
- Pide el plan, no el código: si el plan no tiene sentido, la spec estaba mal; detectarlo ahí cuesta minutos, no días.
- Versiona la spec: guárdala en el repositorio (
SPEC.md,PRODUCT.md,TECH.md) y mantenla actualizada conforme evoluciona la implementación. - Valida contra los criterios iniciales: revisa el resultado comparándolo con los criterios escritos al principio, no solo con el diff del código.
Cuándo usar SDD
SDD aporta más valor cuando:
- Trabajas con agentes de IA que generan código de forma autónoma.
- Necesitas trazabilidad entre requisitos e implementación.
- El equipo incluye personas no técnicas que deben validar qué se construye.
- Quieres reducir el riesgo de desviaciones y deuda técnica en proyectos críticos.
Para experimentación rápida o prototipos muy tempranos, enfoques más ligeros como el vibe coding pueden ser suficientes. SDD aporta control y previsibilidad cuando el coste del error es alto.
Fuentes
- Guías y análisis 2026: Atlassian, SAM Solutions, Escribano.dev, Minitap, Transformación Digital PE, ShakersWorks, Hasina Razafintsalama, VibeCoding.app, Glukhov, Zyvop, TechRadar y Verdent.ai
- Marco de referencia: GitHub Spec Kit
En IA2Net aplicamos especificación, revisión humana y controles en cada desarrollo con IA. Explora nuestros servicios de IA o cuéntanos tu caso.
Preguntas frecuentes
¿SDD sustituye a TDD?
No. Son complementarios: la spec define qué construir y por qué; los tests garantizan que el comportamiento acordado se cumple. En la práctica, SDD termina generando los criterios que luego se automatizan como tests.
¿SDD solo sirve para trabajar con IA?
No, aunque sea donde más se nota. Especificar antes de construir, versionar esa especificación y validar contra ella son prácticas valiosas en cualquier equipo, con o sin agentes.
¿Necesito una herramienta concreta para SDD?
No. El flujo funciona con archivos Markdown versionados en el repositorio. Herramientas como Spec Kit, Kiro o los agentes de Cursor y Claude Code lo automatizan, pero el principio es independiente de la herramienta.
¿Cuándo NO conviene SDD?
En exploración temprana, spikes y prototipos desechables, donde el objetivo es aprender rápido y el coste de escribir una spec supera el valor de la información obtenida. En cuanto el prototipo se convierte en producto, conviene especificar.