SDD vs BMAD vs Vibe Coding: qual escolher para seu time

A discussão sobre SDD, BMAD e Vibe Coding já saiu do "qual é melhor" há tempos. Continuar nessa pergunta é o atalho mais rápido para escolher errado.

Cada uma das três é boa. Em contextos diferentes. E cada uma quebra feio quando você empurra para o quadrante errado.

Neste post vou jogar as três numa matriz de decisão com quatro eixos — tamanho do time, maturidade do projeto, tolerância a erro e prazo — e mostrar o quadrante onde cada metodologia performa. Sem hype, sem religião de framework. Só engenharia.

TL;DR

SDD (Spec-Driven Development): spec é a fonte da verdade, código é gerado/validado a partir dela. Ferramenta de referência: GitHub Spec Kit.
BMAD-METHOD: time virtual de agentes (PM, Architect, Dev, QA, etc.) coordenados por um fluxo ágil. Ferramenta: BMAD-METHOD, 46.6k stars, v6.6.0 (abr/2026).
Vibe Coding: "fully give in to the vibes" — descrever o que quer e aceitar o que o LLM cospe, com loop de testes informais. Cunhado por Andrej Karpathy em fev/2025.
Quem decide: os quatro eixos da matriz lá embaixo. Não o framework mais badalado da semana.

As três em uma frase honesta

SDD — spec como contrato executável

A tese do paper Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants (Piskala, jan/2026) é direta: especificações deixam de ser documento que ninguém lê e viram artefato primário. O código é gerado, testado e auditado contra a spec.

O paper define três níveis de rigor: spec-first (a spec abre o trabalho), spec-anchored (a spec ancora as decisões ao longo do caminho) e spec-as-source (a spec é a única fonte — código é só um artefato compilado dela).

Na prática, o GitHub Spec Kit materializa isso num fluxo de comandos: /speckit.constitution define princípios, /speckit.specify descreve o "o que", /speckit.plan o "como", /speckit.tasks quebra em tarefas e /speckit.implement executa. A descrição oficial é literalmente "focus on product scenarios and predictable outcomes instead of vibe coding every piece from scratch".

Tradução: SDD é a metodologia para quando errar custa caro.

BMAD — time virtual com cinto de ferramentas

BMAD-METHOD — Breakthrough Method for Agile AI-Driven Development — não é um agente. É uma constelação de 12+ agentes especializados (Analyst, PM, Architect, Scrum Master, Dev, QA, UX) coordenados por um fluxo de quatro fases: Análise → Planejamento → Solucionamento → Implementação.

Cada agente gera artefatos persistentes: o Analyst entrega um briefing, o PM entrega o PRD, o Architect entrega o doc de arquitetura, o Scrum Master quebra em stories. Quando o Dev começa a codar, o contexto já está mastigado.

É ágil agênticamente embalado. E o ponto é exatamente esse: enquanto o Vibe Coding terceiriza raciocínio para o modelo, o BMAD impõe estrutura ágil sobre ele. O próprio framework se posiciona como antídoto ao caos do vibe coding — uma posição que aparece literalmente nos materiais da comunidade.

Vibe Coding — o solo do indie hacker

A definição original de Karpathy: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." A metodologia, se podemos chamar de metodologia, é: descreve o problema, deixa o LLM escrever, roda, copia o erro de volta no prompt, repete.

Karpathy foi explícito que o caso de uso são "throwaway weekend projects". Não produção. E os números reforçam: análise da Veracode (citada na Wikipédia) aponta que código gerado por IA tem ~1.7x mais bugs sérios e 2.74x mais falhas de segurança que código humano. O caso Lovable: 170 de 1.645 apps com vulnerabilidades exploráveis.

Mais provocador ainda: estudo da METR (jul/2025) mostrou que devs experientes ficaram 19% mais lentos com ferramentas de IA, mesmo prevendo que ficariam 24% mais rápidos. E o próprio Karpathy já abandonou o termo, preferindo "agentic engineering" hoje.

Isso não mata o vibe coding. Só coloca ele no lugar certo: protótipo, MVP descartável, validação rápida de ideia. Não sistema com SLA.

Os quatro eixos da decisão

Antes da matriz, cada eixo:

1. Tamanho do time

Solo, dupla, squad pequena (até 5), squad grande (5+) ou múltiplos squads. Quanto mais gente, mais o custo de coordenação engole o ganho de velocidade individual.

2. Maturidade do projeto

Greenfield exploratório (descobrindo o que construir), MVP com hipótese clara, produto em crescimento, sistema crítico em produção. Cada fase tolera quantidades muito diferentes de retrabalho.

3. Tolerância a erro

Bug aqui custa quanto? Vai de "ninguém nota" (protótipo interno) até "alguém perde dinheiro/saúde/dado pessoal" (fintech, healthtech, sistema de pagamento). Esse eixo é o mais subestimado e o que mais vai te queimar.

4. Prazo

Horas, dias, semanas, meses. Não confunda urgência percebida com urgência real — quase sempre dá pra empurrar dois dias e investir em estrutura, e quase nunca a urgência justifica jogar tudo no vibe.

A matriz: onde cada uma performa

Combinando os eixos, três quadrantes emergem com clareza:

Quadrante A — Vibe Coding ganha

Time: solo ou dupla.
Maturidade: greenfield exploratório ou MVP descartável.
Tolerância a erro: alta (ninguém vai morrer se quebrar).
Prazo: horas a dias.

Exemplos: prototipar uma landing page para validar copy, montar um script de scraping para uma análise pontual, fazer um POC interno para mostrar viabilidade. Empurrar SDD aqui é overengineering. Empurrar BMAD é orquestrar 12 agentes para escrever um for loop.

Quadrante B — BMAD ganha

Time: squad de 3 a 8 pessoas com pelo menos um dev sênior.
Maturidade: produto em crescimento, várias features paralelas, débito técnico real.
Tolerância a erro: média (bug atrapalha, mas não derruba o negócio).
Prazo: semanas a meses.

A força do BMAD aparece quando você precisa que o briefing, o PRD, a arquitetura e as stories existam de verdade — não só na cabeça do tech lead. O time virtual de agentes faz a coordenação ágil que um time pequeno raramente tem fôlego para fazer manualmente. E os artefatos persistentes viram memória organizacional: o próximo Dev (humano ou agente) entra no contexto sem precisar reaprender o produto.

Quadrante C — SDD ganha

Time: qualquer tamanho, mas com pelo menos um responsável técnico que escreve specs decentes.
Maturidade: sistema em produção, integrações com terceiros, contratos de API públicos.
Tolerância a erro: baixa (pagamento, saúde, dado regulado, B2B com SLA).
Prazo: indiferente — o investimento em spec se paga em qualquer prazo quando o erro é caro.

SDD brilha onde o "o que" precisa ser inquestionável antes do "como". A spec vira contrato: o LLM pode reescrever a implementação cinco vezes; o teste contra a spec não muda. Isso é o que o paper de Piskala chama de spec-as-source — a spec é o artefato canônico, o código é compilado a partir dela. Em ambiente regulado, isso não é luxo; é auditoria sobrevivendo a qualquer rotação de modelo ou refator.

A zona cinza (onde o time se enrola)

Há um quadrante D onde nenhuma das três é claramente melhor: time pequeno, projeto novo, mas com tolerância a erro baixa e prazo apertado. Tipicamente uma fintech early-stage. Aqui a saída é híbrida — SDD nas pontas críticas (auth, transação, integração financeira) e BMAD ou vibe coding ao redor (UI, dashboards internos, scripts).

A matriz não é determinística. É um ponto de partida para parar de discutir nome de framework e começar a discutir contexto.

Anti-padrões: como misturar errado

Três combinações que eu já vi quebrar:

Vibe coding em código que vai pra produção sem revisão. Você ganha velocidade na primeira semana, paga juros compostos nos próximos seis meses. O número da METR — 19% mais lento — não é um acidente; é o custo do débito técnico chegando.
BMAD num time solo. Orquestrar PM, Architect, Scrum Master e Dev quando você é todos eles é cosplay corporativo. O overhead de gerar artefato para si mesmo come o ganho.
SDD em greenfield exploratório. Se você ainda não sabe o que está construindo, escrever spec rigorosa é otimização prematura no nível ontológico. Spec antes de hipótese validada é ficção bem formatada.

Limitações da matriz

Os eixos não capturam tudo. Três coisas ficam de fora:

Skill do dev sênior no comando. Um dev raiz tira leite de pedra com qualquer metodologia. Um dev verde quebra qualquer framework.
Maturidade da stack de IA do time. Times com pipeline de evals, observabilidade de agentes e guardrails maduros operam BMAD e SDD com folga. Quem está começando vai sofrer com qualquer coisa além do vibe.
Cultura organizacional. Empresa que não respeita spec não vai respeitar SDD por mágica. Empresa que não faz cerimônia ágil de verdade não vai virar ágil porque tem agente de Scrum Master.

A metodologia é a parte fácil. A parte difícil é o time.

FAQ rápido

Dá pra usar as três no mesmo projeto? Dá. E é o caminho real na maioria dos casos. SDD nas regiões de baixo erro tolerável (auth, billing, integrações), BMAD nas features de produto que precisam de planejamento estruturado, vibe coding em scripts pontuais e protótipos. O erro é tratar as três como mutuamente exclusivas.

SDD não é só BDD/TDD com nome novo? Filosoficamente é parente. Operacionalmente não — TDD escreve teste antes do código que um humano vai digitar; SDD escreve spec antes do código que um agente vai gerar. A diferença é o consumidor da spec: o agente lê, valida e regenera. O paper de Piskala explora isso em detalhe.

BMAD não é só vibe coding com mais cerimônia? Não. BMAD impõe artefatos persistentes (PRD, arquitetura, stories) e quality gates entre fases. Vibe coding não tem nada disso por design — é exatamente o que Karpathy chamou de "forget that the code even exists". São opostos no eixo de estrutura.

Quanto tempo leva para um time adotar SDD ou BMAD? Depende de cultura. Times que já têm hábito de escrever PRD adotam BMAD em uma sprint. Times que nunca escreveram spec executável levam meses para SDD render — porque o gargalo deixa de ser "código" e passa a ser "clareza de pensamento", que é mais difícil de ensinar.

Conclusão

Se você terminar este post e a única coisa que mudar for trocar o framework da vez por outro, perdeu o ponto. A pergunta certa nunca foi "qual metodologia". Foi "qual quadrante esse trabalho ocupa na minha matriz" — e qual ferramenta cabe nesse quadrante.

SDD para sistemas onde a spec é contrato. BMAD para times que precisam de coordenação ágil sem o overhead humano. Vibe coding para validar hipótese rápido e jogar fora. Mistura quando o produto exige.

E se você está em dúvida sobre o quadrante, comece pelo eixo de tolerância a erro. É o que mais machuca quando você erra. O resto a equipe ajusta.