Spec-Driven Development É Só Waterfall Com Prompt? A Crítica Que Está Ganhando Força

Nas últimas semanas venho acompanhando o mesmo debate se repetir em lugares diferentes, com palavras diferentes, convergindo para a mesma pergunta incômoda. Um post no dev.to sobre um experimento de uma semana com spec-driven development. Um texto duro num Medium de consultor Java, comparando SDD à onda de CASE tools e RUP dos anos 2000. Threads de Hacker News com título direto, "The Waterfall Strikes Back". Não precisei procurar essa conversa; ela apareceu sozinha, repetida, em feeds diferentes, com frequência que já diz algo sobre o nervo que tocou.

O nervo é este: 2026 foi o ano em que spec-driven development deixou de ser aposta de early adopter e virou quase item de checklist. GitHub lançou o Spec Kit e passou de setenta mil estrelas, AWS construiu uma IDE inteira em torno do conceito, e o mapa de ferramentas que já tracei aqui mostra pelo menos sete opções sérias disputando a categoria. Cursos dedicados nasceram, papers acadêmicos formalizaram taxonomia, e times que há um ano discutiam se deviam deixar um agente escrever código de produção agora discutem qual framework de SDD adotar. Essa velocidade de consenso é, historicamente, um sinal de alerta tanto quanto de maturidade — as duas coisas raramente se confirmam ao mesmo tempo.

É exatamente contra essa velocidade que a crítica mais afiada do momento se ergue. Ela não questiona se escrever intenção antes de gerar código ajuda — isso praticamente ninguém discute mais. Questiona algo mais incômodo: será que reintroduzir uma especificação detalhada antes da implementação não é, no fundo, reempacotar o waterfall com verniz de agente por cima, carregando o mesmo defeito estrutural que fez o waterfall ser abandonado — a suposição de que dá para especificar completamente um sistema antes de construí-lo?

Já escrevi neste blog sobre como o vocabulário em torno de SDD, harness e agentic engineering está se diluindo mais rápido do que a indústria consegue definir os termos, separando ali disciplina real de hype de nome. Este post trata de outra coisa, mais desconfortável: não é sobre o nome virar ruído, é sobre se a metodologia em si, mesmo bem definida, carrega o problema de fundo do waterfall clássico. Vou apresentar o argumento "é waterfall 2.0" na íntegra, a defesa mais forte que recebeu, onde essa defesa segura e onde quebra, e no final assumo posição — com a ressalva de que ninguém devia fechar essa discussão com certeza absoluta em setembro de 2026.

O Consenso Que Formou Rápido Demais Em 2026

Vale registrar, rapidamente, como chegamos até aqui, porque o ritmo importa para entender por que a crítica pegou tração agora e não há um ano. SDD não nasceu do nada: emergiu como resposta ao caos percebido do vibe coding, o modo de trabalho onde você descreve a intenção em linguagem solta, aceita o que o agente devolve sem examinar muito, e segue em frente. Funciona bem para protótipo descartável. Vira problema sério quando aplicado a sistema que precisa viver em produção, e boa parte da indústria concluiu isso ao mesmo tempo, no mesmo semestre.

A resposta a esse caos percebido veio rápido e com força de marketing considerável. Frameworks nasceram, ganharam estrelas no GitHub numa velocidade que ferramenta de infraestrutura tradicional levaria anos para alcançar, e a narrativa se consolidou: vibe coding é para fim de semana, SDD é para produção, ponto final. É narrativa limpa, fácil de vender numa palestra de vinte minutos, e por isso mesmo suspeita — realidade raramente se resolve em dicotomia tão arrumada.

O problema de uma narrativa que vence rápido demais é que ela atropela a pergunta que deveria vir antes da adoção em massa: o que, exatamente, essa prática está reintroduzindo que a indústria já tentou e abandonou? A pergunta é, na verdade, a mesma que motivou o Manifesto Ágil em 2001, escrito por gente que tinha acabado de sair de anos de metodologia pesada, documento grosso, ciclo de meses entre especificar e entregar. Quando uma prática nova ecoa tão de perto uma que uma geração inteira de desenvolvedores lutou para deixar para trás, o mínimo é levar a comparação a sério antes de adotar em escala.

É essa comparação que quero fazer aqui, sem pular para a defesa reflexa de "mas com IA é diferente" nem para a rejeição reflexa de "é só hype requentado". As duas reações têm parte de razão, e nenhuma sozinha resolve a pergunta.

O Argumento "É Waterfall 2.0" Até O Fim

A versão mais completa dessa crítica vem de um texto publicado em agosto de 2026 por Uberto Barbini, consultor e autor com histórico em Java e Kotlin, sob o título "Spec-Driven Development: The New Waterfall". O argumento dele começa com uma analogia histórica mais precisa do que a comparação genérica que circula por aí.

Barbini lembra que, por volta dos anos 2000, a indústria já tinha visto essa promessa, só que embalada de forma diferente. CASE tools nos anos oitenta prometiam gerar código a partir de modelo. RUP formalizou a cerimônia em torno disso. CMMI deu cinco níveis para aspirar. Model Driven Architecture tornou o pacote explícito: você escreve o modelo independente de plataforma, e uma transformação produz o código no fim. Programador sênior vira arquiteto, descreve intenção em vez de escrever código, e um time júnior — muitas vezes terceirizado — cuida da digitação. Trocar "time júnior terceirizado" por "agente de IA" e a estrutura do argumento de 2026 fica desconfortavelmente parecida.

O motivo de tudo isso ter falhado, segundo Barbini, não foi a qualidade das ferramentas nem o custo delas, embora ambos pesassem. Foi que o modelo sempre acabava tão complicado quanto o código que deveria substituir — porque o mundo que ele descrevia era complicado — e passava a existir dois artefatos para manter sincronizados em vez de um. O código driftava do modelo na primeira sexta-feira em que alguém precisava corrigir um bug sob pressão, e o modelo ficava esquecido numa prateleira. A resposta histórica não foi mais processo. Foi o oposto: dezessete pessoas reunidas numa estação de esqui em Utah, em fevereiro de 2001, escrevendo quatro linhas sobre o que valorizavam, dando início ao Manifesto Ágil.

A aplicação dessa lição ao SDD de 2026 é o núcleo da crítica: o motor de transformação agora é um modelo de linguagem em vez de um motor de template — melhoria genuína e enorme —, mas o problema estrutural continua o mesmo. Uma especificação precisa o suficiente para gerar o sistema que você quer é tão complexa quanto o próprio sistema. Se não for tão precisa, o agente preenche as lacunas com suposições plausíveis, e você tem drift no primeiro dia em vez de no sexto mês, como no waterfall clássico — o problema não desapareceu, só ficou mais rápido de aparecer. Barbini reforça isso com uma observação sobre determinismo: rodar a mesma especificação duas vezes produz dois sistemas diferentes, ambos plausíveis. Regenerar, nesse cenário, não é reconstruir a partir de fonte estável. É reescrever.

Existe uma segunda camada dessa crítica, mais prática do que filosófica. Brandon Kindred, num texto de 2026 chamado "Same Patterns, New Hype", chega a conclusão parecida por outro caminho: boa parte do que se vende como SDD é engenharia que já existia sob outros nomes, e o valor real está no raciocínio que a pessoa faz ao escrever a especificação, não na ferramenta que promete formalizar esse raciocínio. Quando o spec é tratado como controlador de build — o documento que dirige literalmente o que o agente vai gerar —, ele vira o roteiro rígido que o waterfall sempre teve, só que com o nome trocado. E o drift, alerta Kindred, não desaparece só porque existe um documento chamado spec; ele só muda de lugar.

A Defesa: Phase Gates Não São Artefato Vivo

A defesa mais comum não nega o paralelo histórico — contesta a equivalência estrutural. O waterfall trava a especificação através de phase gates, portões de fase rígidos e sem volta: a fase de requisitos fecha para valer, e mudança exige reabrir formalmente um processo caro. O SDD, nessa defesa, trata a especificação como artefato vivo, atualizado através de ciclos de feedback durante a própria implementação. A objeção "SDD é só waterfall" confundiria escrever uma spec antes de codar com congelar uma spec antes de codar — a primeira é prática saudável em qualquer engenharia séria, a segunda é o que de fato quebrou o waterfall.

Há dado sustentando essa distinção, não só afirmação de princípio. No relato do dev.to, Alex Cloudstar descreve o ciclo de feedback do waterfall clássico como medido em meses: um documento de requisitos de duzentas páginas, entregue a um time, com espera de três a seis meses por um entregável — tempo suficiente para os requisitos já estarem errados quando o software aparecia. No spec-driven development apoiado por agente, esse ciclo passa a ser medido em minutos: você escreve a spec, o agente gera a implementação, revisa, e se a spec estava errada, atualiza e regenera. O ciclo que levava meses cabe numa tarde. Cloudstar chama isso de diferença de categoria, não de grau: o waterfall falhou pelo custo catastrófico de descobrir que a especificação estava errada, e quando esse custo cai a quase zero, o cálculo muda.

A defesa mais forte, porém, vem da genealogia. Se SDD é waterfall só porque uma especificação aparece antes da implementação, test-driven development também seria — no ciclo red-green-refactor, o desenvolvedor escreve uma especificação, o teste que falha, antes de qualquer linha de implementação. Ninguém, em quinze anos de TDD mainstream, chamou isso de waterfall disfarçado. Behavior-driven development leva a lógica adiante, escrevendo a especificação em linguagem quase natural antes do código também. Se "spec primeiro, código depois" bastasse para configurar waterfall, duas décadas de prática ágil consolidada estariam reclassificadas como a mesma coisa que a comunidade ágil rejeitou.

Essa defesa não é inventada para a ocasião: o próprio Barbini, autor da crítica mais dura, termina endossando uma versão dela, propondo tratar testes automatizados como a especificação real — teste é o único artefato do pipeline que precisa ser consistente com a realidade, roda contra dado de produção feio ou não roda. Um documento pode dizer qualquer coisa e continuar bonito na tela. Um teste que descreve algo impossível fica vermelho.

Onde A Defesa Do TDD Segura E Onde Ela Quebra

Aqui a discussão fica honesta de verdade: a analogia com TDD é ao mesmo tempo o argumento mais forte a favor do SDD e o argumento que, levado longe demais, entrega a própria crítica de volta para quem a fez.

Ela segura quando a especificação é pequena, verificável e executável — um teste, um punhado de critérios de aceite objetivos, algo que passa ou não passa contra código real. Nesse formato a spec não compete com o código pela posição de fonte de verdade; serve de âncora que o código tem que satisfazer, e a discordância entre os dois aparece imediatamente, de forma binária. É o que a especificação por exemplo, formalizada por Gojko Adzic e por ferramentas como FIT antes do boom de IA, já defendia: o teste como descrição de intenção que sobrevive à implementação que hoje o satisfaz.

Ela quebra quando a especificação é um documento de vinte páginas em prosa — user stories, critérios de aceite, arquitetura, edge cases de um sistema não trivial —, o formato que a maioria das ferramentas de SDD hoje produz e consome. Um teste não consegue descrever algo impossível sem ficar vermelho na hora. Um documento de vinte páginas pode, sem contradição interna visível, especificar um sistema sem sentido, e ninguém percebe até o código rodar contra dado real. A diferença entre "um teste que falha" e "uma spec de produto inteira" não é de grau, é de gênero: um é falsificável de imediato, o outro só depois de um ciclo inteiro de geração e muita confiança depositada em texto que ainda não encostou em realidade nenhuma.

Isso não invalida a comparação com TDD, mas limita o alcance dela. Ela prova que "escrever spec antes de código" não é, por si só, sinônimo de waterfall — esse ponto fica de pé. Não prova que qualquer spec, de qualquer tamanho e formato, herda automaticamente a mesma imunidade ao problema que o waterfall tinha. A tabela abaixo ajuda a deixar essas diferenças concretas, porque a discussão costuma se perder justamente ao comparar coisas de tamanhos diferentes como se fossem equivalentes:

Dimensão	Waterfall Clássico	SDD (uso típico hoje)	TDD / BDD
Quando a especificação é escrita	Antes de toda a implementação, fase fechada	Antes de cada feature, em documento extenso	Antes de cada unidade de código
Pode mudar depois de escrita	Só via mudança formal de requisito, cara e lenta	Em tese sim; depende de disciplina do time	Sim, trivial: reescreve o teste, roda de novo
Ciclo de feedback até validar	Meses, até o entregável aparecer	Minutos a horas	Segundos, a cada execução da suíte
O que verifica se foi cumprida	Revisão humana tardia, já em produção	Revisão humana do output, nem sempre sistemática	Execução automática, a cada mudança
Granularidade típica	Sistema inteiro	Feature ou módulo	Unidade de comportamento isolada

A leitura que tiro dessa tabela não é que SDD "vence" ou "perde" contra TDD. É que SDD ocupa um ponto intermediário desconfortável entre as duas colunas extremas — mais rápido e reversível que o waterfall, mas mais lento para falsificar e mais dependente de disciplina humana do que TDD. Chamar isso de "exatamente igual ao waterfall" ignora que a coluna do meio tem ciclo de feedback ordens de magnitude mais rápido. Chamar isso de "exatamente igual ao TDD" ignora que a maioria das specs de SDD em produção não é falsificável de forma automática e imediata como um teste é.

Minha Posição, Com Ressalva

Depois de pesar os dois lados, minha posição é que a crítica "é waterfall 2.0" está certa sobre o mecanismo e errada sobre a conclusão. Está certa porque o risco que Barbini descreve é real: uma especificação de prosa longa, não executável, revisada de forma assíncrona, tem o mesmo ponto cego estrutural que o waterfall tinha — pode descrever algo incoerente e continuar parecendo sólida até o código encostar em produção. Isso acontece hoje, em times reais, com ferramentas de SDD reais, e fingir que a velocidade de geração resolve esse ponto cego é otimismo sem lastro.

Onde acho que a crítica erra é em tratar esse ponto cego como propriedade inerente de "escrever spec antes de codar", em vez de propriedade de um formato específico — o documento de prosa extensa tratado como controlador de build. A diferença entre SDD que funciona e SDD que reproduz o waterfall não está no nome da metodologia, está numa escolha mais estreita: a spec do seu time é falsificável contra código real, como um teste, ou é só texto bonito que alguém aceita por educação? Times que amarram a spec a critério de aceite executável, tratam divergência com o comportamento real como bug, e aceitam regenerar em vez de proteger o documento como relíquia, fazem algo estruturalmente diferente do waterfall. Times que entregam a spec ao agente e tratam o resultado como cerimônia satisfeita estão fazendo waterfall com um passo de IA no meio.

A ressalva é que essa distinção é mais fácil de enunciar do que de garantir na prática, e não tenho dado de campo mostrando que times fazem essa escolha certa com consistência. O que existe é relato individual, argumento bem construído dos dois lados, e uma indústria movendo atenção rápido demais para qualquer um reunir esse dado com rigor. É desconfortável admitir isso num post que pede posição, mas seria pior fingir evidência mais sólida do que ela de fato tem.

Boa parte dessa discussão fica mais concreta na prática: cada ferramenta de SDD resolve essa tensão de um jeito diferente — algumas tratam a spec como descartável após a primeira geração, outras a mantêm ancorada ao código por testes automatizados durante toda a vida do sistema. A ferramenta não resolve o problema sozinha, mas o rigor que impõe por padrão influencia bastante para qual lado da tabela acima o seu time vai gravitar sem perceber.

Essa mesma tensão já apareceu neste blog antes de a onda de SDD virar mainstream, quando comparei vibe coding com spec-driven development para decidir qual abordagem cabia em produção: mesmo naquele momento mais cedo do ciclo de hype, a conclusão já apontava para "depende do tamanho e do risco da mudança", não para resposta binária. Nada do que vi desde então mudou essa conclusão; só ficou mais claro por que ela é verdadeira.

Conclusão

Volto à cena com que abri este post: a mesma pergunta aparecendo em lugares diferentes, com pessoas diferentes, na mesma janela de meses. Isso não é coincidência de calendário. É sinal de que a indústria adotou SDD rápido demais para ter respondido, com dado sólido, a pergunta óbvia que qualquer pessoa que já viveu um projeto de waterfall faria ao ouvir "vamos escrever uma spec detalhada antes de codar". A pergunta é justa. A resposta ainda está sendo escrita — não pela indústria de ferramentas, que já decidiu vender a resposta pronta, mas pelos times que descobrem na prática onde a spec ajuda e onde só demora a revelar o mesmo drift que sempre existiu.

Chamar SDD de "waterfall 2.0" erra tanto quanto chamá-lo de "o futuro de todo desenvolvimento de software". As duas afirmações pegam um mecanismo real, generalizam para todo uso possível da prática, e vendem a generalização como conclusão definitiva. O mecanismo de risco existe e é específico ao formato de spec de prosa longa e não falsificável. O mecanismo de benefício também existe e é específico ao ciclo de feedback comprimido que a IA tornou possível. Nenhum dos dois cobre o campo inteiro sozinho.

O futuro, imagino, vai ser mais bagunçado e pragmático do que qualquer um dos dois lados admite hoje. Times vão continuar escrevendo spec antes de código quando isso reduzir retrabalho, e pulando spec quando ela só adicionar cerimônia. A diferença entre quem evita reproduzir o waterfall e quem reproduz sem perceber vai seguir decidida pela pergunta mais chata de todas: essa spec, se estiver errada, algo vai perceber rápido, ou vai ficar bonita e incontestada até alguém tropeçar nela em produção?

Fontes:

Spec-Driven Development É Só Waterfall Com Prompt? A Crítica Que Está Ganhando Força

Spec-Driven Development É Só Waterfall Com Prompt? A Crítica Que Está Ganhando Força

O Consenso Que Formou Rápido Demais Em 2026

O Argumento "É Waterfall 2.0" Até O Fim

A Defesa: Phase Gates Não São Artefato Vivo

Onde A Defesa Do TDD Segura E Onde Ela Quebra

Minha Posição, Com Ressalva

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose