A IA já escreve código. Muito código. Em poucos meses, "pedir para o agente fazer" virou parte do dia a dia de qualquer time de engenharia. Mas há um detalhe incômodo: a IA escreve rápido, e escreve confiante — inclusive quando está errada. Times maduros começam a perceber que o gargalo deixou de ser digitar código e passou a ser garantir que o código faz o que precisa fazer. É aqui que entra o Spec-Driven Development.
O problema do "vibe coding"
A primeira geração de uso de IA em desenvolvimento ficou conhecida como vibe coding: você descreve a intenção em linguagem natural, o agente gera o código, você ajusta, repete. Funciona para protótipos. Mas em sistemas reais aparecem três sintomas crônicos:
Requisitos implícitos viram bugs. O que estava "óbvio" na cabeça de quem pediu não estava no prompt.
Context pollution. O agente lê milhares de linhas de código tentando deduzir o que você quer e alucina nas lacunas.
Drift. A cada nova sessão, o agente "esquece" decisões anteriores. Pequenas inconsistências se acumulam até virarem retrabalho.
O que é Spec-Driven Development
Spec-Driven Development (SDD) inverte a relação tradicional entre código e documentação. Em vez da especificação ser um anexo que envelhece esquecido em algum Confluence, ela passa a ser a fonte da verdade. O código é o artefato derivado — gerado e validado contra o contrato.
A frase que resume a filosofia, cunhada pelo time do GitHub Spec Kit: "specifications do not serve code — code serves specifications".
Para um agente de IA, isso muda tudo. Em vez de inferir intenção a partir de prompts soltos, ele recebe um documento estruturado, com critérios de aceitação verificáveis, e implementa contra esse contrato. Os relatórios iniciais de adoção em GitHub e AWS apontam taxa de sucesso na primeira tentativa de 3 a 10 vezes maior em tarefas não-triviais.
Como funciona, na prática
Os dois frameworks mais maduros — GitHub Spec Kit e AWS Kiro — convergem em um fluxo de quatro fases:
1. Specificar. Você escreve o quê e por quê, sem escolher stack. User stories, critérios de aceitação em notação EARS ("When [condição], the system shall [comportamento]"), modelo de domínio. É aqui que o esforço humano rende mais.
2. Planejar. Agora sim, como: stack, arquitetura, decisões técnicas. A spec funcional já está congelada; o plano técnico é um documento separado que pode evoluir sem mexer no contrato.
3. Tasks. O agente decompõe a spec + plano em tarefas pequenas, executáveis, cada uma ligada a um critério de aceitação. Isso é o que torna o trabalho rastreável.
4. Implementar. O agente executa as tarefas. Cada PR é validado contra a spec — testes de contrato, testes E2E cobrindo cada critério EARS, gates de qualidade automáticos.
Quando algo muda, a mudança entra pela spec primeiro. Nunca pelo código direto. É essa disciplina que elimina o drift.
Por que isso importa agora
Três motivos práticos.
O custo de gerar código caiu para perto de zero. O que antes era escasso (linhas de código) virou abundante. O que continua escasso é clareza sobre o que construir. SDD coloca o esforço onde ele rende.
Front-end e back-end andam em paralelo. Quando o contrato (OpenAPI, GraphQL, JSON Schema) existe antes do código, o front-end gera tipos e mocks, o back-end implementa endpoints conformes, e ambos se encontram no CI. Equipes relatam até 75% de redução no tempo de ciclo para mudanças de API, porque incompatibilidades aparecem na revisão da spec, não em produção.
A spec é o melhor contexto para o agente. Sem spec, a IA tem que ler o repositório inteiro tentando entender o sistema. Com spec, ela tem o contrato. O agente fica mais barato, mais rápido e mais preciso — e o humano fica livre para o trabalho de pensar.
O que muda no papel do desenvolvedor
A pergunta que aparece toda vez: "se a IA escreve o código, o que sobra para mim?"
Sobra o mais difícil — e o mais interessante. Modelar o problema. Definir critérios de aceitação que cobrem os edge cases. Revisar specs com olho de quem entende negócio e sistema. Decidir arquitetura. Validar que o resultado faz o que precisa fazer.
O desenvolvedor não desaparece. Ele sobe de nível. Vira o arquiteto da intenção — e delega a implementação para o agente.
Por onde começar
Se você quer experimentar SDD na próxima feature:
- Antes de abrir o editor, escreva um spec.md com user stories e critérios EARS. (Easy Approach to Requirements Syntax ou Abordagem Fácil para a Sintaxe de Requisitos)
- Se for uma API, escreva o openapi.yaml ANTES de codar qualquer endpoint.
- Decomponha em tarefas pequenas e referenciáveis ("T-03 implementa o critério de aceitação X").
- Use o agente de IA com o spec.md anexado como contexto — não como prompt solto.
- Bloqueie merge se algum critério EARS não tiver teste cobrindo.
Para quem quer um cinto de ferramentas pronto: GitHub Spec Kit (open-source, integra com Copilot, Claude Code, Gemini CLI) e AWS Kiro (IDE agêntica com fluxo Requirements → Design → Tasks nativo) são os pontos de partida mais sólidos hoje.
https://github.com/github/spec-kit
Spec-Driven Development não é uma moda nem um framework a mais. É a resposta natural a uma mudança estrutural: o código virou commodity, a intenção virou o produto. Quem dominar essa transição vai entregar mais, com menos retrabalho, e vai manter a qualidade que os times tradicionais demoraram décadas para conquistar — em vez de jogá-la fora em nome da velocidade.
A IA é uma ótima implementadora. Mas alguém ainda precisa dizer o que construir. SDD é como esse "alguém" passa a falar.
Top comments (0)