BMAD-Method para quem já usa SDD: onde acerta e onde adiciona ruído

Você já tem Spec-Driven Development rodando no fluxo. /specify, /plan, /tasks, /implement. A spec virou o artefato principal e o código virou a "última milha".

Aí aparece o BMAD-Method na sua timeline. Promessa de "time ágil de IA": Analyst, PM, Architect, Dev, QA. Cada um com persona, prompt, identidade. 43 mil estrelas no GitHub, gente séria usando, gente séria reclamando.

A pergunta honesta é: BMAD é o próximo nível do SDD ou é cerimônia a mais com chapéu de framework? Vou mapear os dois em termos um do outro e mostrar onde BMAD vale o overhead, e onde ele só está vendendo waterfall com batom novo.

TL;DR

• O que é: BMAD-Method é um framework multi-agente para desenvolvimento ágil com IA. Cada fase do projeto é encarnada por uma persona com prompt e comandos próprios.
• Stack/Modelos: Claude Code, Cursor, qualquer IDE com agentes. Funciona em cima de Node 20+ e Python 3.10+.
• Custo/Acesso: Gratuito, open-source, MIT.
• Repositório/Link útil: github.com/bmad-code-org/BMAD-METHOD e docs.bmad-method.org.

O que é BMAD em termos de SDD

Se você está habituado ao GitHub Spec Kit, o modelo mental do BMAD não é tão diferente quanto a documentação faz parecer.

SDD organiza artefatos: constitution, spec, plan, tasks, implementation. Cada comando produz um documento que vira input do próximo. O agente é um só, vestindo chapéus diferentes a cada slash command.

BMAD organiza personas. A versão 6.6.0 da documentação oficial lista pelo menos seis agentes nomeados: Mary (Analyst), John (PM), Winston (Architect), Sally (UX Designer), Amelia (Developer) e Paige (Technical Writer). Cada um tem skill ID, comandos próprios e foco. O fluxo é dividido em duas fases grandes: planejamento (Analyst, PM, Architect produzem brief, PRD e arquitetura) e desenvolvimento (Dev e QA executam histórias).

A diferença prática é menos profunda do que parece. Em ambos você empurra contexto progressivamente para o modelo até chegar no código. SDD chama isso de "phases". BMAD chama de "agentes". O resultado é parecido: estrutura, rastreabilidade, menos vibe coding.

O mapeamento que ajuda a decidir

Para quem já tem SDD no músculo, a tradução é mais ou menos esta:

Lendo a tabela, a sensação é que BMAD é SDD com mais cerimônia. Em parte é isso mesmo. Mas tem uma diferença que importa: o BMAD não trata os agentes como "fases sequenciais que produzem documentos". Ele trata como identidades persistentes que você invoca repetidas vezes.

Você pode chamar a Mary no meio do projeto para fazer um market research. Pode chamar o Winston para revisitar a arquitetura quando a história 12 mostrar que o modelo de dados não cabe. SDD, na prática, te empurra a regenerar o plan.md quando algo muda. BMAD te dá um arquiteto vivo para refinar o doc existente.

Onde BMAD acerta de verdade

1. Projeto greenfield grande, time pequeno. Quando você está sozinho ou em dupla começando algo do zero e não tem PM, arquiteto e PO de carne e osso, ter personas com prompts pré-tunados para cada papel reduz o "white page paralysis". A persona do PM vai te perguntar coisas que você esqueceria de perguntar a si mesmo. É um espelho útil.

2. Modernização de legado mal documentado. O caso descrito no Benny's Mind Hack mostra o melhor uso real do BMAD: time pegou um sistema legado opaco, usou os agentes para reconstruir o entendimento da business logic, gerou um Control Manifest versionado e conseguiu rastrear o microsserviço novo de volta até a regra de negócio original. Esse tipo de rastreabilidade não sai de graça com SDD puro, sai com disciplina de processo. BMAD codifica essa disciplina.

3. Quando você precisa de revisão adversarial. O teste prático publicado por RanTheBuilder deu ao BMAD nota 3.65/5 no overall, mas destacou que ele foi o melhor em "design correctness" e revisão adversarial. A separação entre PM, Architect e QA cria pontos naturais de fricção, onde uma persona contesta o output da outra. SDD, sendo single-agent, tende a concordar consigo mesmo.

Onde BMAD adiciona ruído

1. Overhead de setup é real. O mesmo teste do RanTheBuilder marcou seis dias do início ao fim para uma feature, com custo de US$ 200 em tokens. O BMAD Quick (variação enxuta) caiu para 6,5 dias e US$ 85, mas ainda assim é pesado para feature pequena. Para comparação, o Spec Kit fez a mesma feature em cinco horas de planejamento mais um dia de implementação.

2. Multi-agent chaos em projeto pequeno. A análise do nosam.com cunhou o termo. Quando o projeto não justifica um time inteiro, ter seis agentes encadeados vira fricção pura. Você passa mais tempo invocando persona do que escrevendo código. Spec Kit te dá quatro slash commands. BMAD te dá uma orquestra.

3. Inflação de documentos. A crítica do Marmelab sobre SDD vale ainda mais para BMAD: uma feature simples pode terminar em oito arquivos e mil e trezentas linhas de texto. Em BMAD, com sharding de épicos e histórias, esse número cresce. Documento que ninguém relê é dívida, não ativo.

4. A ambiguidade não some por causa do organograma. A observação mais incômoda vem do Martinelli: "adicionar mais agentes de IA ou etapas adicionais de fluxo de trabalho não elimina essa ambiguidade". O problema raiz do desenvolvimento com IA é a qualidade da especificação, não o número de personas que processam ela. BMAD organiza melhor a atividade. Não necessariamente melhora a informação que entra.

5. Aproximação com waterfall. Plano completo antes de qualquer código, fases sequenciais, gates de aprovação entre personas. Quem já trabalhou em ambiente com PMO pesado sente o cheiro. Software ainda é processo não-determinístico. Plano que não comporta descoberta atrapalha mais do que ajuda.

Quando escolher cada um

Regra de bolso honesta para quem já tem SDD no músculo:

• Mantém SDD puro se você está em projeto pequeno-médio, time enxuto, código vivo, ciclo curto. Spec Kit + disciplina de prompt cobre 80% dos casos.
• Considera BMAD se você está em greenfield grande, modernização de legado opaco, ambiente regulado que exige rastreabilidade documentada, ou quando quer revisão adversarial automatizada entre personas.
• Foge de qualquer um dos dois se você está fazendo bug fix, exploratório, prova de conceito de duas horas. Aí vibe coding com bom contexto ainda ganha.

A pergunta que importa não é "qual framework". É qual harness você está construindo em torno do agente. Framework é detalhe. Engenharia é o que decide se o agente entrega produto ou demo.

FAQ rápido

BMAD substitui o Spec Kit? Não. São abordagens diferentes para o mesmo problema. SDD organiza artefatos, BMAD organiza personas. Você pode até misturar: usar o Spec Kit para a fase de spec/plan e o BMAD apenas para a parte de QA adversarial.

Vale para projeto Laravel ou só para stack JS/Python? Vale para qualquer stack. BMAD é orquestração em cima do agente de IA, não framework de runtime. Os comandos rodam no Claude Code ou no Cursor, e o código gerado é da linguagem que você definiu na arquitetura. Em PHP/Laravel funciona normal.

O custo de US$ 200 por feature do BMAD se paga? Depende do que a feature significa para o negócio. Para uma feature crítica em sistema regulado, US$ 200 e seis dias com rastreabilidade documentada é barato. Para um CRUD de admin, é caro absurdo. A pergunta é sempre o valor entregue, não o gasto absoluto em tokens.

BMAD funciona com modelos menores tipo Haiku? Funciona, mas perde qualidade rápido. As personas dependem de raciocínio mais longo para manter consistência entre fases. Sonnet é o piso prático. Opus rende melhor em projetos complexos, custa mais.

Conclusão

BMAD não é hype nem é fraude. É uma escolha de engenharia com trade-off claro: você troca agilidade por estrutura, e velocidade por rastreabilidade. Para o time certo, no projeto certo, paga. Para o time errado, no projeto errado, vira cerimônia que atrasa entrega.

A leitura honesta de quem já tem SDD rodando é: experimenta BMAD em uma feature isolada antes de migrar processo inteiro. Se a sensação for "agora os agentes brigam entre si e meu PRD tem trezentas linhas que ninguém vai ler", volta para SDD enxuto e segue. Se a sensação for "finalmente tenho o arquiteto que minha startup nunca contratou", então o overhead vale.

O que não muda em nenhum dos dois caminhos é que o diferencial do dev em 2026 não é o framework de prompt. É o harness em volta do agente: contexto certo, ferramentas certas, avaliação automatizada, controle de qualidade no loop. Se você quer ver isso aplicado em produto real, sem chatbot e sem slide motivacional, é exatamente o que rola no Harness Engineering com Claude Code: dois dias ao vivo construindo do zero um app que recebe link de produto, pesquisa alternativas em e-commerces e devolve recomendação estruturada, com Claude Code, Laravel e NativePHP.

Framework é detalhe. Engenharia é o que entrega.