Comparacion con otros Frameworks SDD

Existen varios frameworks de Spec-Driven Development. Cada uno tiene un enfoque diferente y resuelve problemas distintos.

Tabla comparativa

Aspecto	GSD	OpenSpec	BMAD	Spec-Kit
Filosofia	Context engineering	Brownfield iterativo	Equipo agil virtual	Specs formales
Complejidad	Oculta en el sistema	Minima (4 comandos)	Media (6 roles)	Media (5 fases)
Ideal para	Solo devs, greenfield	Codebases existentes	Greenfield complejo	Specs como contrato
Paralelismo	Waves automaticas	Manual	Manual	Manual
Verificacion	UAT automatizado	archive con validacion	QA virtual	Manual
Commits	Atomicos por tarea	Por change	Por feature	Manual
Herramientas	Claude, OpenCode, Gemini, Codex	Claude, Cursor, Copilot	Claude, Cursor	Claude, Cursor

GSD

Fortalezas:

• Context engineering elimina degradacion en sesiones largas
• Waves paralelas para ejecucion rapida
• Commits atomicos con verificacion integrada
• Investigacion automatica con 4 agentes paralelos

Debilidades:

• Mas opinionado — asume un workflow especifico
• No ideal para cambios triviales (usa quick mode)
• Requiere --dangerously-skip-permissions para mejor experiencia

Cuando usarlo: proyectos nuevos donde quieres estructura sin burocracia, especialmente como desarrollador individual.

OpenSpec

Fortalezas:

• 4 comandos (propose, explore, apply, archive) — minima curva de aprendizaje
• Brownfield-first: disenado para modificar codigo existente
• Delta specs evitan reescribir especificaciones completas
• ~12 minutos por cambio segun benchmarks

Debilidades:

• Sin paralelismo automatico
• Verificacion basica en perfil Core
• Menos estructura para proyectos grandes desde cero

Cuando usarlo: codebases existentes donde necesitas agregar features iterativamente.

BMAD Method

Fortalezas:

• Simula equipo agil completo (Analyst, PM, Architect, Scrum Master, Dev, QA)
• Bueno para discovery cuando hay muchas incognitas
• Cada rol aporta perspectiva diferente
• Exhaustivo para proyectos complejos

Debilidades:

• Mas lento (~5.5 horas por cambio segun benchmarks)
• Puede ser excesivo para proyectos pequenos
• Muchos artefactos generados

Cuando usarlo: proyectos greenfield complejos con multiples dominios y muchas incognitas.

GitHub Spec-Kit

Fortalezas:

• Toolkit oficial de GitHub
• Specs formales con constitution y requirements
• Bueno para equipos que necesitan documentacion rigurosa
• Integracion natural con GitHub

Debilidades:

• Mas artefactos que OpenSpec (~800 lineas vs ~250)
• Mas pasos manuales
• Menos automatizacion

Cuando usarlo: equipos que necesitan specs formales como contrato entre stakeholders.

Arbol de decision

¿Tienes codebase existente?
├── Si → ¿Cambios pequenos y frecuentes?
│        ├── Si → OpenSpec
│        └── No → GSD (con map-codebase)
└── No → ¿Proyecto complejo con muchas incognitas?
         ├── Si → BMAD
         └── No → ¿Necesitas specs como contrato?
                  ├── Si → Spec-Kit
                  └── No → GSD

Combinar frameworks

No son mutuamente excluyentes:

• BMAD para discovery + OpenSpec para iteracion: usa BMAD para la fase inicial de analisis y arquitectura, luego migra a OpenSpec para cambios iterativos
• GSD para desarrollo + Spec-Kit para documentacion: usa GSD para implementar rapido y Spec-Kit para documentar formalmente despues

Resumen

• GSD: context engineering + paralelismo para solo devs que quieren resultados sin burocracia
• OpenSpec: minimalista, brownfield-first, ~12 min por cambio
• BMAD: equipo agil virtual, exhaustivo, ideal para greenfield complejo
• Spec-Kit: specs formales de GitHub, ideal como contrato entre stakeholders
• No son mutuamente excluyentes — puedes combinarlos segun la fase del proyecto

---

← Brownfield y Gestion de Fases | Indice