BMAD ou AIOX: quando usar cada um (decision tree por ICP)

Toda semana alguém pergunta: "BMAD ou AIOX, qual ganha?" A resposta honesta começa com outra pergunta. E essa pergunta muda quem você é, o tamanho do seu time e o problema que está pagando o teu sono.

Este guia não vende um vencedor. Mapeia decisão por ICP, casos concretos, armadilhas e os três contextos onde a resposta é "nenhum dos dois". Para a tese e a arquitetura comparada lado a lado, o ponto de partida é a tese e arquitetura comparada.

A pergunta errada vs a pergunta certa

A pergunta por trás da pergunta é simples. Ninguém escolhe framework. Escolhe fricção a eliminar.

BMAD-METHOD elimina fricção de processo dentro do ciclo clássico de software. PM levanta requisito, Architect modela, Dev implementa, QA valida. Os ~8 personas do BMAD existem porque essa é a unidade de trabalho do dev-lifecycle.

AIOX elimina fricção cross-domain. Os 53 squads existem porque o trabalho de uma holding não cabe em "PM + Dev + QA". Tem copy de campanha, design system multi-brand, finops, legal, brand, movement, ads. Isso vive em superfície diferente.

Tese curta: BMAD modela quem faz dentro de um produto. AIOX modela onde o trabalho vive num portfólio. Trocar um pelo outro é forçar ferramenta para fora do escopo dela.

BMAD-METHOD em 1 minuto

MIT, open-source, instalação via npx bmad-method install. Docs públicas em docs.bmad-method.org. Comunidade no Discord, i18n em francês, mandarim e vietnamita. ~8 personas nomeadas (Mary, John, Winston, Amelia, Sally, Murat) cobrem PM, Architect, Dev, QA e fases adjacentes. Pipeline canônico para escopo completo, Quick Flow para escopo reduzido. Party Mode permite múltiplas personas em sessão única (brainstorm, roundtable). Scale-Adaptive Planning auto-ajusta profundidade do plano pela complexidade detectada. Module Ecosystem (BMM, BMB, TEA, BMGD, CIS) extende por domínio. SINKRA score 82/100 (MAP-READY) no bench 5-way. A matriz técnica de 70+ práticas abre cada dimensão com evidência local.

AIOX em 1 minuto

Privado, governado por 4 negócios sob mesma constituição. Stack TypeScript, Python, Shell, YAML. 473 agentes em 53 squads, organizados em 8 layers (Business, Execution, Product, Services, Infrastructure, Framework, Governance, Evolution). Constitution de 322 linhas com 11 artigos enforçados via hook. Agent Authority Matrix com exclusive ops: só @devops dá push, só @db-sage roda migration, só @architect aprova mudança de arquitetura. Multi-tenant L0-L4 isola dados por negócio via CODEOWNERS por path. SYNAPSE 8-layer context engine governa TTL por camada (365d/90d/60d/30d/7d). Bench interno registrou 28 práticas distintas de orquestração e 16 práticas exclusivas, ambas a maior contagem entre os frameworks comparados. Para entrar, comece em aioxsquad.ai.

Decision matrix por ICP

Três personas brasileiras concretas, três critérios que decidem na prática. Manifesto editorial AIOX (icps[]) sustenta esses perfis. Os números vêm do bench 5-way interno.

Lê de novo a coluna do meio. Empreendedor sem time técnico tentando rodar framework antes de validar hipótese é o erro mais caro do mercado. Framework antes da hora é overhead vestido de produtividade.

7 use cases concretos

Saindo da persona pura para situação real. Cada linha é um caso que aparece em cohort de aluno AIOX e em projeto de holding. A recomendação reflete o problema, não a preferência.

Pareto ao Cubo aplicado: 80% das decisões saem de 3 variáveis. Tamanho de time, escopo (dev puro vs cross-domain) e maturidade da hipótese de produto. As outras 17 variáveis afinam a borda.

Quando usar AMBOS, quando usar NENHUM

O caso AMBOS é o mais comum em empresa de meio-do-caminho. Holding com 1 produto OSS interno: BMAD opera dentro do dev-lifecycle do produto (story → dev → QA), AIOX opera na camada de portfolio do grupo (squads de design, copy, legal, finops cross-business). Não competem. Ocupam superfícies diferentes do mesmo problema. O cuidado aqui é demarcar fronteira: BMAD não invade portfolio, AIOX não invade dev-lifecycle do produto. Sem essa fronteira, vira soup de cerimônia.

O caso NENHUM é o mais negligenciado. Empreendedor solo sem time técnico validando MVP precisa de uma coisa: hipótese contra mercado real. Framework agora é fuga elegante de validação. Use Claude Code direto, escreve um documento de arquitetura de uma página, contrata mentoria humana, valida em campo. Migra para framework quando aparecer time (>3 pessoas) ou quando hipótese virar produto com receita recorrente e exigir governance. Antes disso, qualquer framework é otimização prematura disfarçada de seriedade.

Existe ainda um terceiro contexto onde nenhum dos dois resolve sozinho: time regulado com inputs de usuário não-confiáveis. Aqui a primeira fundação é segurança (prompt injection scanner, path traversal protection), e o bench mostra que GSD-1 lidera nessa dimensão. AIOX cobre via Constitution e governance, BMAD não cobre. Quem opera saúde, jurídico ou financeiro deve resolver essa camada antes de escolher framework de orquestração.

Clareza é uma arma. Quando você sabe qual fricção está eliminando, a escolha de framework deixa de ser ansiedade e vira decisão técnica. Quando não sabe, qualquer framework vira muleta para a pergunta que você fugiu de fazer. Decisão sem clareza de fricção é teatro de produtividade. Frameworks liberam, dogmas aprisionam: o framework certo na hora errada é dogma com nome bonito. Conhece-te a ti mesmo, conhece teu time, conhece o problema que está pagando teu sono. A decisão certa cai no colo depois disso.

4 armadilhas reais

Toda escolha esconde trade-off. Estas quatro pegam praticamente todo mundo na primeira tentativa.

Do ponto de vista de sistemas, armadilha 3 é a mais traiçoeira. Cerimônia é sintoma de framework grande forçado em problema pequeno. Quem vendeu framework como solução universal não falou desse custo.

Como decidir em 3 perguntas

Decision tree explícito. Responde as três e a recomendação cai no colo.

Pergunta 1: Você tem time técnico operando o terminal?

• Não → NENHUM dos dois agora. Claude Code direto + supervisão humana. Volta quando tiver time.
• Sim → próxima pergunta.

Pergunta 2: O escopo é dev-lifecycle puro ou cross-domain?

• Dev-lifecycle puro (PM, Dev, QA, Architect) → BMAD-METHOD.
• Cross-domain real (design, copy, legal, finops, brand, movement em paralelo) → AIOX.
• Os dois ao mesmo tempo (produto OSS dentro de holding) → AMBOS em camadas diferentes.

Pergunta 3: Você tem governance regulatória ou multi-tenant obrigatório?

• Sim (saúde, jurídico, financeiro, agência multi-cliente) → AIOX. Constitution e Agent Authority são fundação, não overhead.
• Não → mantém a recomendação da pergunta 2.

Três perguntas. Resposta em menos de dois minutos. Sem ansiedade, sem hype, sem "depende".

Comece por aqui

Se você é Dev Frustrado, comece por BMAD-METHOD. Roda npx bmad-method install num projeto pequeno seu, abre o Quick Flow, valida em uma feature de 1-2 dias. Se a fricção que você sentia era de processo dentro do dev-lifecycle, a melhora aparece na primeira sprint. Se a fricção persistir mesmo com BMAD ativo, a hipótese de problema estava errada — não era processo, era escopo cross-domain. Aí você reabre esta página e olha AIOX.

Se você é Empreendedor Refém, comece por Claude Code direto. Escreve uma página de arquitetura, valida hipótese contra mercado real em 4-6 semanas. Quando aparecer time ou quando hipótese virar produto com receita, volta nesta página e escolhe entre BMAD (se virou software puro) ou AIOX (se virou portfólio cross-domain). Não pula etapa. Framework antes de validação é o erro mais caro dessa persona, e o cohort AIOX viu isso muitas vezes.

Se você é Não-Técnico com Visão, comece por mentoria humana antes de qualquer framework. AIOX e BMAD pressupõem terminal. O caminho-de-menor-fricção para você é dev contratado executando BMAD por encomenda, ou mentor desenhando com você no papel antes de qualquer linha de código. Investir em ferramenta antes de investir em quem opera a ferramenta é dinheiro queimado.

Para a comparação técnica completa entre os dois, volta na tese e arquitetura comparada. Para a matriz dimensão por dimensão, a matriz técnica de 70+ práticas abre cada decisão de design. Para arquitetura do AIOX em produção, abre aioxsquad.ai. O resto da decisão é seu trabalho de arquiteto. Compensa quando feito com clareza de fricção, não com ansiedade de framework.