“Vibe coding” virou rótulo para iterar com IA quase no piloto automático: descreve o clima, aceita o diff, segue em frente. Spec-Driven Development (SDD) soa oposto, formal, lento. Na prática, ambos podem usar o mesmo editor e o mesmo modelo; o contraste está no contrato mental com o código que entra no repositório.
Diagrama editorial: SDD ancora revisão; vibe coding tende a pular etapas.
1. Dois modos, mesma ferramenta
Vibe coding prioriza fluxo e sensação de progresso: prompts encadeados, ajustes visuais, “funcionou no meu machine”. SDD prioriza rastreabilidade: problema, escopo, critérios de aceite e limites antes ou junto da geração assistida.
Nenhum dos dois é “sem IA”. A diferença é se a IA recebe contexto verificável ou apenas um desejo difuso.
2. O que SDD exige
Uma spec útil pode caber em uma página: usuário, comportamento esperado, fora de escopo, restrições técnicas. O agente (ou o dev) implementa contra isso; a revisão pergunta “atende a spec?” em vez de “parece ok?”.
SDD não elimina criatividade, delimita onde a criatividade é desejável (UX, algoritmo) e onde é perigosa (permissões, billing, persistência). Specs também alimentam testes e documentação mínima de produto.
3. O que vibe coding otimiza
Exploração: validar cor, layout, API desconhecida, spike descartável. O custo de setup é baixo; o feedback é imediato. Para protótipos pessoais ou demos de conceito, isso é feature, não bug.
O problema começa quando o spike vira produção sem passar por contrato, especialmente em codebases compartilhadas, onde ninguém mais sabe quais partes confiar.
4. Riscos comparados
Vibe coding acumula dívida invisível: nomes inconsistentes, caminhos mortos, dependências ocultas, testes ausentes. SDD mal feito acumula dívida visível: spec desatualizada, burocracia vazia. O pior caso de SDD é teatro; o pior caso de vibe coding é software que ninguém ousa tocar.
Revisão humana é obrigatória nos dois modos. SDD só funciona se alguém atualizar a spec quando a realidade mudar; vibe coding só funciona em produção se alguém converter exploração em decisões explícitas antes do merge.
5. Quando usar cada um
Use vibe coding (com descarte planejado) para aprender, mockar, testar hipótese de interface. Use SDD quando o código precisa sobreviver a outro dev, auditoria, integração ou ciclo longo de manutenção, casos típicos de produto real, como utilitários desktop ou fluxos com dados sensíveis.
Um fluxo híbrido comum: vibe na descoberta, spec curta antes do PR, IA para boilerplate, revisão contra a spec. O objetivo não é moralizar velocidade, é escolher conscientemente o que merece permanecer.