Vibe coding ou spec driven development: quem decide?

Vibe coding e spec driven development não são dois níveis de capricho, são dois lugares onde a decisão de projeto acontece. No vibe coding quem decide é o agente, em silêncio, enquanto escreve; no spec driven quem decide é você, antes. Eu rodei o mesmo pedido nas duas formas, com o mesmo agente e na mesma máquina, e a diferença de tempo foi de 11 segundos.

O que é vibe coding, na prática?

Vibe coding é descrever o que você quer em linguagem natural e aceitar o que o agente devolver, ajustando por conversa até ficar bom. Não tem nada de errado nisso, e é assim que eu começo quase tudo que é exploratório aqui.

O que costuma passar batido é que “descrever o que você quer” quase nunca descreve tudo. Sobra uma pilha de decisão que alguém precisa tomar para o código existir, e se você não tomou, o agente tomou. Ele não vai te avisar, porque para ele aquilo não era ambiguidade, era um padrão razoável entre outros.

E o que é spec driven development?

É escrever o contrato antes de pedir o código: o que entra, o que sai, o que acontece nos casos feios e o que explicitamente não é para acontecer. Não precisa de documento formal nem de ferramenta, um bloco de vinte linhas resolve.

A diferença não está no tamanho do texto, está em qual decisão você tirou da mesa do agente. Especificação boa não descreve o algoritmo, ela fecha as escolhas que mudariam o resultado sem quebrar teste nenhum.

Quanto custa escrever a especificação?

Essa era a minha dúvida, então medi. Peguei uma tarefa pequena, agrupar eventos com carimbo de tempo em janelas de N minutos, e mandei duas vezes para o mesmo agente na mesma máquina. Na primeira, uma linha só: “faz uma função Python que agrupa eventos em janelas de tempo, com teste”. Na segunda, o enunciado inteiro, com formato de entrada, formato de saída, alinhamento das bordas e a lista de casos de teste.

Onze segundos. É essa a diferença de tempo do agente entre a versão vaga e a especificada, e ela é ruído. O custo do spec driven não está no agente, está nos poucos minutos que você gasta escrevendo o contrato, e é por isso que a discussão sobre qual é “mais rápido” quase sempre mede a coisa errada.

Que decisões o pedido vago entregou de graça?

Sete, e eu listei uma por uma olhando o código que voltou. Nome da função em inglês, tamanho da janela recebido como timedelta em vez de minutos, entrada esperando objeto de data já pronto em vez de texto, saída como lista de listas em vez de janelas com início e fim, evento na borda caindo na janela seguinte, teste com unittest em vez de pytest, e três casos de teste em vez de sete.

Nenhuma dessas sete é errada. Todas são escolhas defensáveis, e é exatamente isso que faz elas serem perigosas: não tem erro para o revisor achar, tem uma decisão que alguém precisava tomar e que ninguém registrou.

Qual dessas decisões dói de verdade?

A da âncora da janela. No pedido vago, o agente ancorou os blocos no primeiro evento da lista, então a primeira janela começa exatamente no horário do evento mais antigo que apareceu. Faz todo sentido lendo o código, e é indefensável em relatório.

Se você rodar a mesma agregação no recorte de ontem e no recorte da semana, o primeiro evento muda, as bordas se deslocam, e os dois relatórios do mesmo período param de ser comparáveis. O número não fica errado, fica incomparável, que é pior, porque ninguém desconfia de gráfico que continua bonito.

E não existe teste que pegue isso. O agente escreveu três testes, todos passando, todos coerentes com a âncora que ele mesmo escolheu. Teste confere se o código faz o que o autor quis, e aqui o autor era ele.

Então spec driven é sempre melhor?

Não, e no meu processo os dois convivem por dia. Uso vibe coding para explorar, para descobrir se uma ideia é viável, para protótipo que eu já sei que vou jogar fora, e nesses casos escrever contrato antes é desperdício puro, porque o objetivo é aprender e não é manter.

O que eu não faço mais é deixar código de vibe coding virar fundação sem passar pelo contrato depois. A regra que eu uso é simples: se outra parte do sistema vai depender daquilo, ou se algum número dali vai parar na frente de alguém que decide, escrevo a especificação. Se é rascunho, toca o barco.

Como eu escrevo uma especificação que vale o tempo?

Curta e focada nas bordas, não na explicação do algoritmo. O agente sabe programar melhor que a sua descrição do algoritmo, mas ele não tem como adivinhar o que o seu negócio considera certo.

Na prática eu cubro quatro coisas. O formato exato de entrada e de saída, com um exemplo pequeno de cada um. O que fazer no caso vazio, no caso de um item só e na borda. Um exemplo com valor feio, aquele que não divide bonito, porque é sempre nele que as interpretações se separam. E a lista de casos de teste, escrita como lista mesmo, porque agente escreve o teste que você nomear.

O exemplo feio é o detalhe que muda tudo. Na minha primeira versão do enunciado eu usei janela de 15 minutos, que divide o dia inteiro, e por isso duas âncoras completamente diferentes davam o mesmo resultado e o buraco ficou escondido. Trocando para 13 minutos, a divergência aparece na hora.

Isso muda dependendo do agente que eu uso?

Muda o resultado, não muda o mecanismo. Eu rodei essa mesma tarefa especificada no Claude Code e no Codex, e os dois passaram nos testes um do outro e mesmo assim ancoraram a janela em pontos diferentes, um no epoch e outro na meia-noite.

Ou seja, dois agentes com a mesma especificação incompleta produzem duas respostas certas e incompatíveis. Isso vira até uma ferramenta: quando eu quero saber se o meu contrato está fechado, rodo nos dois e olho se convergem. Divergiu, o buraco é meu.

O que perguntam sobre vibe coding e spec driven?

Especificar não engessa o agente? Engessa a decisão que é sua, e é para isso que serve. O agente continua livre para escolher estrutura de dado, nome de variável e forma de implementar, que é onde ele é bom mesmo.

Dá para especificar sem saber programar? Dá, e é onde a maioria erra o alvo achando que precisa de vocabulário técnico. Especificação é sobre comportamento: o que entra, o que sai, o que acontece quando não tem nada, o que acontece no caso estranho. Isso é regra de negócio, não é sintaxe.

Quanto tempo eu gasto escrevendo isso? Aqui, entre três e dez minutos para uma função, e uma hora para um módulo inteiro. Comparado com achar meses depois que o relatório está incomparável, é barato, mas isso varia para cada um e depende de quanto o seu código precisa durar.

E se eu já tenho um monte de código feito no vibe? Não precisa reescrever nada. Eu pego os pedaços que viraram fundação, escrevo o contrato deles depois do fato, e uso esse contrato como enunciado para o agente gerar os testes que faltavam. Aí as decisões silenciosas viram teste e param de ser silenciosas.