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

O leitor que pesquisa "BMAD ou AIOX, qual escolher" geralmente quer uma tabela com vencedor cravado. Esse instinto é a primeira armadilha. A pergunta certa não é "qual é melhor" — é "qual fricção você está eliminando agora". BMAD elimina fricção de processo no dev-lifecycle. AIOX elimina fricção cross-domain (squads, governance, multi-tenant). Tentar usar um para o problema do outro é ferramenta errada para o trabalho.

Este artigo é decision-support honesto: 3 personas brasileiras, 5 use-cases concretos, 4 armadilhas reais e admissão de que em alguns contextos nenhum dos dois é a escolha. Para a comparação técnica de fundo (por que não são intercambiáveis em primeira instância), ler o overview e tese de fundo.

Por que essa pergunta importa (e por que está mal feita 90% do tempo)

Comparações superficiais entre frameworks de agentes prometem ranking universal. "Framework X vence Y em 7 das 10 dimensões." Esse formato falha porque assume que todo problema cabe na mesma régua. Não cabe. Um dev solo construindo SaaS B2B em 4 semanas e uma holding com 4 negócios e governance constitucional não estão resolvendo o mesmo problema.

O reframe útil: não pergunte "qual é melhor". Pergunte "qual fricção dói mais hoje no meu fluxo". Se a fricção é dev-lifecycle desorganizado (story sem AC, dev sem clareza de scope, QA descobrindo regressão tarde), você precisa de método de desenvolvimento. Se a fricção é cross-domain (design não conversa com copy, legal trava lançamento, governance frouxa em portfolio), você precisa de framework de orquestração.

Essa distinção define o resto do artigo. BMAD-METHOD resolve o primeiro. AIOX resolve o segundo. Não é hierarquia; é categoria.

BMAD-METHOD em 1 minuto: o que é, para quem é

BMAD-METHOD é um método de desenvolvimento. Aproximadamente 8 personas nomeadas (Mary, John, Winston, Amelia, Sally, Murat) cobrem fases do ciclo de produto: PM levanta requisito, Architect modela, Dev implementa, QA valida. Versão atual v6.2.2, licença MIT, instalação via npx bmad-method install, repositório em github.com/bmad-code-org/BMAD-METHOD, comunidade Discord, documentação em docs.bmad-method.org com i18n para francês, mandarim e vietnamita.

O orchestration pattern é Pipeline + Quick Flow — pipeline canônico para projeto completo, quick flow para escopo reduzido. BMAD entrega Party Mode (múltiplas personas colaborando em uma sessão), Scale-Adaptive Planning (auto-ajusta profundidade do plano), Module Ecosystem (BMM/BMB/TEA/BMGD/CIS) e Information Density discipline. Para quem é: dev solo, time pequeno (1-5 devs), produto de software clássico, projeto OSS. Para a matriz técnica de 50 práticas comparando o que cada framework cobre, ver o spoke #2.

AIOX framework em 1 minuto: o que é, para quem é

AIOX/SINKRA é um framework de orquestração cross-domain. 473 agentes distribuídos em 53 squads, organizados em 8 layers (Business, Execution, Product, Services, Infrastructure, Framework, Governance, Evolution). Cada squad é uma unidade SINKRA com regras, tasks, workflows, skills e quality gates próprios — e os squads se compõem nas layers conforme o tipo de trabalho.

AIOX é privado (acesso por fork) e cobre o stack operacional completo: design-system, design-ops, copy, brand, movement, legal, data, finops, customer-success, db-sage, infra, c-level e mais 40+. Os diferenciais que BMAD não tem: Constitution de 322 linhas (11 artigos não-negociáveis enforçados via hooks), Agent Authority Matrix (exclusive ops por agente — só @devops dá push, só @db-sage roda migration), multi-tenant isolation por workspace L0-L4 (4 negócios), 53 squads cross-domain. Para quem é: holding, agência multi-cliente, portfolio de produtos, time grande operando governance forte. Para conhecer o framework, comece em aioxsquad.ai.

Decision tree por ICP: 3 personas, 3 recomendações

Cada persona abaixo vem do manifesto editorial AIOX, com vocabulário e dores reais coletados de 14 mil linhas de conversas WhatsApp e 250+ alunos do programa AIOX Pro. Não são personas inventadas — são quem realmente pesquisa essa decisão.

Persona 1 — O Dev Frustrado (30-50, mediana 38)

Você fala em stack, tooling, MVP, ship, vibe coding, terminal-first. Já testou 10+ ferramentas de IA e nenhuma clicou. Vê IA chegando e quer surfar, não ser substituído. Procura no Google, ChatGPT dev mode, Hacker News, GitHub trending. Sua dor é dev-lifecycle desorganizado: ticket sem clareza, scope creep, QA descobrindo regressão tarde.

Recomendação: BMAD-METHOD. Razão técnica: ~8 personas cobrem o ciclo todo (PM → Architect → Dev → QA), Party Mode permite múltiplas perspectivas numa sessão única (útil para brainstorming sólido), Quick Flow reduz overhead em features pequenas, MIT licensing libera para qualquer projeto OSS. Você está exatamente no escopo que BMAD foi desenhado para resolver.

Persona 2 — O Empreendedor Refém (30-50, mediana 40)

Você fala em MVP, validar, tração, PMF, CAC, LTV, burn rate, agência, freelancer. Já queimou R$50-200K com devs/agências que não entregaram. Tem 5+ ideias engavetadas porque ninguém quer fazer "a versão pequena". Procura no Google, ChatGPT, LinkedIn, YouTube no-code. Sua dor é dependência técnica sem time interno e medo do terminal.

Recomendação: NENHUM dos dois sozinho. Razão técnica: ambos pressupõem desenvolvedor operando o terminal. BMAD pressupõe dev-lifecycle estruturado (você não está nele). AIOX pressupõe governance que time-de-1 não usa. Caminho-de-menor-fricção: Claude Code direto + 1 documento de arquitetura simples + supervisão humana (mentor, imersão, comunidade). Migre para framework quando time crescer >3 pessoas ou hipótese virar produto.

Persona 3 — O Não-Técnico com Visão (40-60, reinventores tardios)

Você fala em controle, autonomia, soberania, estrutura, metodologia, passo a passo. Carrega ideia há anos. Sente que é "tarde demais". Procura no Google, YouTube long-form, ChatGPT básico, LinkedIn. Sua dor é barreira psicológica com terminal somada à pressão familiar/profissional pós-IA.

Recomendação: AIOX framework via guia humano (não solo). Razão técnica: 53 squads = playbook prescritivo por domínio (você não precisa inventar como começar — escolhe o squad, segue o workflow). Constitution e quality gates evitam besteira de agente alucinando — guardrails que protegem quem não tem repertório técnico. Mas isso só converte se houver alguém técnico operando o terminal pelo seu desenho. Se vai contratar dev solo, BMAD-METHOD pode ser mais simples na curva de aprendizado dele.

5 use-cases concretos: cenário → escolha → razão

Personas dão direção. Use-cases dão decisão.

UC1 — Dev solo construindo SaaS B2B com Claude Code

Escolha: BMAD-METHOD. Razão: dev-lifecycle clássico, sem cross-domain. Quick Flow para features pequenas + Party Mode para sessões de design. MIT facilita se virar OSS. AIOX seria overhead — você não vai usar squad de copy, design-ops ou legal num SaaS solo.

UC2 — Time de 2-3 devs em PME brasileira sem time técnico cliente

Escolha: BMAD-METHOD com Claude Code. Razão: ~8 personas cobrem o ciclo de produto cliente. Você não precisa de governance multi-tenant. Você precisa de método de entrega previsível. AIOX 53 squads é overhead que time pequeno não consegue operar.

UC3 — Holding com 4 negócios, governance forte, multi-tenant

Escolha: AIOX/SINKRA. Razão: workspace L0-L4 isolado por business é fundacional, não acessório. CODEOWNERS por path, agent authority com exclusive ops, multi-tenant via squads — tudo isso é necessidade quando você tem 4 negócios em uma só governança. BMAD não cobre essa superfície.

UC4 — Agência com 5+ clientes simultâneos, processos repetidos (hipótese)

Escolha: AIOX com adaptação. Razão: 53 squads cobrem o stack operacional cross-domain (design, copy, brand, movement, ads). Hipótese — não temos caso público de agência rodando AIOX. O ajuste exigido seria escopo por cliente em vez de escopo por business. Se você é agência, valide com piloto antes de comprometer.

UC5 — Founder não-técnico validando MVP em 4 semanas

Escolha: NENHUM dos dois isolado. Razão: ambos pressupõem desenvolvedor. Caminho-de-menor-fricção: Claude Code direto + supervisão humana + 1 documento de arquitetura. Frameworks adicionam overhead que MVP de 4 semanas não pode pagar. Migre para framework quando hipótese se confirmar e time crescer.

Quando usar AMBOS / NENHUM

Há cenários em que a resposta não é "escolha um".

Use AMBOS quando você opera holding com produto OSS interno. BMAD opera dentro do dev-lifecycle do produto OSS (story → dev → QA do código). AIOX opera fora, na camada de portfolio do grupo (squads de design, copy, legal, finops cross-business). Não competem — ocupam superfícies diferentes. Anti-padrão: usar AIOX para dev-lifecycle dentro do produto (overhead), ou BMAD para governance multi-tenant (escopo errado).

Não use nenhum quando você está em prototipagem rápida, validação de hipótese de produto, ou você não é técnico e não tem time. Claude Code direto + supervisão humana basta nessa fase. Frameworks adicionam ônus cognitivo (entender estrutura, ler documentação, configurar) que não traz benefício antes da hora. Migre para framework quando o problema crescer — nunca antes.

Comece pelo problema, escolha pela fricção. Se a fricção é dev-lifecycle, BMAD. Se a fricção é cross-domain ou governance, AIOX. Se você não consegue nomear a fricção, não escolha framework ainda — você ainda está formulando o problema.

Armadilhas reais de cada escolha (4 que pegam todo mundo)

Honestidade técnica antes da prescrição: toda escolha esconde trade-off. Aqui estão quatro que aparecem em conversas reais com criadores travados.

Armadilha 1 — Lock-in BMAD: personas fixos. BMAD pressupõe ciclo PM → Architect → Dev → QA. Se seu workflow é diferente (ex.: produto de pesquisa, ou time onde dev é PM ao mesmo tempo), retrabalho de DSL ou fork manual. Sair do dev-lifecycle clássico é caro.

Armadilha 2 — Lock-in AIOX: privado, acesso por fork. AIOX não é MIT. Escolha apenas se governance estruturada importa de verdade para o seu caso. Saída em 18 meses significa recriar squads, agents, rules em outro framework — esforço não trivial. Pergunte sempre: "o que vou perder se quiser sair daqui em 18 meses?"

Armadilha 3 — Custo escondido BMAD: pressupõe dev-lifecycle estruturado. Mesmo se você é solo, BMAD assume PM, Architect, Dev, QA como fases distintas. Solo-builder pulando fases sente atrito do framework lutando contra o seu fluxo. Para quem é só dev resolvendo bugs em produto seu, Claude Code direto pode ser mais leve que BMAD.

Armadilha 4 — Custo escondido AIOX: 8 layers, 53 squads. Em time de 1-3 pessoas, é overhead. Você lê documentação de squads que nunca vai usar. Constitution gera atrito real em pull request (3 gates antes de mergear) — bom em produção, ruim em prototipagem. Em escala pequena, AIOX cobra estrutura sem entregar benefício proporcional.

Comece por aqui (caminho-de-menor-fricção por persona)

Decisão sem ação é especulação. Aqui estão três caminhos práticos por persona.

Se você é Dev Frustrado: rode npx bmad-method install hoje. Configure Claude Code como runtime. Reserve 3 horas para entender estrutura — Mary (analyst), John (PM), Winston (architect), Amelia (dev), Sally (PO), Murat (QA). Em uma tarde você sabe se BMAD encaixa no seu ritmo. Custo de saída é zero (MIT, npm uninstall).

Se você é Empreendedor Refém: não escolha framework hoje. Comece por Claude Code direto + 1 documento de arquitetura escrito por você (uma página, em pt-BR, descrevendo o produto). Use mentoria ou imersão guiada para os 30 primeiros dias. Migre para framework quando time crescer (>3 pessoas) ou hipótese virar produto. Você economiza overhead de framework que ainda não justifica.

Se você é Não-Técnico com Visão: não tente framework solo. Busque mentoria, imersão ou contratação de dev-solo com supervisão. Se já tem time técnico, AIOX framework via aioxsquad.ai entrega estrutura prescritiva por domínio + governance que evita alucinação. Se vai contratar dev solo terceirizado, BMAD-METHOD pode ter curva de aprendizado mais leve para o profissional.

A escolha certa muda conforme o problema cresce. Comece pequeno, escolha pela fricção atual, migre quando o problema mudar de categoria. Para a comparação técnica de fundo entre os dois frameworks, ler o overview e tese de fundo.