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.