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.
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
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
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.
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).