BMAD-METHOD: Agile con IA y seis agentes nombrados

Cada cierto tiempo aparece un proyecto open source que acumula estrellas a un ritmo que obliga a voltear. BMAD-METHOD es uno de esos: cuarenta y cinco mil estrellas, cinco mil forks, y una propuesta que no se parece a la mayoría de los frameworks de agentic coding que hemos revisado este año.

La mayoría intenta hacer “un agente que programe bien”. BMAD hace otra cosa: modela un equipo entero — analista de negocio, PM, arquitecto, diseñador UX, technical writer e ingeniero senior — y te da un flujo agile con fases, sprints y readiness checks. Es, literalmente, una consultora de software empaquetada como librería de npm.

Lo revisamos sin instalar nada, solo leyendo repo, wiki y ejemplos. Aquí van nuestras notas.

· bmad-code-org/BMAD-METHOD · MIT

Qué hace realmente

BMAD se autodescribe como Breakthrough Method for Agile AI Development. El nombre suena a marketing, pero la propuesta concreta es clara: dividir el ciclo de vida del software en cuatro fases — Analysis, Planning, Solutioning, Implementation — y asignar cada fase a agentes con personas definidas.

Los seis agentes tienen nombre propio, lo cual suena raro hasta que lo usas un rato:

• Mary, la analista de negocio, hace research de mercado y facilita brainstorming.
• Paige, la technical writer, se encarga de documentación y diagramas.
• John, el PM, escribe el PRD, arma los epics y corre readiness checks.
• Sally, la diseñadora UX, produce specs, wireframes y flujos.
• Winston, el arquitecto, define la arquitectura y valida alignment.
• Amelia, la ingeniera senior, ejecuta stories, revisa código y cierra sprints.

La lógica detrás es que al invocar a “John” en vez de a “un agente genérico”, el prompt carga una persona con contexto de rol ya cocinado: qué preguntar, qué documento producir, qué criterios de aceptación aplicar. Es prompt engineering disfrazado de organigrama, y para ser justos, funciona como mecanismo de claridad — sabes a quién llamar y qué esperar.

Encima de los agentes hay tres tracks adaptativos. Quick Flow para bug fixes y features pequeños, donde solo se genera una tech spec. BMad Method para productos y plataformas, con PRD, arquitectura y UX. Enterprise, que añade Security y DevOps y está pensado para multi-tenant y compliance.

Cómo funciona por dentro

El flujo es explícitamente agile. Una feature no empieza escribiendo código. Empieza con Mary haciendo research, John escribiendo el PRD, Winston validando arquitectura, y solo entonces Amelia entra a ejecutar stories en sprints con velocity tracking. Cada paso tiene artefactos que se pasan al siguiente agente como contexto.

La instalación es un one-liner:

npx bmad-method install

Eso deja tres capas de customización: una para reglas organizacionales, una para reglas de proyecto, y una para overrides locales. La idea es que una empresa inyecte sus estándares (convenciones de commits, políticas de seguridad, stack obligatorio) una sola vez y todos los agentes los respeten.

Donde BMAD brilla es en la legibilidad del output. Como cada agente produce artefactos definidos — PRD, arquitectura, specs, tech specs, stories — el resultado se parece a lo que vendería una consultora seria. Puedes mostrárselo a un cliente sin editarlo mucho. Y si alguna vez has peleado con un agente que salta directo a programar sin entender el problema, la fricción que BMAD introduce al principio te va a parecer bienvenida.

Donde pesa es en todo lo demás. El overhead de pasar por cuatro fases para agregar un botón es real. El track Quick Flow existe justamente para reconocer eso, pero incluso ahí hay más ceremonia que en un simple “modifica este archivo”.

Pros

• Separación de responsabilidades fuerte. No es el mismo agente tratando de ser estratega y ejecutor al mismo tiempo. Eso reduce el ruido de decisiones mezcladas.
• Artefactos reutilizables. El PRD, la arquitectura y las stories salen en un formato que sirve fuera del proyecto: onboarding, handoff, auditoría.
• Track Enterprise pensado. La inclusión explícita de compliance, security y DevOps como flujo separado es útil si de verdad trabajas en ese entorno.
• Customización en tres capas. Poder fijar reglas organizacionales una vez y que todos los agentes las hereden es un patrón sano.
• Comunidad activa. Cuarenta y cinco mil estrellas no significa calidad, pero sí significa que vas a encontrar issues respondidos, ejemplos y PRs.

Contras

• Seis agentes es mucho. Para equipos de uno o dos devs, cinco de esos agentes están modelando roles que nadie ocupa en la vida real. Terminas jugando al organigrama.
• Ceremonia sobre ejecución. Pasar por Analysis → Planning → Solutioning → Implementation para cada tarea agrega fricción que no siempre paga. El track Quick Flow ayuda, pero sigue siendo más proceso del que muchos proyectos necesitan.
• Curva de aprendizaje alta. Hay que entender qué hace cada persona, qué artefacto produce, cómo se encadenan y cómo personalizar cada capa antes de que el flujo se sienta natural.
• Orientación clara a empresa grande. El vocabulario — readiness checks, alignment checks, velocity — viene de entornos con PMs, arquitectos y QA dedicados. Si tu realidad es una persona haciendo tres roles, el framework te empuja a simular un equipo que no tienes.
• Prompt footprint grande. Tantos agentes y artefactos implican más tokens, más pasos, más contexto pasándose de lado a lado. En una tarea chica eso no se justifica.

Ninguno de estos puntos es un defecto de implementación. Son consecuencias directas del diseño: BMAD eligió modelar un equipo enterprise y lo hizo bien. El problema no es técnico; es de fit.

Cuándo sí, cuándo no

Sí tiene sentido si:

• Tu equipo es de cinco personas o más con roles reales (PM, arquitecto, devs).
• Trabajas en entornos con requisitos de compliance, auditoría o multi-tenant.
• Los artefactos intermedios (PRD, specs de arquitectura) son entregables que alguien va a leer y firmar, no papeleo desechable.
• Estás en una consultora y necesitas producir documentación de proyecto de forma reproducible.

No lo adoptaríamos si:

• Tu equipo son una o dos personas. Los seis agentes nombrados acaban siendo una sola persona jugando a ser seis.
• Tu stack es iterativo y experimental, donde el PRD de hoy es descartable mañana.
• Tu ratio de ceremonia/valor ya es alto y buscas reducirlo, no sumarlo.
• Trabajas en prototipos o features donde el costo de planear excede el costo de ejecutar.

La frontera que observamos, empíricamente, está alrededor de los cinco a diez devs. Por debajo de eso, el overhead de BMAD no paga. Por arriba, empieza a tener sentido porque los roles ya existen en tu organización y el framework solo los refleja.

Veredicto

BMAD-METHOD es un proyecto serio, bien ejecutado, con una visión coherente. No lo estamos descartando por mal hecho — al contrario, lo que hace lo hace con cuidado. Lo descartamos para nuestro contexto porque el contexto es otro: equipos chicos, iteración rápida, artefactos mínimos.

Lo que sí vamos a robarnos es la idea de los artefactos con plantilla y los tres layers de customización. No necesitamos seis agentes nombrados para eso; podemos definir dos o tres prompts con persona y dejar que nuestro flujo siga siendo directo. BMAD es excelente lectura para ver hasta dónde se puede llevar la metáfora del equipo agile traducida a agentes, aunque no lo adoptemos tal cual.

Si tu realidad se parece a una consultora, un banco o una empresa con compliance, vale la pena instalarlo y probarlo en serio. Si tu realidad se parece a tres personas construyendo un producto, probablemente ya tienes un flujo que funciona mejor — y que no requiere invocar a John, Mary y Winston para cambiar un color.

TL;DR — BMAD es una consultora enterprise empaquetada en npm: impresionante de diseño, excesiva para equipos de menos de cinco personas. Lee el repo, roba ideas, no instales a menos que tu organigrama ya tenga los roles que el framework asume.