SDD Não São Três Ferramentas — É uma Pilha de Oito Fases
O artigo de Martin Fowler sobre ferramentas SDD vale a pena ler. Fowler tem uma rara capacidade de nomear as coisas com precisão, e seu enquadramento do desenvolvimento guiado por specs como resposta ao problema do "colapso de contexto" na codificação assistida por IA é a articulação mais clara do problema central que vi publicada.
Mas a análise para em três ferramentas. E esse ponto de parada obscurece o que torna o SDD difícil na prática.
O Que Fowler Acerta
Fowler identifica as três ferramentas em que a maioria das implementações SDD converge: um formato de spec, um mecanismo de validação e um portão de aprovação. Ele está correto que essas três primitivas são necessárias. Uma spec sem validação é uma lista de desejos. Validação sem um portão de aprovação produz caos — agentes implementando requisitos meio aprovados e depois revertendo.
Sua observação de que o gargalo mudou da geração de código para a verificação de corretude também é precisa e subestimada. O problema não é que os agentes de IA escrevam lentamente. O problema é que eles escrevem com confiança na direção errada quando os requisitos são ambíguos — e ninguém percebe até que a funcionalidade seja lançada.
Onde o Enquadramento das Três Ferramentas Fica Aquém
As três ferramentas que Fowler descreve — spec, validar, aprovar — cobrem o loop de implementação. Elas não cobrem o que acontece antes, nem o que acontece depois.
Antes da implementação, há um problema. Um desenvolvedor tem uma ideia. Essa ideia precisa ser externalizada (brainstorm), estruturada em critérios de aceitação (spec), testada adversarialmente para completude (challenge) e verificada quanto à prontidão de implementação antes que qualquer agente toque no código (verificação de prontidão). Essas quatro fases acontecem antes da etapa de aprovação, e ignorá-las é o motivo pelo qual as specs chegam ao portão de aprovação com critérios vagos demais para serem implementados corretamente.
Após o merge, há um problema diferente. O código que passa nos critérios de aceitação no momento do merge pode se afastar da spec semanas depois, à medida que mudanças adjacentes se acumulam. As três ferramentas de Fowler não têm nada a dizer sobre isso. O ciclo aprovar-validar termina no merge.
As Oito Fases
Um ciclo de vida SDD completo tem oito fases:
1. BRAINSTORM → capturar a ideia antes que ela se dissolva
2. SPEC → estruturá-la em critérios de aceitação testáveis
3. CHALLENGE → examinar adversarialmente a spec em busca de lacunas e contradições
4. READINESS CHECK → verificar se a spec é implementável antes de começar a codificar
5. APPROVE → humano aprova o contrato
6. IMPLEMENT → agente executa contra a spec
7. VALIDATE → verificar a implementação contra cada critério
8. HEAL → detectar e corrigir retroativamente a deriva pós-mergeAs três ferramentas de Fowler mapeiam para as fases 5, 6 e 7. Isso deixa cinco fases descobertas.
As fases que as equipes mais comumente pulam são a 3 (challenge) e a 8 (heal). Pular o challenge significa que os critérios de aceitação chegam à aprovação com ambiguidades ocultas que só surgem durante a implementação. Pular o heal significa que a deriva se acumula silenciosamente após o merge, e a spec se torna um artefato histórico em vez de um contrato vivo.
Por Que Isso Importa para a Seleção de Ferramentas
Se você avalia ferramentas SDD perguntando "ela tem um formato de spec, um mecanismo de validação e um portão de aprovação", quase todas as ferramentas no panorama atual passam. Essa é a pergunta errada.
A pergunta certa é: qual ferramenta cobre todas as oito fases, e quais fases exigem intervenção manual?
Uma ferramenta que cobre as fases 5–7 mas não as 1–4 força os desenvolvedores a gerenciar o fluxo de trabalho pré-implementação fora da ferramenta. As fases de challenge e verificação de prontidão — que existem precisamente para detectar o que os humanos perdem — estão ausentes.
Uma ferramenta que cobre as fases 5–7 mas não a fase 8 trata o merge como o fim do ciclo de vida. Para bases de código de longa duração com mudanças adjacentes frequentes, esta é uma lacuna significativa.
O Enquadramento de Fowler Ainda É Útil
Nada disso é uma crítica à análise de Fowler. O enquadramento das três ferramentas é uma descrição precisa do fluxo de trabalho SDD mínimo viável. Para equipes adotando SDD pela primeira vez, as fases 5, 6 e 7 são o lugar certo para começar — elas entregam a maior parte do valor com menos sobrecarga.
O enquadramento se torna um teto quando as equipes tentam escalar. Em maior velocidade, com agentes em paralelo e specs de longa duração, as fases fora da janela das três ferramentas criam a fricção que limita o throughput.
A Pilha Completa
As ferramentas SDD não são uma lista de verificação de recursos. São um pipeline. A questão não é se uma ferramenta tem suporte a specs — é se a ferramenta cobre o pipeline de ponta a ponta, incluindo as fases que a maioria das análises ignora.
Do brainstorm ao heal, sem lacunas.
Leitura adicional: Mais artigos sobre desenvolvimento guiado por specs · Modo Autônomo: SDD ponta a ponta com /autonomous-sdd · Planu vs Ferramentas SDD