Los asistentes de IA codifican rápido. El problema es que no recuerdan nada, no preguntan suficiente y a veces resuelven el problema equivocado.
El Spec Driven Development (SDD) propone una solución simple: acordar qué se va a construir antes de construirlo. Nada más. Y nada menos.
- ¿Qué es el Spec Driven Development?
- Por qué funciona: 5 ventajas concretas
- Frameworks SDD más relevantes ahora mismo
- OpenSpec: el que mejor equilibra potencia y sencillez
- Conclusión
¿Qué es el Spec Driven Development?
La idea central es esta: antes de que el agente escriba una línea de código, humano y máquina se ponen de acuerdo sobre qué hay que hacer.
Ese acuerdo queda escrito en una especificación (spec): un documento que describe el cambio, los requisitos, el diseño técnico y las tareas concretas. La spec vive en el repositorio, junto al código. No en el chat.
¿Por qué importa tanto dónde vive? Porque los modelos de IA no tienen memoria entre sesiones. Cada vez que abres un chat nuevo, el agente empieza desde cero. Si los requisitos están solo en el historial de conversación, se pierden. Si están en una spec versionada, siempre están disponibles.
El «vibe coding» es rápido. El SDD es predecible. Con IA, necesitas las dos cosas.
Por qué funciona: 5 ventajas concretas
1. El agente siempre trabaja con el contexto correcto
La spec es la fuente de verdad. Da igual si abres una sesión nueva, cambias de herramienta o incorporas a alguien al equipo. El contexto está ahí, escrito, versionado y accesible.
2. Revisas antes de ejecutar
Cambiar una frase en un documento cuesta segundos. Refactorizar una implementación errónea puede costar horas. Con SDD, el momento de corrección llega antes de que el agente empiece a trabajar.
3. El output del agente es predecible
Sin spec, el mismo prompt puede generar resultados muy distintos en sesiones diferentes. Con spec, el agente siempre parte del mismo punto y trabaja dentro de los mismos criterios de aceptación.
4. La historia del proyecto se escribe sola
Cada cambio nace de una especificación. Eso significa que en cualquier momento puedes responder a la pregunta: ¿por qué existe esta funcionalidad? Sin excavar en commits. Sin reconstruir conversaciones perdidas.
5. Escala sin fricción
Funciona igual de bien para un desarrollador solo que para un equipo grande. La spec crea un lenguaje común que elimina malentendidos sin necesitar reuniones extra.
Frameworks SDD más relevantes ahora mismo
El ecosistema ha crecido rápido. Estos son los tres frameworks más citados hoy:
Spec Kit
El más veterano y el más completo. Flujo estructurado en fases, con comandos propios para cada etapa (/specify, análisis, diseño, implementación).
Lo bueno:
- Muy exhaustivo. Cubre todos los ángulos.
- Gran comunidad y documentación.
Lo menos bueno:
- Setup de 20-30 minutos. Requiere Python.
- Genera specs muy largas (800+ líneas para cambios moderados).
- Las fases son rígidas: poca flexibilidad para iterar sobre la marcha.
BMAD (Be My AI Developer)
Apuesta por un modelo multi-agente: un arquitecto, un analista, un desarrollador y un QA trabajando coordinados sobre la misma spec.
Lo bueno:
- Output de alta calidad en proyectos complejos.
- Separación real de responsabilidades entre roles.
Lo menos bueno:
- Curva de aprendizaje pronunciada.
- El overhead de coordinar múltiples agentes puede ser excesivo para proyectos pequeños.
Kiro (Amazon)
La opción integrada de Amazon. Genera specs automáticamente con requisitos, historias de usuario y criterios de aceptación. Experiencia pulida desde el primer minuto.
Lo bueno:
- Onboarding muy rápido.
- Integración nativa con el ecosistema AWS.
Lo menos bueno:
- Atado a su propio IDE.
- Limitado a modelos de Claude por defecto.
- Sin portabilidad real entre entornos.
OpenSpec: el que mejor equilibra potencia y sencillez
Mientras los demás frameworks añaden capas, OpenSpec va en dirección contraria: hace lo necesario y nada más.
Desarrollado por Fission AI, es open source, no requiere claves de API y se instala en menos de cinco minutos:
npm install -g openspecCompatible con más de 20 herramientas: Claude Code, Cursor, GitHub Copilot, Windsurf, Amazon Q, Cline, Continue… Sin lock-in. Sin dependencias de proveedor.
Cómo funciona
El repositorio tiene un directorio openspec/ con dos partes bien diferenciadas:
- Specs actuales: lo que el sistema hace hoy. La fuente de verdad.
- Cambios propuestos: cada feature o fix vive en su propia carpeta aislada hasta que se implementa y se fusiona.
Esta separación es la clave. Sabes exactamente qué está cambiando, puedes revisarlo antes de ejecutar y el historial de decisiones queda archivado de forma automática.
También incluye un archivo AGENTS.md —instrucciones específicas para los agentes de IA— que permite que cualquier herramienta siga el flujo correctamente, tenga o no integración nativa con OpenSpec.
El flujo de trabajo: 4 comandos
/opsx:new nombre-del-cambio— Crea la carpeta del cambio./opsx:ff— Genera la propuesta, los requisitos, el diseño técnico y las tareas. Aquí revisas y apruebas./opsx:apply— El agente implementa siguiendo la spec aprobada./opsx:archive— Cierra el ciclo: archiva el cambio y actualiza las specs actuales.
¿Qué lo diferencia del resto?
- Specs concisas: ~250 líneas donde otros generan 800+. Revisar es rápido y real.
- Sin fases rígidas: cualquier artefacto se puede modificar en cualquier momento.
- Pensado para proyectos existentes: la mayoría de herramientas asumen que partes de cero. OpenSpec está diseñado para evolucionar bases de código que ya existen.
- Sin lock-in: funciona con las herramientas que ya usas.
Conclusión
La IA codifica rápido. Demasiado rápido, a veces. Si no externalizas el pensamiento en especificaciones persistentes, esa velocidad se convierte en una trampa: más código, menos comprensión, más deuda técnica.
El SDD no es volver al pasado. Es una respuesta madura a cómo se desarrolla software hoy.
Y dentro del ecosistema actual, OpenSpec es el framework que mejor resuelve el equilibrio entre rigor y agilidad: suficiente estructura para que la IA sea predecible, suficiente ligereza para que el equipo lo adopte de verdad.
Las especificaciones son la memoria del proyecto. El código es solo su expresión más reciente.
¿Usas algún framework SDD en tu equipo? Cuéntanoslo en los comentarios.
