Por quase dois anos, o vibe coding foi vendido como o futuro do desenvolvimento. A promessa era sedutora: descreva o que você quer em linguagem natural, deixe o modelo gerar o código e repita o ciclo até funcionar. Para um protótipo de fim de semana, funciona muito bem. Em uma base de código real, a conta começa a não fechar. O que parecia velocidade vira retrabalho, porque a intenção do sistema nunca foi registrada em lugar nenhum, apenas em uma conversa que se perde no histórico do chat.
O Spec-Driven Development, ou desenvolvimento guiado por especificação, entra exatamente nesse ponto de dor. A ideia inverte a hierarquia habitual. Em vez de o código ser a verdade e a documentação um resumo escrito depois, a especificação passa a ser a fonte de verdade, e o código existe para servir a ela. Ferramentas como o Spec Kit, aberto pela GitHub em setembro de 2025, e o Kiro, da AWS, transformaram esse conceito em um fluxo concreto que agentes de IA conseguem seguir.
Chamar isso de novidade radical seria exagero. Especificar antes de construir é um princípio tão antigo quanto a engenharia de software. O que mudou é o motivo pelo qual ele voltou a importar. Quando quem escreve o código é um agente incansável que faz exatamente o que o contexto permite, a qualidade da especificação deixa de ser boa prática e vira o fator que decide o resultado. Vale entender o que de fato está por trás da sigla, porque a lição serve para qualquer time que hoje coloca IA para programar.
O que é vibe coding e por que ele trava
O termo vibe coding ganhou o mundo em 2025 para descrever o ciclo de escrever um prompt, receber código, aplicar um remendo e repetir. É rápido e prazeroso enquanto o problema é pequeno. O limite aparece quando o sistema cresce. Sem um registro do que foi decidido e por quê, cada nova alteração parte de uma leitura frágil do que já existe. O agente reescreve o que não devia, quebra o que funcionava e o desenvolvedor gasta mais tempo revisando do que ganharia escrevendo. A sensação de produtividade era real, mas escondia o custo que se acumulava na próxima iteração.
A inversão: a especificação como fonte de verdade
O Spec-Driven Development propõe um fluxo em etapas, cada uma um artefato que a etapa seguinte lê. No Spec Kit, o ciclo é Specify, Plan, Tasks e Implement. Primeiro você descreve o que construir e por quê, em termos de usuário, sem tecnologia. Depois adiciona o como: arquitetura, bibliotecas, modelo de dados e restrições. Em seguida o plano vira uma lista de tarefas discretas, e só então o agente implementa. Há ainda os arquivos de constituição, que guardam princípios e convenções do projeto para orientar o comportamento da IA em todo código gerado. O Spec Kit funciona com Copilot, Claude Code, Gemini CLI, Cursor e outros, e virou um dos repositórios de ferramentas para desenvolvedores que mais cresceram no período.
Kiro, EARS e o artefato versionado
O Kiro, da AWS, chega ao mesmo princípio por um caminho próprio. Ele gera três documentos que juntos formam a especificação: um de requisitos, escrito na notação estruturada EARS, um de design com arquitetura e diagramas, e um de tarefas com o plano de implementação rastreável. A vantagem estrutural é simples e poderosa. A especificação é um artefato versionado, não uma conversa efêmera. Quando o requisito muda, você atualiza o arquivo, e a decisão não desaparece no histórico. Ao desenhar requisito e arquitetura antes, com consciência da base de código, o agente acerta de primeira com mais frequência, o que significa menos ciclos de correção e menos ruído.
Onde a ilusão mora
Seria ingênuo tratar o Spec-Driven Development como bala de prata. Ele adiciona cerimônia, e cerimônia tem custo. Para um script descartável, escrever três documentos antes de codar é desperdício. O ganho aparece onde o retrabalho é caro, em bases reais, com times e continuidade. Há também um limite honesto: a especificação só vale pelo pensamento que a sustenta. Uma spec vaga gera código ruim mais rápido, não código bom. A ferramenta organiza a intenção, mas não pensa pelo autor. Trocar o vibe coding por um ritual burocrático, preenchido no automático, apenas move o problema de lugar.
O caso condensa uma verdade que atravessa toda a engenharia. A alavanca nunca esteve em prompt melhor, e sim em pensamento mais claro tornado explícito. O vibe coding deu a impressão de que dava para pular essa etapa, e a fatura chegou na forma de retrabalho. O Spec-Driven Development não mata a criatividade nem impõe processo pesado por processo. Ele externaliza a intenção para que humanos e agentes compartilhem a mesma fonte de verdade, do requisito à implementação.
A maturidade, aqui, é saber dosar. Especificar o que tem risco e continuidade, deixar fluir o que é exploração descartável, e nunca confundir o preenchimento de um template com a clareza que ele deveria capturar. Um agente faz o que a especificação permite. Se a especificação é rasa, o resultado será raso com mais eficiência. Ao colocar agentes para programar a partir de uma spec, uso o Claude para transformar requisitos em plano e tarefas, revisar a arquitetura antes da implementação e manter a decisão sempre sob controle humano. A pergunta que sobra não é se a IA vai escrever o código, mas se você deu a ela uma verdade clara para seguir. Para conversas sobre engenharia, IA aplicada e arquitetura de software, acompanhe o Canal Nexa e a Seleção Vip.