# Spec-Driven Development: quando a especificação vira a fonte da verdade (não o código)

> Source: <https://dev.to/wildrik/spec-driven-development-quando-a-especificacao-vira-a-fonte-da-verdade-nao-o-codigo-f7d>
> Published: 2026-07-21 01:19:33+00:00

Venho usando agentes de código (Claude Code, Cursor) e bati numa parede que todo mundo conhece: o **vibe coding** — descrever a tarefa e deixar a IA cuspir código — escala mal. Funciona até a terceira mudança, quando ninguém mais lembra qual era a intenção original. O código virou a única fonte de verdade, e ele é péssimo pra contar *por que* algo foi feito.

Foi aí que caí no **Spec-Driven Development (SDD)**: colocar a especificação *antes* do código. Na prática, a "spec" é um markdown versionado no repo — requisitos + critérios de aceite — que a IA lê antes de gerar qualquer linha. Ela vira o artefato principal, não um doc que apodrece numa pasta.

A tese que tirei: o gargalo de programar com IA deixou de ser "a IA escreve código bom?". Hoje é "a IA entende o que eu realmente quero?". A spec é o que fecha essa lacuna.

Três coisas que me fizeram levar a sério:

`/speckit.specify`

, `/speckit.plan`

...). Mais perto de TDD do que de cascata.`CLAUDE.md`

(ou `AGENTS.md`

) na raiz do repo já é uma forma enxuta de aplicar a ideia.Não é bala de prata. Pra script de 50 linhas, é overhead. O ganho aparece em código que vai ser mantido, em time, ou quando você delega pesado pra agentes autônomos.

Escrevi um guia mais fundo com as 4 fases em detalhe, a comparação **Spec Kit vs Kiro vs Tessl vs OpenSpec** (qual escolher) e o passo a passo rodando SDD com Claude Code na prática: [techknow.com.br/post/spec-driven-development](https://www.techknow.com.br/post/spec-driven-development)

Quem aqui já tá usando spec como fonte da verdade no fluxo com IA? Curioso pra saber qual ferramenta pegou — e onde travou.