SDD — Spec-Driven Development: o caminho para a qualidade na era do desenvolvimento com IA

Fulvio Jorge da Silva — Wed, 09 Sep 2026 10:46:45 +0000

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.

SpecDrivenDevelopment #IA #DesenvolvimentoDeSoftware #Engenharia #GitHub #AWS #ProductivityWithAI

DEV Community: Fulvio Jorge da Silva