La mayoría de devs usa la IA como un buscador muy listo.
Le hacen una pregunta. Obtienen una respuesta. Le hacen otra. Y así durante horas,
dando vueltas al mismo problema sin llegar a ningún lado.
Eso no es construir con IA. Es improvisar con IA.
Y hay una diferencia enorme.
Qué es BMAD
BMAD son las siglas de Breakthrough Method for Agile AI-Driven Development.
No es un framework más. Es una forma distinta de pensar cómo trabajar con agentes.
La premisa es simple: un solo agente que hace de todo es como contratar a alguien
y pedirle que sea product manager, arquitecto, desarrollador y QA al mismo tiempo.
Nadie rinde bien así. Los modelos tampoco.
BMAD divide el trabajo entre agentes especializados, igual que un equipo real.
Los cuatro roles
| Rol | Responsabilidad |
|---|---|
| Business Analyst | Entiende el problema, captura requisitos, escribe historias de usuario |
| Product Manager | Define el producto, prioriza el backlog, toma decisiones de alcance |
| Architect | Diseña la arquitectura, elige el stack, define los contratos entre módulos |
| Developer | Implementa el código con todo el contexto ya resuelto |
Cada agente tiene su propio system prompt, su propio foco, sus propias responsabilidades.
No improvisa. Sabe exactamente para qué existe.
Un ejemplo real, paso a paso
Supón que quieres construir una app de seguimiento de hábitos.
Sin ningún método: abres el chat y escribes "hazme una app de hábitos con React".
La IA genera algo genérico. No era lo que tenías en mente. Ajustas el prompt.
Otras dos horas. Mismo resultado.
Con BMAD, el flujo es completamente distinto.
Paso 1 — El Business Analyst entra primero
No genera código. Hace preguntas.
Eres un Business Analyst experto. Tu trabajo es entender el problema
antes de que se escriba una sola línea de código.
Pregunta al usuario:
- ¿Qué problema concreto resuelve esta app?
- ¿Quién la va a usar y en qué contexto?
- ¿Qué tiene que hacer sí o sí para ser útil desde el día uno?
- ¿Qué queda fuera del MVP?
No asumas nada. No propongas soluciones. Solo escucha y documenta.
El output es un documento de requisitos. Claro. Sin ambigüedad.
Paso 2 — El Product Manager toma ese documento
Define las features con criterios de aceptación concretos.
No "el usuario puede ver sus hábitos". Sino: "el usuario ve un listado de hábitos activos
ordenados por frecuencia, con indicador visual del streak actual".
Esa diferencia parece pequeña. En la implementación es enorme.
Paso 3 — El Architect diseña antes de que se escriba código
Eres un Architect de software. Recibes el PRD del Product Manager
y tu trabajo es definir:
- Estructura de carpetas y módulos
- Modelo de datos (entidades, relaciones, campos)
- Contratos entre capas (qué expone cada módulo, qué consume)
- Stack técnico justificado
No escribas implementación. Escribe decisiones.
El output es un documento de arquitectura. El Developer lo recibe como contexto fijo.
Paso 4 — El Developer implementa con todo claro
Eres un Developer. Tienes el PRD, la arquitectura y las historias de usuario.
Tu trabajo es implementar el módulo de autenticación siguiendo exactamente
las decisiones de arquitectura documentadas.
Si encuentras una ambigüedad, para y pregunta. No asumas.
Módulo a módulo. Con criterios de aceptación. Con arquitectura definida.
Al final tienes un producto que alguien pensó antes de construir.
Por qué funciona mejor que hablar con un solo agente
Los modelos rinden mejor con un rol delimitado.
Un agente que solo hace arquitectura toma mejores decisiones de diseño que uno al que
le pides arquitectura, código, documentación y tests en el mismo chat.
El contexto se contamina. El foco se pierde. La calidad baja.
La especialización no es solo para humanos.
La conexión con la especificación
Lo que BMAD hace de forma implícita — separar el qué del cómo antes de escribir
código — tiene un nombre en ingeniería de software: desarrollo orientado a especificación.
Si quieres llevar esta idea más lejos y aplicarla en tu flujo de trabajo con IA de forma
sistemática, hay una metodología que lo formaliza: Spec-Driven Development (SDD).
La idea es la misma: antes de que un agente genere una sola línea de código, existe un
documento de especificación claro que define el qué, el quién, los flujos y las decisiones
de arquitectura. El agente developer recibe eso como contexto cerrado, no como un chat abierto.
Tengo un libro corto sobre esto — SDD: Construye con control — si
quieres ver cómo estructura esa especificación en la práctica.
Cómo empezar con BMAD
BMAD es open source en GitHub: busca [bmad-method](https://github.com/bmad-code-org/bmad-method).
Puedes tomarlo tal cual, adaptarlo a tu stack o usarlo como referencia para construir
tu propio sistema de agentes. Funciona con Claude, con GPT, con Gemini.
El modelo importa menos que el sistema.
Los mejores builders que conozco no tienen mejores prompts.
Tienen mejor estructura.
Top comments (0)