Spec Driven Development: o próximo passo depois do vibe coding

Andrej Karpathy apresentou o termo “vibe coding” em fevereiro de 2025. Um ano depois, ele mesmo admitiu que essa era estava chegando ao fim — e que estamos entrando na era da engenharia agêntica: orquestrar agentes contra especificações detalhadas com supervisão humana.

Não porque a IA ficou menos capaz. Mas porque o modo como estávamos usando ela começou a mostrar suas rachaduras.

O problema que ninguém queria falar

Quando os agentes de IA chegaram ao desenvolvimento de software, a promessa era sedutora: descreva o que você quer e receba código funcionando em segundos.

E funcionava, até certo ponto.

Para scripts rápidos, protótipos descartáveis, provas de conceito isoladas, o vibe coding entrega. O problema aparece quando o projeto cresce. Quando você precisa de código que respeite arquitetura, regras de negócio, padrões do time e decisões tomadas semanas atrás.

Estudos publicados em 2025 mostraram que LLMs geram código vulnerável em taxas que variam entre 9,8% e 42,1% dependendo do benchmark. Em fevereiro de 2026, o número de problemas introduzidos por IA em repositórios de produção já havia superado 110.000.

Três falhas se repetem:

Intent drift — um prompt como “adicione login” é drasticamente subespecificado. O modelo faz escolhas razoáveis que raramente correspondem ao que o time de fato queria.

Context decay — conforme o projeto cresce além da janela de contexto efetiva do agente, ele esquece decisões anteriores e silenciosamente as contradiz.

Unverifiable output — sem critérios de aceite explícitos, não há como saber se o código gerado está certo. Ele apenas parece certo.

É exatamente aqui que entra o Spec Driven Development.

O que é Spec Driven Development

Spec Driven Development é uma abordagem em que a especificação, e não o código, é o artefato central do desenvolvimento.

A ideia é simples: antes de pedir para um agente de IA escrever qualquer linha de código, o desenvolvedor cria uma spec clara, estruturada e revisada sobre o que precisa ser construído. Essa spec não é um comentário solto no chat. Ela é um documento técnico versionado que descreve objetivo, contexto, regras de negócio, arquitetura esperada, padrões de código, validações, fluxos e critérios de aceite.

O agente deixa de receber uma intenção vaga. Ele passa a receber uma direção técnica.

A qualidade do que a IA gera é diretamente proporcional à qualidade da especificação que você escreve.

Existem três níveis de maturidade dentro do SDD:

Nível Descrição Spec-first Spec escrita antes do desenvolvimento, usada para guiar o agente Spec-anchored Spec mantida após a tarefa, servindo como referência para evolução e manutenção Spec-as-source Spec é o artefato principal; humano edita apenas a spec, código é derivado dela

Como escrever uma boa spec

Uma boa spec não precisa ser um documento de 30 páginas. Ela precisa responder às perguntas que a IA vai fazer se você não responder antes.

Addy Osmani define os elementos essenciais:

Contexto do projeto: qual é a arquitetura, quais tecnologias, quais padrões já existem.

Objetivo da funcionalidade: o que precisa ser construído e por quê.

Entidades e modelos: quais objetos de domínio estão envolvidos e como se relacionam.

Regras de negócio: o que é obrigatório, o que é opcional, o que é proibido.

Restrições técnicas: limites de design, integrações existentes, padrões que precisam ser seguidos.

Critérios de aceite: como você vai saber que a implementação está correta.

Testes necessários: quais cenários precisam de cobertura.

Compare os dois extremos:

Sem spec:
"Crie uma funcionalidade de cadastro de empresa."

Com spec:
Contexto: API REST em .NET 8 seguindo Clean Architecture com CQRS.
Objetivo: Implementar o cadastro de empresa com validação de CNPJ único.
Entidades: Company (Id, TradeName, LegalName, Cnpj, CreatedAt).
Regras: CNPJ deve ser único no sistema. Razão social é obrigatória.
          Nome fantasia é opcional. CNPJ deve passar na validação de dígitos verificadores.
Arquitetura: Command > Handler > Repository. Usar FluentValidation.
Critérios de aceite:
  - POST /companies retorna 201 com empresa criada
  - POST /companies com CNPJ duplicado retorna 409
  - POST /companies com CNPJ inválido retorna 422
Testes: unitários no handler, integração no endpoint.

A diferença no resultado gerado é proporcional à diferença na especificação.

O fluxo na prática com Claude Code

O SDD muda a sequência do trabalho. Não começa pelo código. Começa pela especificação.

1. Entender a necessidade
         ↓
2. Escrever a spec (objetivo, contexto, regras, arquitetura, critérios de aceite)
         ↓
3. Revisar a spec antes de abrir o editor
         ↓
4. Entregar a spec ao Claude Code
         ↓
5. Claude Code analisa o projeto existente
         ↓
6. Claude Code propõe um plano de implementação
         ↓
7. Desenvolvedor revisa e aprova o plano
         ↓
8. Implementação em etapas (domínio → aplicação → infraestrutura → API → testes)
         ↓
9. Rodar testes, build e validações
         ↓
10. Revisar código gerado contra a spec
         ↓
11. Ajustar spec ou solicitar correções se necessário
         ↓
12. Finalizar com documentação e commit

A diferença prática: em vez de corrigir código gerado por tentativa e erro, você revisa um plano antes de qualquer linha ser escrita. E quando algo sai errado, você volta para a spec, não para o prompt.

O ecossistema em 2026

O SDD deixou de ser uma ideia experimental. Em 2026, praticamente todas as ferramentas relevantes de desenvolvimento com IA incorporaram alguma forma dessa abordagem.

Ferramenta Empresa Abordagem Spec Kit GitHub Specs versionadas integradas ao repositório Kiro AWS Fluxo nativo de spec-first Cursor Anysphere Suporte a documentos de especificação Claude Code Anthropic Plan mode + specs em Markdown BMAD Comunidade Framework de spec para agentes Tessl Tessl Spec como fonte primária de verdade OpenSpec Comunidade Especificação aberta para agentes

A DeepLearning.AI lançou um curso dedicado ao tema. A Birgitta Böckeler publicou análises comparando as ferramentas. O Addy Osmani escreveu sobre como escrever boas specs para agentes.

O mercado reconheceu o problema e começou a construir soluções ao redor dele.

O novo papel do desenvolvedor

O SDD não elimina o desenvolvedor. Ele muda o centro de gravidade do trabalho.

Antes, o valor estava em saber escrever código. Hoje, o valor está em saber especificar o problema com precisão. Isso exige entendimento de negócio, visão de arquitetura, capacidade de antecipar edge cases, clareza para documentar decisões e julgamento para revisar o que foi gerado.

São habilidades que bons desenvolvedores sempre tiveram. O SDD apenas as coloca no centro do processo em vez de tratá-las como atividade secundária.

A metáfora que mais gosto: o desenvolvedor deixa de ser apenas o operário que constrói e passa a ser também o arquiteto que projeta. A IA é o executor técnico de uma especificação previamente pensada por um ser humano.

Por onde começar

Se você quer experimentar SDD hoje, a entrada mais simples é esta:

Pegue a próxima feature que você for desenvolver. Antes de abrir o editor ou escrever o primeiro prompt, escreva um arquivo Markdown com o objetivo, as regras de negócio, a arquitetura esperada e os critérios de aceite.

Não precisa ser perfeito. Precisa ser explícito.

Leve esse documento para o seu agente de IA, peça para ele analisar o projeto e propor um plano de implementação. Revise o plano. Só então deixe o código ser gerado.

A diferença no resultado vai ser imediata.

Conclusão

Vibe coding foi o primeiro contato. Spec Driven Development é a maturidade.

Não são abordagens opostas: o vibe coding ainda funciona para prototipação rápida e exploração. O SDD entra quando você precisa de código que vai para produção, que outros vão manter, que precisa ser correto, não apenas plausível.

A IA não vai substituir o desenvolvedor que sabe especificar, revisar e orientar a construção de software. Ela vai substituir quem acha que mandar um prompt vago e aceitar o resultado é suficiente.

A pergunta não é mais “você sabe programar?” A pergunta passou a ser: “você sabe especificar o que precisa ser construído com precisão suficiente para que uma IA execute bem?”

Essa resposta ainda precisa vir de um ser humano.

Você já usa alguma forma de SDD no seu fluxo de trabalho? Quais elementos da spec você considera mais críticos? Deixa nos comentários.

Referências

• Yan et al. (2025) — Spec-Driven Development: From Code to Contract in the Age of AI — ArXiv
• Addy Osmani — How to write a good spec for AI agents
• Martin Fowler — Understanding SDD: Kiro, spec-kit, and Tessl
• DeepLearning.AI — Spec-Driven Development with Coding Agents
• Augment Code — What Is Spec-Driven Development?
• Towards Data Science — From Vibe Coding to SDD
• Thoughtworks — Spec-driven development: Unpacking 2025’s key new AI-assisted practice
• InfoWorld — Vibe coding or spec-driven development? How to choose
• BCMS — Spec-Driven Development (SDD): The Definitive 2026 Guide
• Medium PT — Spec Driven Development: a abordagem que melhorou meu desenvolvimento com IA