As formas de pedir para a IA escrever código estão se diversificando rapidamente.
De um lado, está o vibe coding: criar de forma improvisada por meio de conversas. Do outro, está o tema deste artigo, o Spec Driven Development (SDD).
Em uma frase: o SDD define primeiro a especificação (spec) em um documento antes de solicitar o código.
Esse documento se torna a única fonte de verdade e orienta a IA no planejamento, na implementação e na validação.
Este artigo explica como o SDD funciona, suas principais ferramentas, spec-kit e Kiro, e quando usá-lo em vez de vibe coding. As informações sobre as ferramentas são de agosto de 2026.
Vamos começar pelo resumo dos pontos principais.
- O SDD define primeiro “o que construir” em um documento spec e trata o código como seu resultado.
- O fluxo tem quatro etapas: spec (requisitos) → plan (design técnico) → tasks (divisão do trabalho) → implementação.
- O spec-kit, do GitHub, e o Kiro, da AWS, são ferramentas de destaque que implementam esse fluxo.
- A divisão geral é: vibe coding para protótipos e SDD para código de produto que será mantido por muito tempo.
Por que as especificações voltaram
A ideia de escrever a documentação antes de desenvolver não é nova. As especificações de requisitos da época do modelo cascata faziam exatamente isso, mas foram deixadas de lado pelo Agile por serem pesadas demais.
A chegada dos agentes de IA mudou a situação. Desenvolvedores humanos fazem perguntas e completam o contexto mesmo quando recebem requisitos ambíguos.
Já a IA preenche as lacunas com suposições plausíveis quando recebe um prompt ambíguo. O resultado não corresponde aos requisitos, mas parece correto: o tipo mais problemático de defeito.
Isso gerou a necessidade de “eliminar a ambiguidade antes de delegar o trabalho à IA”, e as especificações voltaram como resposta. A diferença agora é que o documento serve como critério de execução para a IA, não apenas como algo que pessoas leem.
O pipeline de quatro etapas, de spec a tasks
Os nomes variam um pouco entre as ferramentas, mas a estrutura é a mesma.
| Etapa | Resultado | O que é definido |
|---|---|---|
| Specify | spec.md | O que construir e por quê (requisitos · cenários) |
| Plan | plan.md | Como construir (stack tecnológico · arquitetura) |
| Tasks | tasks.md | Em que ordem construir (divisão em unidades de trabalho) |
| Implement | Código | Implementar cada task em ordem |
Há duas regras fundamentais.
Primeiro, só avance para a etapa seguinte depois que uma pessoa revisar e aprovar o resultado anterior. Assim, a ambiguidade é filtrada na documentação antes de chegar ao código.
Segundo, se os requisitos mudarem durante a implementação, altere spec, não o código, e refaça as etapas seguintes. spec precisa ser sempre a verdade mais atual.
Visto pelo lado oposto: o código já não é a origem, mas o resultado de compilar spec. A verdadeira fonte é a documentação.
Duas ferramentas: spec-kit e Kiro
O spec-kit, do GitHub, é um toolkit de código aberto que não depende de um agente específico.
Ele adiciona os comandos de barra /specify, /plan e /tasks sobre Claude Code, Copilot, Gemini CLI e outros, impondo o pipeline acima.
Outra característica é o documento constitution, que contém os princípios imutáveis do projeto.
O Kiro, da AWS, é um IDE agêntico projetado desde o início em torno do SDD. Ele cria três documentos: requirements.md, design.md e tasks.md.
Seu ponto forte é a notação de requisitos. Ele estrutura os requisitos usando a notação EARS (Easy Approach to Requirements Syntax).
O método organiza os requisitos em frases como “O sistema deve ~ em uma situação ~”.
Se você já usa um agente de uso geral como o Claude Code, adicionar o spec-kit tem um custo de adoção menor. Se quer uma experiência integrada ao IDE, o Kiro é mais adequado.
A diferença em relação ao vibe coding
O SDD nem sempre é a escolha certa. Criar e revisar três documentos tem um custo real; aplicá-lo a um protótipo de fim de semana ou a um script descartável pode acabar sendo mais trabalhoso que o próprio projeto.
O critério é a vida útil do código. Se ele pode ser descartado nesta semana, itere rapidamente com vibe coding.
Se o código será mantido e expandido por vários meses ou mais, eliminar primeiro a ambiguidade com SDD reduz o custo total.
Também há um ponto de atenção na operação: o drift, quando spec e código ficam desalinhados.
Quando a regra “mudanças de requisitos devem começar sempre por spec” é quebrada, spec vira um documento em que ninguém confia. Então o SDD inteiro se reduz a uma formalidade.
Resumo
No fim, o SDD afirma que “a verdadeira linguagem de programação na era da IA são as especificações em linguagem natural”. Ele transforma a comunicação de intenção, antes resolvida com uma linha de prompt, em um documento que pode ser revisado.
Antes de escrever um prompt para a próxima funcionalidade, experimente escrever primeiro um documento spec. Em um dia, você poderá decidir se essa metodologia se adapta ao seu trabalho.