Spec-Driven Development: origem, metodologia, ferramentas e o que o hype não conta

tl;dr — SDD é uma resposta legítima a um problema real com agentes de IA. O conceito faz sentido, as ferramentas são imaturas, o custo é alto e a evidência de ROI ainda é quase toda anedótica. Vale entender. Vale desconfiar.

O problema que originou tudo isso

Para entender por que Spec-Driven Development surgiu, é preciso voltar um passo.

Em 2025, agentes de IA como Claude Code, Cursor e Codex deixaram de ser autocomplete glorificado e passaram a executar tarefas complexas de forma autônoma. Com isso surgiu o fenômeno do vibe coding: você descreve o que quer em linguagem natural, o agente gera centenas de linhas de código, e você aprova sem entender completamente o que foi feito.

O resultado? Código que funciona até o momento em que precisa ser mantido. Decisões arquiteturais invisíveis. Débito técnico acumulado em velocidade industrial.

O estudo mais rigoroso sobre o tema — conduzido pela METR em 2025 com desenvolvedores experientes em projetos open source reais — concluiu que desenvolvedores usando ferramentas de IA foram, em média, 19% mais lentos do que sem elas. Não mais rápidos. O motivo: prompts não estruturados criavam loops de debugging que consumiam todo o tempo poupado na geração inicial de código.

Spec-Driven Development é a tentativa da indústria de resolver esse problema na raiz.

De onde vem a ideia

A ideia de escrever especificações antes de escrever código não é nova. É tão antiga quanto a própria engenharia de software.

1963: Margaret Hamilton, gerenciando o software das missões Apollo da NASA, cunhou o termo “engenharia de software” porque os programas cresceram além da capacidade de qualquer pessoa de compreendê-los integralmente. Ela percebeu: isso é engenharia, precisa de processo.

1968: A OTAN organizou uma conferência em Berlim que identificou formalmente a Software Crisis: os computadores agora permitiam programas tão complexos que não podiam ser gerenciados adequadamente. O volume de código havia superado a capacidade humana de raciocinar sobre ele.

1972: Dijkstra, em sua aula do Prêmio Turing, resumiu: “Enquanto não havia máquinas, programar não era nenhum problema. Quando tínhamos poucos computadores fracos, programar se tornou um problema leve. Agora temos computadores gigantescos, e programar se tornou um problema igualmente gigantesco.”

A resposta da época foi processo: Waterfall como padrão DoD, depois Agile em 2001, depois CI/CD na nuvem viabilizando o Agile em escala.

Agora estamos no próximo ciclo. Drew Breunig, pesquisador que popularizou o termo SDD em 2026, descreveu com precisão: “Nossa crise de software atual é nossa incapacidade de gerenciar bases de código complexas que os novos modelos permitem. Antes, o problema era que não conseguíamos manter todo o código na cabeça. Agora nem conseguimos ler todo o nosso código.”

Agentes de IA habilitam volume waterfall na cadência do agile. Esse é o problema que SDD tenta endereçar.

O que é Spec-Driven Development

SDD é uma metodologia de desenvolvimento que trata a especificação como o artefato primário — não o código.

Em vez do ciclo tradicional de prompt → código → iteração, o fluxo se torna:

Spec → Plano → Tarefas → Código

A spec define intenção, restrições, critérios de aceitação e arquitetura antes de qualquer implementação. O agente de IA então executa contra essa entrada estruturada em vez de interpretar uma descrição vaga.

Uma distinção importante: com ferramentas como Spec Kit, Kiro e Tessl, a própria spec é gerada pela IA. Você descreve o objetivo em linguagem natural, e o agente produz os arquivos de especificação — tipicamente requirements.md, design.md e tasks.md — que ele mesmo usará como contexto na implementação. A spec não é um documento escrito manualmente upfront por analistas; ela emerge da conversa entre desenvolvedor e agente, ainda antes do código.

Isso muda o diagnóstico de problemas clássicos com especificações: a distância entre spec e código não é mais de semanas ou de equipes diferentes. Spec e código são gerados no mesmo ciclo, pela mesma ferramenta, com poucos minutos de distância. O problema que persiste não é a separação temporal — é o trabalho upfront, o custo de tokens, a degradação do contexto ao longo das iterações, e o que acontece após o deploy quando a realidade diverge do que estava especificado.

Existem diferentes níveis de adoção do SDD:

Spec-first: a spec é gerada antes da implementação e usada como guia para aquela tarefa. Após concluída, é descartada.

Spec-anchored: a spec é mantida após a tarefa para guiar evolução e manutenção futura do sistema. É um artefato vivo que acompanha o código.

Spec-as-source: o nível mais ambicioso. A spec é o código-fonte. O código gerado é apenas um artefato compilado da spec, marcado com // GENERATED FROM SPEC - DO NOT EDIT. Tessl está tentando viabilizar isso.

O Triângulo SDD — e por que o ciclo é mais difícil do que parece

A contribuição mais honesta ao debate veio de Breunig em março de 2026, depois de construir o projeto whenwords (uma biblioteca open source com zero código — apenas spec + 750 testes de conformidade) e observar como outros projetos semelhantes evoluíram.

Seu aprendizado central: SDD não é uma equação linear. É um ciclo de feedback.

Ele propõe o SDD Triangle: spec, testes e código são três nós que precisam estar sincronizados o tempo todo. Quando o código avança, a spec deve ser atualizada. Quando a spec muda, novos testes precisam ser escritos. Quando testes falham, o código precisa mudar — e às vezes a spec também estava errada.

O problema é que manter esses três nós sincronizados é difícil:

• Escrever specs é difícil. Elas nunca são exaustivas e são escritas antes de o software encontrar o mundo real.
• Escrever testes é difícil. Mesmo antes de agentes, ninguém gostava de escrever testes.
• Atualizar specs e testes após a implementação parece overhead, especialmente quando você está usando agentes exatamente para se mover rápido.
• LLMs tomam decisões silenciosas durante a implementação. Essas decisões raramente voltam para a spec.

O resultado prático: a spec é escrita, o código é gerado, o produto é lançado. A spec fica desatualizada em dias. Ninguém volta para atualizá-la. O problema original — intenção perdida, decisões invisíveis — apenas migrou de nível.

O ecossistema de ferramentas

O espaço de ferramentas SDD explodiu entre o final de 2024 e início de 2026. É útil entender as camadas:

Camada 1 — Frameworks de spec: definem e gerenciam os artefatos de especificação → Spec Kit, Tessl, Kiro, BMAD, OpenSpec, cc-sdd

Camada 2 — Sistemas de planejamento e tarefas: convertem specs em grafos de tarefas executáveis → Taskmaster, Agent OS, Beads, Feature-Driven-Flow

Camada 3 — Agentes de execução: escrevem e modificam código → Claude Code, Cursor Agent, Codex, Devika, OpenDevin, CrewAI

Camada 4 — IDEs com IA: integram todas as camadas em um único workflow → Kiro, Windsurf, Cursor, Claude Code, Copilot

A maioria dos desenvolvedores hoje usa apenas a Camada 3 — é exatamente onde o problema do vibe coding vive.

Tabela de ferramentas relevantes

Como usar na prática: Kiro como exemplo

Kiro é o ponto de entrada mais acessível para desenvolvedores já usando VS Code. É um fork do Code OSS (o núcleo open source do VS Code) construído por um time pequeno dentro da AWS, posicionado deliberadamente fora do ecossistema AWS — você não precisa de conta AWS para usá-lo.

Instalação

Acesse kiro.dev e baixe o instalador para seu sistema operacional. Faça login com GitHub ou Google.

O workflow em três etapas

Passo 1 — Requisitos

Você descreve o que quer construir em linguagem natural. Kiro traduz isso para notação EARS (Easy Approach to Requirements Syntax):

WHEN usuário submete formulário de login
  AND credenciais são válidas
THEN sistema deve autenticar o usuário
  AND redirecionar para o dashboard
  AND registrar o evento de login com timestamp

Essa notação força restrições explícitas e legíveis por máquina. Você revisa e ajusta o requirements.md gerado antes de avançar.

Passo 2 — Design

Kiro analisa sua base de código existente e gera um design.md com decisões arquiteturais, escolhas de stack e estrutura de componentes. Para um projeto React + Node.js, você verá algo como:

## Architecture

Frontend: React 18 com React Router v6
Backend: Express 4.x com middleware JWT
Database: PostgreSQL via Prisma ORM
Auth: bcrypt (salt rounds: 12) + JWT (access: 15min, refresh: 7d)
Testing: Jest + Supertest para integração

Você revisa este documento antes de qualquer código ser escrito. Discordâncias com a arquitetura real do projeto são detectadas aqui — não depois de 400 linhas geradas.

Passo 3 — Tarefas

Kiro gera um tasks.md com passos de implementação discretos, sequenciados por dependência:

- [ ] Task 1: Setup de banco de dados e schema de usuários
- [ ] Task 2: Endpoint POST /auth/register com validação Joi
- [ ] Task 3: Endpoint POST /auth/login com geração de tokens
- [ ] Task 4: Middleware de autenticação JWT
- [ ] Task 5: Endpoint POST /auth/refresh
- [ ] Task 6: Testes de integração para todos os endpoints

Você controla quais tarefas executar e quando. O agente implementa uma tarefa por vez, com pontos de revisão entre elas.

Steering files

Além dos três documentos de spec, Kiro suporta steering files — arquivos de configuração persistentes que definem padrões para toda a base de código:

# .kiro/steering/code-style.md
- Use TypeScript estrito, sem `any` implícito
- Prefira `async/await` sobre callbacks
- Nomes de variáveis em camelCase, constantes em SCREAMING_SNAKE_CASE
- Funções públicas devem ter JSDoc

Hooks

Kiro suporta hooks baseados em eventos — agentes que disparam automaticamente em resposta a gatilhos definidos:

{
  "hooks": [
    {
      "name": "security-audit",
      "trigger": "on-save",
      "agent": "Verifique vulnerabilidades de segurança no arquivo salvo"
    },
    {
      "name": "test-generator",
      "trigger": "on-file-create",
      "pattern": "src/**/*.ts",
      "agent": "Gere testes unitários para o novo arquivo"
    }
  ]
}

O que funciona bem

• Revisar um documento de design antes da implementação é fundamentalmente diferente de revisar 500 linhas de código gerado depois. Problemas emergem no nível certo.
• Steering files eliminam um volume enorme de prompts repetitivos sobre estilo e convenções.
• O fluxo de tarefas sequenciais mantém o contexto do agente focado — um problema por vez, não um sistema inteiro.

O que não funciona bem

• Kiro gerou 16 critérios de aceitação para um bug fix simples em testes independentes. Para mudanças pequenas, o overhead é real.
• A geração de spec para features de complexidade moderada leva 30–45 segundos. Isso queima no fluxo de desenvolvimento rápido.
• A notação EARS tem curva de aprendizado. Não é intuitiva para quem nunca trabalhou com especificações formais.
• Kiro usa o registro Open VSX de extensões (não o da Microsoft), o que significa ausência de suporte oficial ao C# — limitação séria para times .NET.
• O modo Autopilot (execução de múltiplas tarefas sem supervisão) produz resultados menos previsíveis. A lógica de aprovação por tarefa é onde o valor real está.

Preços

Durante o preview público: gratuito (com limites de interações). GA: Free (50 interações/mês) · Pro $19/mês (1.000 interações) · Pro+ $39/mês (3.000 interações)

Os problemas reais

1. Trabalho upfront que vai contra o instinto do desenvolvedor

A promessa do SDD com IA é que a spec é gerada rapidamente — e de fato é. Mas “rápido” não significa “grátis”. Antes de qualquer linha de código útil, você passa por múltiplos ciclos de revisão: revisa a spec gerada, corrige intenções mal interpretadas, ajusta o plano arquitetural, aprova ou rejeita tarefas. Cada ciclo exige atenção humana real.

Para uma feature de média complexidade, esse overhead pode ser menor que o custo de debugar código vibe-coded depois. Para um bug fix pontual, o custo supera o benefício por larga margem — Kiro gerou 16 critérios de aceitação para uma correção simples em testes independentes. O trabalho upfront não desaparece porque a IA gera a spec; ele muda de natureza. Em vez de escrever, você revisa e decide. É menos custoso, mas não é zero.

2. Custo de tokens multiplicado em todas as fases

Cada fase do SDD (spec → plano → tarefas → implementação) consome tokens antes de uma linha de código de produção ser escrita. Com modelos de raciocínio, o uso agêntico pode ser 100x maior que o uso padrão.

Sessões pesadas de SDD com Claude Code atingem o limite de contexto regularmente. O processo de compactação automática leva de 3 a 12 minutos. O custo não é só financeiro — é também de tempo e de interrupção de fluxo. Nenhum benchmark público compara o custo total (tokens + tempo de revisão humana) de SDD versus desenvolvimento direto.

3. Degradação do contexto ao longo das iterações

Esse é o problema menos discutido e talvez o mais sério. Specs geradas por IA são alimentadas de volta para a IA na fase de implementação. Cada ciclo de compactação ou reinício de sessão perde nuances. O agente que implementa o código não tem acesso pleno às decisões que o agente de especificação registrou.

O resultado: o código começa a divergir sutilmente da spec à medida que o contexto degrada. O loop entre spec e código, que deveria ser sincrônico, passa a ser uma série de telefones sem fio — cada fase amplifica pequenos ruídos da fase anterior.

4. Specs se tornam enganosas após o deploy

Com ferramentas modernas de SDD, a spec não está “longe do código” — ela é gerada no mesmo ciclo, pela mesma ferramenta, minutos antes da implementação. O problema clássico de especificações escritas por analistas desconectados da realidade técnica não se aplica aqui.

O problema que persiste é diferente: o que acontece depois do deploy. Edge cases só aparecem em produção. Comportamento real do usuário diverge do modelado. Problemas de performance emergem sob carga. A spec não é atualizada. Se ela é usada para guiar manutenção e evolução futura (spec-anchored), uma spec desatualizada torna-se ativamente enganosa: o agente confia nela, gera código baseado numa realidade que já não existe, e o desenvolvedor só percebe quando o sistema quebra.

A ferramenta Plumb de Breunig tenta endereçar isso: um CLI que se conecta ao git commit, lê os traces do agente, extrai decisões tomadas durante a implementação e pede aprovação do desenvolvedor antes de atualizar a spec. É um PoC, não produção — mas aponta na direção certa.

5. Proliferação de artefatos sem curadoria real

Cada feature gera múltiplos arquivos markdown. A promessa implícita de que “o agente mantém a spec atualizada” não se sustenta — alguém precisa revisar cada mudança na spec com o mesmo rigor que revisa o código. Na prática, isso não acontece. As specs acumulam, divergem do código, e passam a ser ruído em vez de sinal.

6. Especificações não eliminam não-determinismo

Um mesmo spec pode produzir implementações diferentes em execuções diferentes. Maior precisão reduz a variação mas aumenta o custo de escrita. E specs mal escritas — o resultado mais provável quando a metodologia é nova para o time — produzem código bem-organizado que faz a coisa errada.

7. Risco de waterfall com IA no loop

A crítica mais estrutural vem de Thoughtworks e de análises independentes: SDD como praticado atualmente corre o risco de ser waterfall com IA no loop. Você ainda está definindo tudo upfront e esperando que a realidade coopere. Para desenvolvimento exploratório com requisitos genuinamente desconhecidos, abordagens orientadas a contexto adaptam melhor.

Quando faz sentido usar

SDD no formato atual faz sentido para:

• Times enterprise desenvolvendo sobre bases de código grandes e existentes onde drift arquitetural é caro
• Ambientes regulados onde audit trails e rastreabilidade de requisitos são obrigatórios (EU AI Act, setor financeiro, saúde)
• Domínios estáveis com contratos claros: APIs, schemas de dados, regras de conformidade
• Times com maturidade em TDD ou BDD que querem estender essa disciplina à camada de IA
• Emulação e portabilidade: o caso de uso onde SDD mais brilha é reimplementar um sistema existente em outra linguagem, usando os testes do sistema original como especificação

SDD provavelmente é exagero para:

• Projetos solo e protótipos rápidos
• Desenvolvimento exploratório onde os requisitos são genuinamente desconhecidos
• Correções pequenas ou bugs isolados
• Times sem a disciplina de manter specs atualizadas após a implementação

O diagnóstico honesto

SDD é uma resposta legítima a um problema real. Vibe coding gera código mais rápido do que times conseguem governar. Especificações são uma ferramenta para restaurar essa governança.

Mas o paralelo com TDD é instrutivo. TDD tem 25 anos, tem evidência empírica extensiva, e a adoção real no mercado fica em torno de 8% no sentido estrito (escrever testes antes do código, consistentemente). SDD está gerando hype porque resolve um problema visível da era dos agentes, mas herda o mesmo desafio fundamental: desenvolvedores preferem entregar. Qualquer metodologia que adiciona trabalho upfront vai lutar contra esse instinto.

A ausência de crítica pública fácil de encontrar é ela própria um sinal. Quando os benefícios são triviais de achar e os tradeoffs não, uma metodologia ainda está na fase de marketing, não de maturidade. Spec-Driven Development ainda não pagou esse ingresso.

As ferramentas que vale acompanhar: Spec Kit pela flexibilidade open source e independência de IDE, Kiro pelos workflows estruturados em IDE, Tessl pela visão mais ambiciosa de spec-as-source (ainda não comprovada), e Plumb como referência do problema mais difícil e não resolvido — manter specs vivas depois da implementação inicial.

Referências

• The Rise of Spec Driven Development — Drew Breunig
• The Spec-Driven Development Triangle — Drew Breunig
• Spec-Driven Development Is Eating Software Engineering — Vishal Mysore
• Spec-Driven Development: Unpacking 2025’s key new practice — Thoughtworks
• Spec-Driven Development: When Architecture Becomes Executable — InfoQ
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl — Martin Fowler’s blog
• The Limits of Spec-Driven Development — Isoform
• GitHub Spec Kit
• Kiro IDE
• Tessl
• Measuring AI Impact on Experienced Developer Productivity — METR, 2025