Todo mundo que testou um agente de codificação em 2024 ou 2025 já viveu a mesma cena: você descreve o que quer em duas frases, o agente entrega um código que parece funcionar, os testes passam. Três sprints depois, ninguém mais sabe por que aquele trecho existe. Esse padrão ganhou até apelido, “vibe coding”, e é justamente o problema que o Spec-Driven Development (SDD) se propõe a resolver. Em vez de deixar a intenção do projeto viver só na cabeça de quem escreveu o prompt, o SDD transforma a especificação em um contrato versionado, revisável e executável, que humanos e agentes de IA compartilham como fonte única de verdade.
Por que o vibe coding parou de escalar
O GitHub descreve bem a origem do problema: agentes de codificação são excelentes em reconhecer padrões, mas péssimos em preencher lacunas de ambiguidade sozinhos. Tratados como motor de busca (“faz aqui uma tela de login”), eles produzem algo plausível. Tratados como pares de programação literais, que seguem instruções explícitas, produzem algo confiável. Essa diferença não vem do modelo por trás do agente, vem do que existe, ou não existe, antes do primeiro prompt.
Foi para fechar essa lacuna que nasceu o Spec Kit, toolkit open source do próprio GitHub lançado em setembro de 2025. Hoje ele já passa de 117 mil estrelas no repositório, um crescimento raro para uma ferramenta de processo, não de produto. O Spec Kit organiza o trabalho em quatro fases: Specify (gerar a especificação a partir da necessidade real), Plan (definir stack e arquitetura), Tasks (quebrar em unidades pequenas e revisáveis) e Implement (executar mudanças focadas guiadas pelas fases anteriores). A lógica separa intenção, que muda pouco, de implementação, que muda o tempo todo.
O que é, de fato, uma especificação no Spec-Driven Development
A definição mais precisa que encontrei vem da Thoughtworks: Spec-Driven Development é “um paradigma de desenvolvimento que usa especificações de requisitos de software bem elaboradas como prompts, apoiado por agentes de codificação de IA, para gerar código executável”. Na prática, é um artefato vivo, não documentação arquivada numa wiki que ninguém lê: define comportamento externo (entradas, saídas, pré-condições, pós-condições, invariantes) em linguagem de domínio, não em jargão de implementação. Muitos times usam a estrutura Given/When/Then para descrever cenários, o mesmo vocabulário que quem já trabalhou com BDD reconhece de longe.
Isso não significa que o problema está resolvido. A própria Thoughtworks é honesta sobre os limites: geração de código a partir de spec não é determinística, “spec drift” ainda acontece (a especificação e o código se desalinham com o tempo) e a indústria segue sem consenso sobre qual dos dois deveria ser o artefato primário do software. SDD reduz o problema do vibe coding, não o elimina por completo.
Onde a perda de informação realmente acontece
Um ponto que a Microsoft detalha bem é onde, exatamente, a intenção se perde num projeto de software. São quatro handoffs: da necessidade do stakeholder para o requisito, do requisito para a arquitetura, do design para a implementação e da implementação para a validação. Cada handoff sem um artefato compartilhado vira um exercício de interpretação, e cada interpretação é uma chance de o agente (ou o desenvolvedor júnior, sejamos justos) entender errado.
O caso prático citado pela Microsoft chamou minha atenção: em times que adotaram a spec como fonte única de verdade, o tempo de onboarding de novos integrantes caiu de duas ou três semanas para poucos dias, porque a pessoa nova não precisa mais reconstruir o contexto perdido em decisões de arquitetura tomadas há seis meses: ela lê a spec.
Quando toda ferramenta grande faz a mesma aposta
O que separa uma tendência real de um modismo passageiro costuma ser simples de checar: quantos concorrentes independentes chegaram à mesma conclusão sem copiar um do outro. Em 2026, a lista de ferramentas de codificação com IA que lançaram sua própria versão de SDD inclui:
- GitHub Spec Kit, com foco em fluxo de quatro fases integrado a Copilot, Claude Code e Gemini CLI
- AWS Kiro, voltado a times que já operam em ambiente AWS
- OpenSpec e BMAD-METHOD, projetos open source independentes com abordagens próprias de spec versionada
- Cursor, com regras de projeto embutidas no editor (.cursor/rules)
- Tessl e Google Antigravity, com propostas de spec como infraestrutura operacional, não só documento de planejamento
A DeepLearning.AI já tem um curso dedicado ao tema, “Spec-Driven Development with Coding Agents”. Quando uma prática de engenharia vira conteúdo de currículo formal, ela deixou de ser experimento de early adopter.
O momento do mercado brasileiro
No Brasil, o pano de fundo ajuda a explicar por que esse assunto vai bater na porta dos times de engenharia mais cedo do que parece. Segundo levantamento da IDC citado pelo IT Forum, 53% das organizações brasileiras já apontam IA generativa como prioridade estratégica para 2026, e o Gartner projeta que 40% das aplicações corporativas terão agentes de IA incorporados até o fim do ano, um salto em relação a menos de 5% em 2025. O Plano Brasileiro de Inteligência Artificial prevê R$ 23 bilhões em investimentos até 2028.
Consultorias locais como a Mind Group relatam ganhos de produtividade de até 55% em times que usam assistência de IA para codificação, sem perda de qualidade, e redução de custos entre 20% e 40% conforme o tipo de projeto. Vale o alerta: são números de case comercial, não de estudo acadêmico independente, mas sinalizam para onde o mercado está olhando.
Ainda assim, vale um alerta importante para quem só acompanha imprensa tech brasileira mainstream: nas buscas feitas para este texto, sites como Tecnoblog, Canaltech, TecMundo e MacMagazine praticamente não têm cobertura direta sobre Spec-Driven Development. É um tema tratado hoje quase inteiramente em fontes internacionais (GitHub, Microsoft, Thoughtworks) e em blogs de consultoria de IA no Brasil. A disciplina já está mudando engenharia de agentes na prática; só ainda não virou pauta de tecnologia de massa por aqui.
O que muda no dia a dia ao adotar Spec-Driven Development
Adotar SDD não exige trocar de ferramenta amanhã. Exige mudar um hábito antes de abrir o editor: escrever a spec (o que o sistema deve fazer, quais são as entradas e saídas esperadas, o que não pode quebrar) antes de escrever o primeiro prompt de implementação. Times que já usam Claude Code ou GitHub Copilot no dia a dia podem experimentar o fluxo de quatro fases do Spec Kit num único módulo pequeno antes de expandir para o projeto inteiro. É um investimento de algumas horas por sprint que, segundo os relatos analisados aqui, se paga rápido em menos retrabalho e menos código regenerado do zero.
A pergunta que fica não é mais “os agentes conseguem escrever código de produção sozinhos?”. É outra: quem vai escrever a especificação que eles seguem, e quão bem escrita ela vai estar? Em 2026, essa segunda pergunta importa mais para a qualidade do software do que a escolha do modelo por trás do agente.