Do vibe à especificação
Em 2 de setembro de 2025 o GitHub lançou o Spec Kit, de código aberto, e explicou por quê. O vibe coding pode ser ótimo para protótipos rápidos, mas é bem menos confiável em aplicações sérias e em código que já existe. O Spec Kit trabalha em quatro fases: especificar o que se constrói e por quê, planejar a abordagem técnica, quebrar em tarefas pequenas e testáveis e só então implementar. Nas palavras do GitHub, a fonte da verdade deixa de ser o código e passa a ser a intenção (GitHub). O Kiro, da Amazon, e o Tessl seguem caminhos parecidos.
O que a especificação precisa ter
No livro eu mostro isso num salão de manicure que passou a aceitar vários telefones por cliente. A ordem “acrescente à tabela um segundo campo e ao formulário um botão” descrevia dois elos dos sete, e os outros cinco se romperam. A intenção soaria diferente: a cliente pode informar vários números e marcar o principal; o lembrete vai para o principal; as clientes antigas mantêm os números depois da migração; a exportação do contador abre; todas as verificações ficam verdes (capítulo “Um objetivo em vez de uma instrução”). Dá para percorrer a cadeia no experimento “Sete elos por trás de um telefone”.
Além do objetivo, uma boa intenção tem limites: o que não se pode fazer nem pela vitória e onde o agente deve parar e reportar (mesmo capítulo). Limites rendem mais escritos como proibições (capítulo “Arquitetura como sistema de proibições”). O lugar de costume é o AGENTS.md, arquivo que o agente lê no começo de cada sessão e que, segundo o agents.md, mais de 60 mil projetos de código aberto usam (mesmo capítulo).
O que a especificação não resolve
Em outubro de 2025 Birgitta Böckeler, da Thoughtworks, testou Kiro, Spec Kit e Tessl e anotou onde eles empacam. O Kiro transformou a correção de um bug pequeno em quatro histórias de usuário com 16 critérios de aceitação. O Spec Kit gerou uma pilha de markdown, e ela escreveu que preferia revisar código a todos aqueles arquivos. E, apesar dos checklists, o agente às vezes pulava instruções e recriava classes que o projeto já tinha (site de Martin Fowler).
Isso não me surpreende. Uma regra num arquivo de texto é um pedido, e numa sessão longa o agente pode esquecê-la (capítulo “Arquitetura como sistema de proibições”). A especificação funciona quando os seus itens viram verificações e quando os testes são escritos ou aprovados por outro, e não pelo agente que escreve o código (capítulo “O agente engana o teste”). E o plano deve ser lido antes do trabalho, enquanto o agente ainda não apagou nada (capítulo “Um objetivo em vez de uma instrução”). Formular a tarefa de um jeito que não dê para entender de duas formas é o primeiro módulo do meu curso de vibe coding.
