BMAD Method, SDD y mi workflow de agentes: dónde coinciden y en qué se separan

Por /

Llevo varios meses usando un workflow propio con Claude Code: agentes especializados, git worktrees para aislamiento de contexto y MCPs que conectan con datos reales. Funciona. Lo he documentado en mi artículo sobre Archivo Final y también lo uso en este blog para gestionar el pipeline de generación de contenido SEO.

Hace unos días apareció en mi feed BMAD Method con más de 40.000 estrellas en GitHub. Framework open source para desarrollo de software con agentes IA, versión 6, con 12+ agentes especializados y 34+ workflows. El tipo de proyecto que, cuando lo ves con ese volumen de comunidad, te preguntas: ¿estoy reinventando la rueda? ¿Me estoy perdiendo algo importante?

Lo analicé en detalle. Y para analizarlo con rigor, necesité añadir un tercer eje al comparativo: SDD, el Spec-Driven Development, del que ya escribí en este blog. Porque resulta que tanto BMAD como mi workflow son implementaciones distintas de la misma filosofía. Entender eso cambia completamente cómo leer las diferencias.

SDD: la filosofía que subyace a todo

Antes de entrar en BMAD o en mi workflow, conviene nombrar el paradigma que los une.

El desarrollo dirigido por especificaciones (SDD) propone que la especificación —no el código— sea el artefacto central del proyecto. No una documentación posterior al hecho, sino un contrato vivo que se escribe antes de implementar, se actualiza con cada cambio y guía a los agentes de IA de forma inequívoca.

SDD resuelve directamente el problema del vibe-coding: el agente no infiere intención desde un prompt vago, sino que ejecuta contra una especificación explícita con contexto técnico, criterios de aceptación y definición de “done” clara.

El artículo que publiqué en diciembre define tres niveles de madurez:

Nivel Descripción
Spec-first La especificación se escribe antes del código. El agente la usa como prompt o contexto inicial.
Spec-anchored La especificación se mantiene viva y actualizada tras la implementación. Es referencia continua del proyecto.
Spec-as-source La especificación es el único artefacto que edita el humano. El código se genera completamente a partir de ella.

Y un ciclo de cuatro fases: Especificar → Planificar → Construir → Validar y revisar.

Tener esto claro es lo que permite comparar BMAD y mi workflow sin mezclar churras con merinas. Los dos son implementaciones de SDD. Las diferencias están en cómo materializan la especificación, qué artefactos producen y en qué nivel de madurez operan.

Qué es BMAD Method

Build More Architect Dreams es un framework de desarrollo ágil con IA que cubre el ciclo completo desde la idea hasta el deployment. Se instala como paquete npm en cualquier proyecto:

npx bmad-method install

Y funciona con Claude Code, Cursor, Windsurf o cualquier IDE con agentes. Una vez instalado, tienes disponibles 8 agentes especializados que puedes invocar directamente desde el chat.

Agente Rol
analyst Brainstorming, investigación, product brief
pm PRD, epics y stories
architect Decisiones técnicas, arquitectura del sistema
ux-designer Flujos de usuario, diseño de interfaz
dev Implementa las stories
qa Testing, E2E tests
sm (Scrum Master) Sprint planning, sprint tracking, retrospectivas
tech-writer Documentación técnica

El workflow es secuencial por fases:

Phase 1 — Analysis (opcional)
  └── Analyst → Project Brief

Phase 2 — Planning
  ├── PM → PRD.md
  └── UX Designer → UX design docs (opcional)

Phase 3 — Solutioning
  ├── Architect → architecture.md
  ├── PM + Architect → epics/ + stories/
  └── Architect → check-implementation-readiness

Phase 4 — Implementation (por sprint)
  ├── SM → sprint-status.yaml
  ├── Dev (por story) → código
  ├── Dev → code-review
  └── SM → retrospective (por epic)

Todos los artefactos van a _bmad-output/. Son la memoria persistente del proyecto: el siguiente agente los lee antes de trabajar, sin necesidad de repetir contexto.

En términos de SDD: BMAD es una implementación spec-anchored formal. El PRD es la especificación funcional. La arquitectura es la especificación técnica. Las stories son la descomposición implementable. El check-implementation-readiness valida la coherencia entre los tres antes de escribir una línea de código.

BMAD también adapta el nivel de rigor según la complejidad:
– Quick Flow (1-15 stories) — solo tech-spec, sin arquitectura formal
– BMad Method (10-50+ stories) — proceso completo
– Enterprise (30+ stories) — añade Security + DevOps planning

Mi workflow y la capa de especificación que me estaba perdiendo documentar

Antes de que ningún agente escriba una línea de código, el proceso arranca desde Claude Code con el comando /create-new-issue. El agente ejecuta:

  1. Exploración del codebase — Lee los módulos relevantes, entiende la arquitectura existente, identifica las dependencias y las restricciones reales del sistema.
  2. Redacción de la especificación — Genera un issue en GitHub con la estructura completa:
  3. Problem Statement — Qué problema existe y por qué importa
  4. Solution — Qué construir y con qué enfoque, incluyendo decisiones de diseño (blocking vs. non-blocking, feature flags, upgrade paths)
  5. Implementation — Especificación técnica detallada: modelos, campos, migraciones, servicios, endpoints, notificaciones. Con fragmentos de código cuando aplica.
  6. Definition of Done — Checklist con cada criterio verificable
  7. Manual Testing Checklist — Escenarios concretos para validar el comportamiento esperado

Una vez creado el issue, el flujo continúa:

  1. Implementación — El Developer agent lee el issue y lo implementa. La especificación está en GitHub, no en el contexto del chat.
  2. Pull Request — El PR referencia el issue. Cierra automáticamente al hacer merge.
  3. QA — Se valida contra los criterios de la Definition of Done y el Manual Testing Checklist del issue.

En términos de SDD: esto es spec-anchored en la práctica. El issue es el contrato vivo. Se versiona en GitHub, tiene historial de comentarios, se puede linkar desde el PR, y queda como registro permanente de por qué se tomó cada decisión de diseño.

El resto del workflow

Sobre los worktrees, los MCPs y los agentes, el artículo de Archivo Final ya tiene los detalles. El resumen:

  • Git worktrees — Aislamiento de contexto por rama. Permite lanzar agentes en paralelo sin que sus contextos interfieran.
  • 10 MCPs — Datos reales: Conext7, Google Search Console, GA4, Playwright (citación en motores generativos), GitHub, base de datos. Los agentes no trabajan con suposiciones.
  • Sesiones compartidas — .claude/sessions/{feature}.md como canal de comunicación entre agentes. Cada agente lee el documento completo antes de trabajar.

Comparativa a tres bandas: SDD puro, BMAD y mi workflow

Dimensión SDD (filosofía) BMAD Method Mi workflow
Nivel SDD Spec-anchored / Spec-as-source Spec-anchored formal Spec-anchored en GitHub Issues
Artefacto de especificación Documento estructurado libre PRD.md + architecture.md + stories GitHub Issues
Dónde vive la spec Repo (archivos) _bmad-output/ (archivos) GitHub (issues, traceable, público)
Quién genera la spec AI + humano iterativamente Agentes BMAD (PM, Architect) /create-new-issue + exploración del codebase
Granularidad Variable Story-level (criterios de aceptación) Issue-level (Definition of Done + Manual Testing)
Revisión pre-implementación Punto de validación explícito check-implementation-readiness Revisión manual del issue antes de implementar
Trazabilidad Según implementación PRD → Story → PR Issue → PR → Merge (automático en GitHub)
Datos externos No nativo No nativo MCPs: datos reales de GSC, GA4, Playwright
Ejecución paralela No define Secuencial por fases Worktrees → agentes simultáneos
Retrospectivas Implícitas en “Validar y revisar” SM agent → retrospective por epic No formalizadas
Portabilidad Alta (filosofía agnóstica) Alta (npx bmad-method install) Media (requiere configurar el workspace)

Los gaps reales — ahora con más precisión

Revisando la comparativa con la capa de SDD encima, los gaps quedan más nítidos:

Lo que BMAD tiene y mi workflow no

Arquitectura como artefacto explícito. El agente Architect de BMAD produce un architecture.md con las decisiones técnicas y sus justificaciones antes de implementar. En mi workflow, las decisiones arquitectónicas se toman en el issue o en la sesión de chat, pero no queda un documento formal de arquitectura consultable. Esto se nota en proyectos donde varias features interactúan con la misma capa de datos o servicio.

Validación cruzada de coherencia. El check-implementation-readiness revisa que PRD, arquitectura y stories sean coherentes entre sí antes de escribir código. En mi workflow, la coherencia entre el issue (spec) y el codebase existente depende de cuán bien hizo la exploración el agente al crear el issue. No hay un paso de validación formal.

Descomposición desde requisitos, no desde codebase. BMAD genera las stories desde el PRD y la arquitectura. Mis issues se generan desde la exploración del codebase. La diferencia: BMAD parte de “qué queremos conseguir”, yo parto de “qué existe y cómo encaja lo nuevo”. Para features bien definidas con requisitos claros, BMAD garantiza mayor alineación con los objetivos de negocio. Para features que evolucionan código existente, mi enfoque es más preciso técnicamente.

Retrospectivas formalizadas. El SM agent de BMAD documenta lecciones por epic. No tengo equivalente. El conocimiento se acumula en mi cabeza, no en el sistema.

Lo que mi workflow tiene y BMAD no cubre

Datos reales en el momento de especificar. Cuando el agente crea un issue, tiene acceso via MCPs al estado real de la base de datos, a los logs del sistema y al código existente. La spec se escribe con contexto de producción, no desde suposiciones. BMAD genera specs más formales pero potencialmente más desconectadas del estado real del sistema.

Trazabilidad pública en GitHub. Los issues son públicos, linkables, comentables. Hay historial de por qué se tomó cada decisión. Al hacer merge del PR que cierra el issue, la trazabilidad es automática. Esto también funciona como portfolio técnico: cualquiera puede ver cómo se está construyendo el producto.

Ejecución paralela real. Worktrees + agentes simultáneos en ramas independientes. BMAD es secuencial por diseño.

Dominio-específico para contenido. Para el pipeline de generación de contenido SEO de este blog, los agentes @seo-strategist, @marketing-copywriter y @wp-implementer hacen cosas que los agentes genéricos de BMAD no contemplan.

Tres niveles de madurez, tres herramientas distintas

Lo que me parece más útil del análisis no es “BMAD vs mi workflow” sino entender que son soluciones a distintos problemas de escala y naturaleza:

SDD como filosofía es el punto de partida. Si no estás especificando antes de implementar —de alguna forma— estás haciendo vibe-coding y pagando el coste en retrabajo.

Mi workflow con GitHub Issues resuelve bien el desarrollo iterativo de producto con contexto rico del codebase. La spec vive en GitHub, es trazable y el agente la genera con información real del sistema. Funciona especialmente bien cuando el “qué” está relativamente claro y el reto está en el “cómo” técnico.

BMAD resuelve mejor la fase de definición del producto cuando el “qué” todavía no está claro. Si estás arrancando un proyecto nuevo con ambigüedad en los requisitos, o si necesitas que varios stakeholders converjan en una especificación antes de que empiece la implementación, BMAD aporta una estructura que mi workflow no tiene.

La combinación que me parece más interesante para proyectos de producto nuevos: usar BMAD para la fase de planificación (PRD + arquitectura) y mi workflow de Issues + worktrees para la implementación sprint a sprint. Lo que queda pendiente como experimento en Archivo Final.

Recursos

Entradas relacionadas

Scroll al inicio