Spec-Driven Development (SDD) es una metodología de desarrollo de software con IA que sustituye los prompts ad hoc por una especificación estructurada que guía al agente durante toda la generación de código. Aparece en el Technology Radar 2025 como técnica emergente.
SDD existe porque los equipos que usan GitHub Copilot, Claude Code o Cursor sin método obtienen resultados inconsistentes: el mismo problema se resuelve de tres formas diferentes por tres developers distintos. La especificación elimina la variabilidad.
Tu equipo usa GitHub Copilot o Claude Code. Escriben un prompt, obtienen codigo, lo revisan, lo ajustan, lo integran. Funciona... a veces. Otras veces el codigo generado no entiende el contexto, ignora la arquitectura existente, o resuelve un problema diferente al planteado. El problema no es la IA. Es como la estas usando.
Spec-Driven Development (SDD) es una metodologia emergente que ya aparece en el Technology Radar 2025. No es otra herramienta de IA. Es un cambio fundamental en como los equipos de desarrollo interactuan con agentes de IA para escribir codigo. Si llegas aqui desde fuera del contexto agentico, antes conviene revisar qué es agentic AI y cómo está transformando el desarrollo de software.
El problema: prompts ad hoc = resultados impredecibles
La mayoria de equipos usa IA para programar de esta manera:
- Developer tiene una tarea
- Escribe un prompt describiendo lo que necesita
- IA genera codigo
- Developer revisa, ajusta, integra
- Repetir para la siguiente tarea
Problema: Cada prompt es independiente. No hay contexto compartido. No hay "memoria" del proyecto. El resultado depende de la habilidad del developer para escribir buenos prompts.
Consecuencias tipicas:
- Scope creep: la IA resuelve mas (o menos) de lo pedido
- Falta de contexto: codigo que no respeta la arquitectura existente
- "Caja negra": dificil entender por que la IA genero lo que genero
- Inconsistencia: el mismo problema resuelto de 3 formas diferentes por 3 developers
En la práctica, el gap de calidad y monitoring que aparece cuando los agentes IA llegan a producción es donde la mayoría de proyectos se rompen. SDD existe precisamente para cerrarlo desde la fase de diseño.
Que es Spec-Driven Development
Spec-Driven Development invierte el flujo. En lugar de escribir prompts ad hoc, empiezas con una especificacion estructurada que guia todo el proceso de generacion de codigo.
La idea central: una especificacion funcional detallada actua como "North Star" para los agentes de IA, en lugar de depender de prompts improvisados.
El workflow de SDD
1. ESPECIFICACION
- Documento estructurado con requisitos, intenciones, restricciones
- Actua como "fuente de verdad" para el proyecto
- Versionado junto con el codigo
2. DESCOMPOSICION
- La especificacion se desglosa en tareas mas pequenas
- Cada tarea es manejable por un agente de IA
3. GENERACION
- Agentes de IA generan codigo basado en la especificacion
- El contexto viene del documento, no del prompt instantaneo
4. REVISION HUMANA
- Developers revisan en cada paso
- Ajustes se documentan para mejorar el sistema
5. ITERACION
- Feedback se incorpora a la especificacion
- Se construye una base de conocimiento con el tiempo
Este pipeline se vuelve crítico en workflows multi-etapa con agentes IA donde un fallo en el paso N propaga a N+1 y N+2 hasta amplificarse en el resultado final. La especificacion estructurada actua como contrato entre etapas y limita esa propagacion.
Por que SDD es diferente (y mejor)
1. Control y predictibilidad
Con prompts ad hoc, el resultado depende de la calidad del prompt en ese momento. Con SDD, el resultado depende de una especificacion bien pensada que ha sido revisada por el equipo.
Resultado: Menos sorpresas. Codigo mas consistente. Menos "que hacia este codigo?" tres meses despues.
2. Colaboracion estructurada
La especificacion se convierte en un documento versionado que el equipo puede revisar, discutir y mejorar. Es la fuente de verdad del proyecto.
Resultado: Mejor comunicacion entre producto, desarrollo y QA. Todos hablan el mismo idioma.
3. Supera limitaciones de la IA
Los agentes de IA tienen contexto limitado. Con SDD, ese contexto viene de la especificacion, no del historial de chat que se pierde entre sesiones.
Resultado: Codigo que respeta la arquitectura existente. Menos refactoring posterior.
4. Trazabilidad completa
Cada linea de codigo generada puede trazarse a un requisito especifico. Cuando algo falla, sabes exactamente donde buscar.
Resultado: Debugging mas rapido. Mantenimiento mas simple.
Para sectores regulados (banca, salud, administración), el diseño compliance-first para agentes con trazabilidad de auditoría deja de ser opcional — es la diferencia entre una arquitectura que pasa auditoría EU AI Act y una que no.
3 herramientas que implementan SDD
Actualmente hay tres aproximaciones principales a SDD, cada una con un enfoque diferente:
1. Amazon Kiro
Guia a usuarios a traves de tres fases: requisitos, diseno y creacion de tareas. Enfoque estructurado pero tradicional.
2. GitHub spec-kit
Proceso de tres pasos con orquestacion mas rica. Incluye prompts configurables y una "constitucion" que define principios inmutables del proyecto.
3. Tessl Framework
El enfoque mas radical: la especificacion misma se convierte en el artefacto mantenido, no el codigo. El codigo es un derivado de la especificacion.
Como implementamos SDD en onext
En onext, SDD es la base de nuestros Centros de Excelencia de IA. No es teoria: es como transformamos equipos de desarrollo en 4-6 semanas.
Nuestro flujo probado
Fase 1: Documentacion de especificacion (Semana 1)
- Auditoria del proyecto: Entendemos arquitectura, patrones, convenciones
- Creacion de "constitucion": Reglas inmutables que la IA debe respetar
- Template de especificacion: Formato estandar para nuevas features
Fase 2: Integracion con herramientas (Semana 2)
- Configuracion de agentes: Claude Code, Copilot o similar con contexto del proyecto
- Playbook de prompts: Templates probados para tareas comunes
- Flujo de code review: Checklist especifico para codigo generado por IA
Fase 3: Adopcion del equipo (Semana 3-4)
- Workshop practico: El equipo aprende escribiendo especificaciones reales
- Pair programming: Developers experimentados guian a juniors
- Metricas de seguimiento: Tiempo ahorrado, calidad del codigo, consistencia
Fase 4: Optimizacion continua (Semana 5-6)
- Refinamiento de especificaciones: Aprendemos de lo que funciona y lo que no
- Expansion de casos de uso: Aplicamos SDD a mas tipos de tareas
- Autonomia del equipo: El equipo mantiene y mejora el sistema sin nosotros
Caso real: De 2 horas por feature a 30 minutos
Cliente: SaaS B2B Serie A, 8 developers
Problema: Codigo generado por IA inconsistente, mucho tiempo en refactoring
Before (sin SDD)
- Cada developer usaba Copilot "a su manera"
- Codigo generado ignoraba convenciones del proyecto
- 60% del tiempo en ajustar codigo generado
- 3 developers hacian el mismo problema de 3 formas
After (con SDD)
- Especificacion compartida con patrones del proyecto
- "Constitucion" que define arquitectura y convenciones
- Templates de spec para features, bugs, refactoring
- Codigo generado consistente entre developers
Resultados (6 semanas):
- Tiempo por feature: 2h -> 30min (-75%)
- Tiempo en refactoring: 60% -> 15% (-75%)
- Consistencia de codigo: Medida por linter, +40% menos warnings
- Satisfaccion del equipo: 3.2/5 -> 4.6/5
"Ahora el codigo generado parece escrito por nosotros, no por un bot generico"
Un matiz importante: cautela constructiva
El Technology Radar clasifica SDD en categoria "Assess" (explorar con cautela). La evaluacion es realista:
"Aunque el espacio resulta fascinante, los flujos de trabajo permanecen elaborados y opinados. Las herramientas generan especificaciones extensas dificiles de revisar."
Nuestra interpretacion: Las herramientas genericas de SDD pueden ser complejas. Pero cuando la metodologia se adapta a tu contexto especifico (tu arquitectura, tu equipo, tus convenciones), los beneficios superan la curva de aprendizaje.
Por eso en onext no vendemos una herramienta. Implementamos la metodologia adaptada a tu equipo.
Principios clave de SDD para empezar hoy
No necesitas herramientas complejas para empezar con SDD. Estos son los principios que puedes aplicar desde hoy:
1. Escribe antes de pedir
Antes de escribir un prompt, escribe 3-5 lineas describiendo:
- Que problema resuelve esto
- Que restricciones tiene
- Como deberia integrarse con el codigo existente
2. Define tu "constitucion"
Documenta las reglas inmutables de tu proyecto:
- Patrones de arquitectura que siempre usas
- Convenciones de naming
- Dependencias permitidas y prohibidas
- Estructura de carpetas
3. Crea templates de especificacion
Un template simple para nuevas features:
## Feature: [Nombre]
### Problema
[Que problema del usuario resuelve]
### Solucion
[Como lo resolvemos a alto nivel]
### Restricciones
- [Arquitectura a respetar]
- [Patrones a usar]
- [Lo que NO debe hacer]
### Criterios de aceptacion
- [ ] [Criterio 1]
- [ ] [Criterio 2]
### Integracion
[Como se integra con codigo existente]
4. Revisa con la especificacion en mano
En code review, no solo revises el codigo. Revisa si el codigo cumple la especificacion. Si no hay especificacion, ese es el primer problema.
Conclusion: De "usar IA" a "integrar IA"
Spec-Driven Development no es una herramienta mas. Es un cambio de mentalidad:
- De: "La IA es un autocomplete inteligente"
- A: "La IA es un agente que ejecuta especificaciones"
Los equipos que adoptan SDD no escriben menos codigo. Escriben mejor codigo, mas rapido, con mas consistencia. Y lo mas importante: el codigo generado es mantenible a largo plazo.
La pregunta no es si tu equipo usara IA para programar. La pregunta es si la usara de forma caos (prompts ad hoc) o de forma controlada (spec-driven).
Preguntas frecuentes sobre Spec-Driven Development
¿Qué es Spec-Driven Development (SDD)?
Spec-Driven Development es una metodología de desarrollo de software con IA que reemplaza los prompts ad hoc por una especificación estructurada que describe qué tiene que hacer el código, bajo qué arquitectura y con qué restricciones. El agente IA (Claude Code, Copilot, Cursor) genera el código contra esa especificación, no contra un prompt suelto. Resultado: mismo problema resuelto de la misma forma por developers distintos.
¿En qué se diferencia SDD de TDD o BDD?
TDD (Test-Driven Development) escribe primero los tests; BDD (Behavior-Driven Development) escribe primero el comportamiento esperado en lenguaje natural. SDD escribe primero la especificación funcional y arquitectónica completa que el agente IA va a usar para generar todo el código. TDD y BDD son disciplinas de personas escribiendo código; SDD es disciplina de personas dirigiendo agentes IA que escriben código.
¿Cómo se aplica SDD con Claude Code o GitHub Copilot?
La spec se materializa en un documento estructurado (Markdown o YAML) que el
agente lee como contexto antes de generar. En Claude Code se usa
CLAUDE.md o ficheros de spec dedicados; en Copilot se usa
.github/copilot-instructions.md; en Cursor se usan reglas de
proyecto. La spec describe contexto del producto, arquitectura, convenciones
de código, casos límite y criterios de aceptación.
¿SDD funciona con equipos que mantienen código legacy?
Sí, y precisamente ahí da más retorno. En código legacy la spec actúa como mapa: define la arquitectura real existente, los puntos de extensión seguros y las zonas que no se deben tocar. El agente IA deja de "inventar" porque la spec le da el contexto que el código legacy no documenta por sí mismo.
¿Cuándo NO conviene aplicar SDD?
Prototipos exploratorios donde el objetivo es descubrir qué construir, no construirlo bien. En esos casos la spec premature mata la velocidad. SDD encaja cuando ya hay producción, arquitectura definida y equipo multi-developer. Si trabajas solo en un MVP de 2 semanas, no lo necesitas.