BMAD na Prática: O Fluxo Completo de Desenvolvimento com Agentes de IA

Nos artigos anteriores da série falamos sobre SDD (Spec-Driven Development) e como aplicar quality gates, testes e templates. Agora vou mostrar algo que não encontrei documentado de forma clara em lugar nenhum: o fluxo completo do BMAD, passo a passo, mostrando como os agentes de IA se organizam pra entregar código de produção.

O que é o BMAD?

O BMAD (Breakthrough Method for Agile AI-Driven Development) é um framework open source que organiza agentes de IA como se fossem um time ágil. Cada agente assume um papel, PM, Arquiteto, Dev, QA e executa uma parte específica do fluxo de desenvolvimento.

O ponto central é: você não diz “faz aí” pra IA. Você segue um fluxo onde cada fase produz artefatos que alimentam a próxima, e cada agente de IA sabe exatamente o que fazer porque tem contexto estruturado.

Os Agentes

Antes de entrar no fluxo, vale conhecer quem faz o quê. Lembrando: são todos agentes de IA, não pessoas reais.

Agente de IA	Papel	O que faz
Analista	Discovery	Pesquisa de domínio, mercado, concorrência
PM	Planejamento	Cria PRD com requisitos funcionais e não-funcionais
UX Designer	Design	Cria specs de UX, componentes, padrões de interação
Arquiteto	Solucionamento	Toma decisões técnicas (ADRs), valida prontidão
Scrum Master	Organização	Planeja sprints, cria stories, faz retrospectiva
Dev	Implementação	Executa stories usando TDD
QA	Qualidade	Estratégia de testes, automação
Solo Dev	Quick Flow	Faz spec + dev + review pra mudanças pequenas

Dois Caminhos: Full Method vs. Quick Flow

A primeira decisão no BMAD é: qual o tamanho da mudança?

flowchart TB START([Nova mudança]) --> DECISION{Qual o tamanho?} DECISION -->|"Grande"| FULL["Full Method"] DECISION -->|"Pequena"| QUICK["Quick Flow"] accTitle: Decisão de escopo do BMAD accDescr: Uma decisão de escopo mostrando que mudanças grandes seguem o Full Method, enquanto mudanças pequenas usam o Quick Flow.

Full Method: passa por todas as fases, com múltiplos agentes de IA colaborando
Quick Flow: um único agente (Solo Dev) faz spec + dev + review

Essa separação é fundamental. Sem ela, você acaba usando o processo completo pra corrigir um typo, ou pior, fazendo uma feature complexa sem specs.

Full Method: O Fluxo Completo

Greenfield (Projeto Novo)

Quando o projeto é novo, começamos do zero, da análise até a implementação:

flowchart TB F1["1. Análise"] F2["2. Planejamento"] F3["3. Solucionamento"] F4["4. Implementação"] F1 --> F2 --> F3 --> F4 accTitle: Fases greenfield do BMAD accDescr: Um fluxo greenfield de quatro fases que começa em análise, passa por planejamento e solucionamento, e termina em implementação.

Fase 1 — Análise (Agente Analista)

O agente Analista faz a pesquisa inicial: domínio, mercado, concorrência, viabilidade técnica. Produz o Product Brief com visão, personas e métricas de sucesso.

Fase 2 — Planejamento (Agentes PM e UX Designer)

O agente PM cria o PRD (Product Requirements Document) com todos os requisitos funcionais em formato Given/When/Then. Se o projeto tem UI, o agente UX Designer cria as specs de design: componentes, padrões de interação, design system.

Fase 3 — Solucionamento (Agente Arquiteto)

O agente Arquiteto toma as decisões técnicas e documenta como ADRs (Architecture Decision Records). Depois, quebra o PRD em epics e stories. No final, roda uma validação de prontidão pra garantir que tudo está alinhado antes de começar a codar.

Fase 4 — Implementação (Agentes SM, Dev e QA)

Aqui é onde o código acontece:

flowchart TB SM["Planejar sprint"] STORY["Criar story"] ARCH{"DoR ok?"} DEV["Implementar com TDD"] QA{"Review ok?"} GATES{"Gates passaram?"} COMMIT["Commit e sync"] SM --> STORY --> ARCH ARCH -->|OK| DEV ARCH -->|Falhou| STORY DEV --> QA QA -->|OK| GATES QA -->|Corrigir| DEV GATES -->|Passou| COMMIT GATES -->|Falhou| DEV accTitle: Loop de implementação do BMAD accDescr: Um loop de implementação em que o planejamento de sprint cria stories, a prontidão é validada, o desenvolvimento segue com TDD, QA revisa o resultado, quality gates rodam, e o trabalho aprovado é commitado.

O agente Scrum Master planeja o sprint e cria os arquivos de story com contexto completo
O agente Arquiteto valida a Definition of Ready de cada story
O agente Dev implementa usando TDD: RED -> GREEN -> REFACTOR por AC
O agente QA faz code review adversarial
Quality gates: testes + build + type-check
Commit e sincronização de artefatos

Brownfield (Código Existente)

Quando já existe código em produção, o fluxo muda. Não precisa de Fase 1 (análise) porque o domínio já é conhecido. O contexto vem do próprio codebase:

flowchart TB START([Código existente]) --> CTX["Gerar contexto"] CTX --> DECISION{Precisa de PRD?} DECISION -->|Sim| P2["Fase 2: PRD"] DECISION -->|Não| P3["Fase 3: Arquitetura"] P2 --> P3 P3 --> P4["Fase 4: Implementação"] P4 --> DONE([Código entregue]) accTitle: Fluxo brownfield do BMAD accDescr: Um fluxo de entrega brownfield em que o código existente fornece contexto do projeto, o PRD é produzido quando necessário, a arquitetura é definida e a implementação entrega o código.

A diferença principal: antes de qualquer coisa, você gera um project context, um documento que descreve os padrões, stack, convenções e estrutura do codebase existente. Isso permite que os agentes de IA sigam os padrões que já existem em vez de inventar novos.

Quick Flow: O Caminho Rápido

Pra mudanças pequenas, bugs, ajustes de config e features simples que mexem em menos de 3 arquivos, o Quick Flow é o caminho.

flowchart TB QS["Quick Spec"] --> QD["Quick Dev"] QD --> QR["Code Review"] QR --> DONE([Código entregue]) accTitle: Caminho Quick Flow accDescr: Um fluxo enxuto em que uma quick specification leva a quick development e depois a code review antes da entrega.

Um único agente de IA (o Solo Dev) faz tudo:

Quick Spec: cria uma tech-spec ou story simplificada
Quick Dev: implementa a mudança
Code Review: revisa o próprio código de forma adversarial

O Quick Flow não pula quality gates, testes, build e type-check continuam sendo necessários. O que ele pula são as fases de planejamento e solucionamento que não fazem sentido pra mudanças pequenas.

Quando usar Quick Flow vs. Full Method?

Cenário	Caminho
Bug fix isolado	Quick Flow
Ajuste de config	Quick Flow
Feature simples (< 3 arquivos)	Quick Flow
Feature nova com múltiplos endpoints	Full Method
Refactor de arquitetura	Full Method
Novo epic ou módulo	Full Method
Mudança que afeta segurança/auth	Full Method

Na dúvida, use o Full Method. É melhor ter specs que não precisava do que código sem specs.

Os Artefatos do Fluxo

Cada fase produz artefatos que alimentam a próxima. Isso é o que diferencia o BMAD de simplesmente pedir pra IA “faz aí”:

flowchart TB F1["Análise"] --> A1["Product Brief"] A1 --> F2["Planejamento"] F2 --> A2["PRD + UX Specs"] A2 --> F3["Solucionamento"] F3 --> A3["ADRs + Stories"] A3 --> F4["Implementação"] F4 --> A4["Código + Testes"] F4 --> A5["Sprint Status"] A4 -. Atualiza .-> A2 A4 -. Atualiza .-> A3 accTitle: Cadeia de handoff de artefatos do BMAD accDescr: Uma cadeia de handoff em que análise produz Product Brief, planejamento produz PRD e UX Specs, solucionamento produz ADRs e Stories, e implementação produz código, testes e status de sprint com feedback voltando para specs e arquitetura.

Os artefatos são documentos vivos. Quando a implementação revela que algo precisa mudar nas specs, as specs são atualizadas. Esse feedback loop é o que mantém tudo consistente.

Sprint Status como Fonte da Verdade

O estado de cada story é rastreado num arquivo central:

development_status:
  # Epic 1: Autenticação
  epic-1: in-progress
  1-1-user-registration: done
  1-2-user-login: in-progress
  1-3-password-reset: ready-for-dev
  1-4-oauth-integration: backlog

  # Epic 2: Dashboard
  epic-2: backlog
  2-1-dashboard-layout: backlog

Os status possíveis seguem um fluxo linear:

flowchart TB BACKLOG["backlog"] --> READY["ready-for-dev"] READY --> PROGRESS["in-progress"] PROGRESS --> REVIEW["review"] REVIEW --> DONE["done"] accTitle: Progressão de status da sprint accDescr: Uma progressão linear de status da sprint que vai de backlog para ready-for-dev, depois in-progress, review e done.

O Fluxo de Decisão Completo

Juntando tudo, o fluxo de decisão do BMAD fica assim:

flowchart TB START([Nova mudança]) --> SCOPE{Escopo?} SCOPE -->|Pequena| QF["Quick Flow"] SCOPE -->|Grande| EXISTS{Projeto já existe?} EXISTS -->|Não| GF["Greenfield"] EXISTS -->|Sim| BF["Brownfield"] QF --> DONE([Entregue]) GF --> DONE BF --> DONE accTitle: Fluxo completo de decisão do BMAD accDescr: Um fluxo completo de decisão em que uma nova mudança é roteada para Quick Flow ou, no caso de trabalho maior, para entrega greenfield ou brownfield conforme a existência prévia do projeto.

Considerações finais

O BMAD não é um framework pra tornar as coisas mais burocráticas. É pra tornar o trabalho com agentes de IA previsível e confiável. Sem um fluxo estruturado, cada sessão é uma loteria, às vezes a IA acerta, às vezes não.

Com o BMAD:

Mudanças pequenas são rápidas (Quick Flow)
Mudanças grandes são bem planejadas (Full Method)
Todo código tem specs, testes e review
O contexto persiste entre sessões através de artefatos vivos

Se você leu os outros artigos da série sobre SDD, agora tem o quadro completo: o fluxo (este artigo), a filosofia e as práticas.

Repositório oficial do BMAD Method.

O que é o BMAD?#

Os Agentes#

Dois Caminhos: Full Method vs. Quick Flow#

Full Method: O Fluxo Completo#

Greenfield (Projeto Novo)#

Brownfield (Código Existente)#

Quick Flow: O Caminho Rápido#

Quando usar Quick Flow vs. Full Method?#

Os Artefatos do Fluxo#

Sprint Status como Fonte da Verdade#

O Fluxo de Decisão Completo#

Considerações finais#

Comentários