El Spec-Driven Development (SDD) ha pasado de concepto académico a trending topic. GitHub lanzó Spec Kit (72.000+ estrellas). AWS construyó un IDE entero — Kiro — alrededor de la idea. Thoughtworks lo ha añadido a su Technology Radar. Y cada semana aparece un framework nuevo que promete revolucionar cómo trabajamos con agentes de IA.
Pero aquí va la pregunta incómoda: ¿cuánto de esto necesitas realmente? Porque hay una diferencia enorme entre “escribir una spec antes de codear” y “montar un pipeline de 8 herramientas para validar un CRUD”.
Las herramientas SDD de 2026: el mapa completo
🏗️ IDEs y plataformas spec-first
Kiro (AWS/Amazon) — El que más ruido está haciendo. Un IDE completo que usa notación EARS (Easy Approach to Requirements Syntax) para estructurar specs en tres documentos: requisitos, diseño y tareas. Alimentado por Claude Sonnet de Anthropic. El agente no escribe una línea hasta que apruebas la spec. Tier gratis con 50 interacciones/mes, Pro a $19/mes.
Lo bueno: para features complejas, el paso de planificación reduce drásticamente el rework. Lo malo: solo usa modelos Claude, la spec se desincroniza después de 2 días de cambios iterativos, y las 50 interacciones gratis se evaporan rápidamente. Lo viral: un usuario consiguió que el código generado por Kiro provocara un incidente real en AWS. “Vibe too hard, brought down AWS” fue trending en Hacker News.
Intent (Augment Code) — La opción premium. A diferencia de todos los demás, sus specs son bidireccionales: se actualizan automáticamente cuando el agente modifica el código. Usa un Coordinator Agent que delega a agentes especializados (Implement, Verify, Critique, Debug). Desde $60/mes para equipos de hasta 20. Es el más potente, pero también el más caro.
🔧 Toolkits open source
GitHub Spec Kit — El toolkit oficial de GitHub para SDD. Open source, MIT license. Se instala vía uv tool install specify-cli y organiza tu proyecto con un directorio .specify y slash commands: /speckit.specify para documentar requisitos, luego genera tareas y el agente implementa. Compatible con Copilot, Claude Code, Gemini CLI y 5+ agentes más.
Lo bueno: agnóstico de agente, bien documentado, respaldado por GitHub. Lo malo: specs estáticas — si el código diverge, la reconciliación es manual.
OpenSpec (Fission AI) — Framework ligero para SDD. Open source, sin API keys ni MCP necesario. Compatible con 20+ herramientas. Su diferencia: usa delta markers que marcan qué partes de la spec han cambiado, semi-automatizando la sincronización. Ideal para proyectos brownfield donde iteras sobre código existente.
BMAD-METHOD — El más enterprise de los open source. Define 12+ roles de agentes especializados (architect, PM, QA, etc.) con un flujo docs-as-code pesado. Gratuito, pero requiere inversión de tiempo seria en configuración. Para equipos grandes con procesos formales.
⚙️ Frameworks y herramientas clásicas de API spec
El SDD tiene raíces en el contract-first development que lleva años madurando. Estas herramientas siguen siendo relevantes, especialmente para APIs:
Diseño de specs:
- OpenAPI 3.1 / AsyncAPI 3.0 / Protobuf — Los formatos estándar para definir contratos de API (REST, event-driven, gRPC respectivamente)
- Stoplight Studio — Editor visual de OpenAPI. Diseñas endpoints arrastrando, sin pelear con YAML
- Redocly — CLI + editor para equipos que prefieren ficheros y Git
Validación:
- Spectral — Linter para OpenAPI/AsyncAPI. Reglas configurables por equipo
Generación de código:
- OpenAPI Generator — Genera servidor y clientes en 50+ lenguajes desde un spec OpenAPI
- buf — Linting + generación para Protobuf/gRPC
Mock y testing:
- Prism — Mock server automático desde tu spec. El frontend trabaja sin esperar al backend
- Schemathesis — Fuzzing automático basado en el spec. Encuentra bugs que los tests manuales no pillan
- Dredd — Verifica que tu implementación cumple el contrato
- Pact — Contract testing entre consumidor y proveedor
Documentación automática:
- Redoc / Swagger UI — Docs HTML desde OpenAPI (estáticas o interactivas)
- Bump.sh — Docs hosted con changelog automático entre versiones
El debate: ¿Waterfall 2.0 o evolución necesaria?
La reacción instintiva de cualquier developer con experiencia es: “Escribir documentos exhaustivos antes de codear… ¿no probamos esto ya con Waterfall? ¿No fracasó estrepitosamente?”
La diferencia clave es quién ejecuta la spec. En Waterfall, escribías un documento de 200 páginas y luego un humano lo interpretaba (mal) durante 6 meses. En SDD, escribes una spec concisa y un agente de IA la implementa en minutos — literalmente. El feedback loop no es de meses, es de minutos.
Un estudio de METR encontró que developers usando IA sin estructura eran un 19% más lentos de media — a pesar de reportar mayor confianza. El problema: prompts imprecisos crean bucles de debug que consumen el tiempo ahorrado en generación. La spec rompe ese ciclo.
¿Cuándo es overengineering?
Aquí es donde la mayoría de artículos sobre SDD mienten por omisión. Te venden un pipeline de 8 herramientas sin preguntarte si lo necesitas. La realidad:
🧑💻 Dev solo o equipo de 2-3 personas
No necesitas herramientas. Un fichero markdown en tu repo con los requisitos, constraints y decisiones arquitectónicas es suficiente. Tu agente de IA (Claude Code, Copilot, el que sea) lo lee como contexto y produce código más alineado. Como dice un desarrollador: “No necesitas Spec Kit ni Kiro. Un fichero markdown y tu agente existente bastan. El valor está en el pensamiento que haces al escribir la spec, no en el tooling.”
Coste: 0€. Tiempo extra: 10-15 minutos por feature. ROI: enorme.
👥 Equipo de 4-10 personas
GitHub Spec Kit u OpenSpec. Necesitas algo de estructura para que las specs no deriven en cada persona haciéndolo a su manera. Spec Kit te da convenciones y slash commands. OpenSpec añade delta markers para proyectos existentes. Ambos gratis.
Opcional: Spectral para linting de API specs si tu producto es API-heavy. Prism para desbloquear al frontend.
🏢 Equipos de 10+ o proyectos regulados
Kiro, Intent o el pipeline completo. Aquí sí tiene sentido la artillería: specs formales con EARS notation, generación de código desde OpenAPI, contract testing con Schemathesis, docs automáticas, CI/CD que valida contratos en cada PR. La auditoría y trazabilidad justifican el overhead.
Kiro: el que todos están mirando
Merece párrafo aparte porque es el que más tracción tiene. Kiro genera tres documentos antes de escribir código: requirements.md (qué), design.md (cómo), y tasks.md (en qué orden). Incluye “hooks” — automatizaciones que se disparan al guardar ficheros, como ejecutar tests o linters automáticamente.
El problema real de Kiro: la spec se queda obsoleta. Después de 2 días de iteración, el design.md ya no refleja lo que el código hace realmente. Intent resuelve esto con specs bidireccionales, pero cuesta 3x más. Es el dilema clásico de la documentación: mantenerla sincronizada cuesta más que crearla.
Mi recomendación
Empieza por abajo. Un SPEC.md en tu repo con los requisitos de tu próxima feature. Dáselo a tu agente como contexto. Mide si el código sale mejor y con menos iteraciones. Si la respuesta es sí — y lo será —, entonces plantéate subir de nivel con Spec Kit o Kiro.
Lo que NO debes hacer: montar un pipeline enterprise de validación + generación + mocking + contract testing para un proyecto con 3 endpoints y un equipo de 2 personas. Eso no es ingeniería, es procrastinación disfrazada de rigor.
El valor del SDD no está en las herramientas. Está en pensar antes de codear. Que en 2026 necesitemos un framework para recordarnos eso dice bastante sobre el estado de la profesión.
Fuentes: GitHub Spec Kit, Kiro, OpenSpec, Augment Code – SDD Tools Comparison, Alex Cloudstar – SDD 2026, METR Developer Productivity Study