[AI]: Spec-Driven Development com Claude Code

Isso tudo soa estranhamente familiar.

A gente passa 30 anos dizendo que waterfall morreu, que documento era veneno, que “especificar demais” matava a inovação. Agile matou isso com força, às vezes com razão, muitas vezes por pura preguiça.

Agora o pêndulo volta, renomeado: SDD.
Mesma ideia básica, outro marketing, agora com IA no meio.

Escrever a spec inteira, validar, depois implementar exatamente aquilo…
desculpa, mas isso é waterfall com autocomplete sim.

O problema nunca foi “especificar antes de codar”.
O problema é especificar mal, congelar cedo demais e fingir que o mundo não muda.

Depois de 30 anos de Agile, a gente deveria saber fazer melhor do que esse falso dilema:

• ou caos criativo sem contrato
• ou spec monolítica que vira verdade absoluta

Engenharia madura não é isso.

SDD sem Requirements Engineering é só mais um hype com nome novo.
Bonito, organizado, cheio de .spec.md… e estruturalmente vazio.

Especificação que não tem rastreabilidade não é contrato, é literatura.
Pode ser bem escrita, pode gerar teste, pode gerar código… e ainda assim estar quebrada...

Se você não consegue responder, de forma deterministica:

• qual requisito deu origem a esse código?
• qual teste prova que esse requisito foi satisfeito?
• o que quebra se eu remover isso aqui?

Então sua spec já morreu, só não foi enterrada ainda. Specs apodrecem porque ninguém consegue ver o impacto de mudá-las. RE resolveu isso há décadas. Rastreabilidade não é burocracia. É o único antídoto contra a degradação natural das especificações.

E aqui entra o ponto que separa engenharia de sistemas de prompt engineering: rastreabilidade.

Não é velocidade.

Não é escrever spec antes do código.

É conseguir manter a especificação e a implementação evoluindo juntos, com vínculo explícito, verificável e inevitável.
Qualquer coisa fora disso é teatro.
SDD, do jeito que está sendo vendido, não resolve a parte difícil.

Ele resolve a parte fácil: gerar código obediente a um texto congelado.
Isso é trivial. Isso é automation.
A parte difícil, e que Agile expôs, mas nunca resolveu é:
requisitos mudam depois do código existir, decisões antigas precisam ser revistas, protótipos ensinam coisas que a spec não previa, invariantes precisam sobreviver à iteração.

Sem rastreabilidade, a spec vira ficção. Com rastreabilidade, a mudança vira engenharia. Spec boa não é a que “vem antes”. É a que anda junto, registra desvios, explica por que mudou e quebra o build quando a realidade tenta trapacear.

Nesse ponto, pouco importa se você chama de SDD, Agile ou Waterfall.

falei um pouco aqui também sobre como utilizar essas ferramentas na prática e tem muito do que seu texto trouxe!

https://www.youtube.com/watch?v=lC85jFCG_ho

Seu artigo é bem abrangente. Eu fiquei com uma dúvida em relação aos testes. Quando você diz:

Gere testes a partir da especificação antes de implementar

Pode-se dizer que o desenvolvimento pratica TDD? Não entendi se ocorre alguma interação entre os testes e a implementação como no TDD. Digo, se na implementação chega a ocorrer erros por conta dos testes e a implementação precisa ser ajustada.

Seria algo em cascata (waterfall clássico), testes, depois implementação, e tudo ok e pronto? Ou ele fica ajustando entre um e outro (desenvolvimento agile), codando de forma interativa e incremental.

Cara, dúvida de leigo mesmo. Estou iniciando em IA e vibe coding.