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 código, lo revisan, lo ajustan, lo integran. Funciona... a veces. Otras veces el código generado no entiende el contexto, ignora la arquitectura existente, o resuelve un problema diferente al planteado. El problema no es la IA. Es cómo la estás usando.
Spec-Driven Development (SDD) es una metodología emergente que ya aparece en el Technology Radar 2025. No es otra herramienta de IA. Es un cambio fundamental en cómo los equipos de desarrollo interactúan con agentes de IA para escribir código. Si llegas aquí desde fuera del contexto agéntico, antes conviene revisar qué es agentic AI y cómo está transformando el desarrollo de software.
El problema: prompts ad hoc = resultados impredecibles
La mayoría de equipos usa IA para programar de esta manera:
- Developer tiene una tarea
- Escribe un prompt describiendo lo que necesita
- IA genera código
- 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 típicas:
- Scope creep: la IA resuelve más (o menos) de lo pedido
- Falta de contexto: código que no respeta la arquitectura existente
- "Caja negra": difícil entender por qué la IA generó lo que generó
- 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.
Qué es Spec-Driven Development
Spec-Driven Development invierte el flujo. En lugar de escribir prompts ad hoc, empiezas con una especificación estructurada que guía todo el proceso de generación de código.
La idea central: una especificación funcional detallada actúa como "North Star" para los agentes de IA, en lugar de depender de prompts improvisados.
El workflow de SDD
1. ESPECIFICACIÓN
- Documento estructurado con requisitos, intenciones, restricciones
- Actúa como "fuente de verdad" para el proyecto
- Versionado junto con el código
2. DESCOMPOSICIÓN
- La especificación se desglosa en tareas más pequeñas
- Cada tarea es manejable por un agente de IA
3. GENERACIÓN
- Agentes de IA generan código basado en la especificación
- El contexto viene del documento, no del prompt instantáneo
4. REVISIÓN HUMANA
- Developers revisan en cada paso
- Ajustes se documentan para mejorar el sistema
5. ITERACIÓN
- Feedback se incorpora a la especificación
- 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 especificación estructurada actúa como contrato entre etapas y limita esa propagación.
Por qué 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 especificación bien pensada que ha sido revisada por el equipo.
Resultado: Menos sorpresas. Código más consistente. Menos "¿qué hacía este código?" tres meses después.
2. Colaboración estructurada
La especificación se convierte en un documento versionado que el equipo puede revisar, discutir y mejorar. Es la fuente de verdad del proyecto.
Resultado: Mejor comunicación 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 especificación, no del historial de chat que se pierde entre sesiones.
Resultado: Código que respeta la arquitectura existente. Menos refactoring posterior.
4. Trazabilidad completa
Cada línea de código generada puede trazarse a un requisito específico. Cuando algo falla, sabes exactamente dónde buscar.
Resultado: Debugging más rápido. Mantenimiento más 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
Guía a usuarios a través de tres fases: requisitos, diseño y creación de tareas. Enfoque estructurado pero tradicional.
2. GitHub spec-kit
Proceso de tres pasos con orquestación más rica. Incluye prompts configurables y una "constitución" que define principios inmutables del proyecto.
Insight clave: La "constitución" es revolucionaria. Define reglas que la IA nunca puede violar: patrones de arquitectura, convenciones de naming, dependencias prohibidas. Esto resuelve el problema de "la IA ignora nuestros estándares".
3. Tessl Framework
El enfoque más radical: la especificación misma se convierte en el artefacto mantenido, no el código. El código es un derivado de la especificación.
Cómo implementamos SDD en onext
En onext, SDD es la base de nuestro método de AI-Accelerated Development. No es teoría: es cómo trabajamos con equipos de desarrollo, en un Quick-start de 4–8 semanas. Si antes de mover nada quieres saber qué tendrías que tener listo, puedes repasar el checklist que usamos la primera semana.
Nuestro flujo probado
Fase 1: Documentación de especificación (Semana 1)
- Auditoría del proyecto: Entendemos arquitectura, patrones, convenciones
- Creación de "constitución": Reglas inmutables que la IA debe respetar
- Template de especificación: Formato estándar para nuevas features
Fase 2: Integración con herramientas (Semana 2)
- Configuración de agentes: Claude Code, Copilot o similar con contexto del proyecto
- Playbook de prompts: Templates probados para tareas comunes
- Flujo de code review: Checklist específico para código generado por IA
Fase 3: Adopción del equipo (Semana 3-4)
- Workshop práctico: El equipo aprende escribiendo especificaciones reales
- Pair programming: Developers experimentados guían a juniors
- Métricas de seguimiento: Tiempo ahorrado, calidad del código, consistencia
Fase 4: Optimización continua (Semana 5-6)
- Refinamiento de especificaciones: Aprendemos de lo que funciona y lo que no
- Expansión de casos de uso: Aplicamos SDD a más tipos de tareas
- Autonomía del equipo: El equipo mantiene y mejora el sistema sin nosotros
Ejemplo: cómo cambia el trabajo de un equipo con SDD
Ejemplo ilustrativo, sin cifras: un equipo de desarrollo de un SaaS B2B que usa IA para programar, pero cada persona a su manera.
Antes (sin SDD)
- Cada developer usaba Copilot "a su manera"
- El código generado ignoraba las convenciones del proyecto
- Buena parte del tiempo se iba en ajustar código generado
- Tres developers resolvían el mismo problema de tres formas
Después (con SDD)
- Especificación compartida con los patrones del proyecto
- "Constitución" que define arquitectura y convenciones
- Plantillas de especificación para features, bugs y refactoring
- Código generado consistente entre developers
Un matiz importante: cautela constructiva
El Technology Radar clasifica SDD en categoría "Assess" (explorar con cautela). La evaluación es realista:
"Aunque el espacio resulta fascinante, los flujos de trabajo permanecen elaborados y opinados. Las herramientas generan especificaciones extensas difíciles de revisar."
Nuestra interpretación: Las herramientas genéricas de SDD pueden ser complejas. Pero cuando la metodología se adapta a tu contexto específico (tu arquitectura, tu equipo, tus convenciones), los beneficios superan la curva de aprendizaje.
Por eso en onext no vendemos una herramienta. Implementamos la metodología adaptada a tu equipo.
Y cuando el código lo escribe un agente, la especificación es además el punto donde alguien firma lo que se va a construir. Lo desarrollamos en Specs y agentes: la especificación es donde se firma.
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 líneas describiendo:
- Que problema resuelve esto
- Qué restricciones tiene
- Cómo debería integrarse con el código existente
2. Define tu "constitución"
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 especificación
Un template simple para nuevas features:
## Feature: [Nombre]
### Problema
[Qué problema del usuario resuelve]
### Solución
[Cómo lo resolvemos a alto nivel]
### Restricciones
- [Arquitectura a respetar]
- [Patrones a usar]
- [Lo que NO debe hacer]
### Criterios de aceptación
- [ ] [Criterio 1]
- [ ] [Criterio 2]
### Integración
[Cómo se integra con código existente]
4. Revisa con la especificación en mano
En code review, no solo revises el código. Revisa si el código cumple la especificación. Si no hay especificación, ese es el primer problema.
Conclusión: De "usar IA" a "integrar IA"
Spec-Driven Development no es una herramienta más. 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 código. Escriben mejor código, más rápido, con más consistencia. Y lo más importante: el código generado es mantenible a largo plazo.
La pregunta no es si tu equipo usará IA para programar. La pregunta es si la usará 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.
Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y una persona que decide donde hay riesgo— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →