Desenvolvimento Orientado por Especificações vs Vibe Coding: Waterfall?

Especificações como fonte da verdade ou cerimônia lenta?

Conteúdo da página

O Desenvolvimento Orientado por Especificações (SDD) entrou em 2026 como a resposta séria dos desenvolvedores ao desvio do “vibe coding”.

O argumento é simples: os agentes de IA produzem resultados melhores e mais consistentes quando implementam com base em uma especificação revisada, em vez de um prompt ad hoc. Difícil argumentar contra isso em teoria.

Na prática, o Hacker News chamou isso de “O Retorno do Waterfall”.

Ambos os lados têm razão.

Desenvolvimento Orientado por Especificações versus Vibe Coding

O Caso para o SDD em um Mundo de Vibe Coding

Vibe coding – a prática de escrever um prompt solto e iterar sobre o que o agente de IA produz – funciona de maneira notável para trabalhos pequenos, exploratórios e descartáveis. Nos primeiros seis meses de 2025, foi o padrão dominante de codificação com IA. Os desenvolvedores entregaram scripts, protótipos e ferramentas simples mais rápido do que nunca.

Então, os projetos cresceram. Funcionalidades que envolviam múltiplos arquivos começaram a se desviar. Restrições estabelecidas na primeira sessão foram esquecidas na terceira. Suposições de segurança foram descartadas. Decisões arquiteturais mudaram no meio da funcionalidade porque o agente não tinha uma memória durável da intenção.

O Desenvolvimento Orientado por Especificações (SDD) apareceu como a resposta disciplinada. A afirmação central: tornar a especificação o artefato central, não o prompt. Escreva requisitos, um design e um plano de tarefas primeiro. Deixe o agente implementar contra esses artefatos, uma fatia de cada vez. Mantenha a especificação versionada e atualizada.

GitHub Spec Kit, Kiro, fluxos de trabalho SDD do Claude Code e BMAD, além de outras estruturas da comunidade, são todas implementações dessa ideia. As ferramentas são reais. O interesse é real. A reação negativa também é real.

No Que o Vibe Coding É Bom

Antes de descartar o vibe coding, vale a pena ser preciso sobre o que ele faz bem.

Protótipos exploratórios. Quando você não tem certeza do que deseja construir, o caminho mais rápido é construir algo rascunho e reagir a ele. O SDD exige saber o que especificar. Se você ainda não sabe, as especificações são prematuras.

Experimentos de UI. O layout visual e a sensação de interação são difíceis de especificar antecipadamente. O vibe coding permite ver opções rapidamente, descartar a maioria delas e convergir para algo que realmente parece correto. Um documento de requisitos não ajuda aqui.

Automação descartável. Scripts únicos, trabalhos de extração de dados, ajudantes de migração – raramente precisam de um documento de design. O custo de errar ligeiramente é baixo. O custo de um processo lento e cerimonial é real.

Feedback rápido. Quando você precisa aprender algo rapidamente – essa API funciona como eu acho que funciona? – o vibe coding reduz o ciclo de aprendizado a minutos. O SDD retardaria isso sem benefício.

O erro é pegar os padrões de sucesso desses contextos e aplicá-los a funcionalidades de produção com restrições reais, usuários reais e consequências reais por errar.

Onde o Vibe Coding Falha

O vibe coding se degrada de forma previsível à medida que o escopo e as apostas aumentam.

Alterações em múltiplos arquivos. Uma vez que uma funcionalidade toca em cinco ou mais arquivos, a janela de contexto do agente começa a perder o controle das invariantes. Sem um documento de design, cada prompt precisa reestabelecer o contexto que foi estabelecido e esquecido em uma sessão anterior.

Deriva arquitetural. Sem não-objetivos explícitos, os agentes implementam coisas. O agente adiciona uma camada de cache porque parece razoável. Três sessões depois, a suposição de cache está integrada ao modelo de dados e removê-la é caro.

Restrições esquecidas. “Apenas usuários autenticados podem acionar isso” é uma frase em um documento de requisitos. Em uma sessão de vibe coding, é algo que você mencionou uma vez na sessão um e o agente não lembra na sessão quatro quando escreve o novo endpoint.

Suposições de segurança ocultas. Regras de autorização, limites de validação de entrada, manipulação de segredos – essas são exatamente o tipo de requisitos implícitos que são perdidos quando o agente está otimizando para um código funcional plausível, em vez de um código correto e restrito.

Transição de equipe. Se você construiu isso através de prompts iterativos, o artefato que registra o que foi decidido e por quê é… o log do git. Boa sorte com isso.

O Que o Desenvolvimento Orientado por Especificações Muda

O SDD não alega eliminar a iteração. As boas versões do SDD são explicitamente iterativas. O que elas mudam é onde a iteração acontece. Para a definição completa – incluindo como o SDD difere de TDD, BDD e métodos formais – consulte O Que é Desenvolvimento Orientado por Especificações?

Em vez de iterar no código e inferir a intenção a partir dos diffs, você itera na especificação e depois implementa. A especificação torna-se o artefato que registra o que foi decidido, por quê e o que está fora do escopo – servindo uma função semelhante aos Registros de Decisões Arquiteturais mas orientado para a intenção da funcionalidade em vez de escolhas em nível de sistema. O código implementa essa intenção.

O SDD passa por cinco fases – especificar, planejar, tarefas, implementar, validar – com uma porta de revisão humana em cada etapa. Consulte Fluxo de Trabalho do Desenvolvimento Orientado por Especificações: Da Especificação ao Código para o processo completo, modelos e pontos de verificação. O agente participa da maioria das fases, mas os humanos revisam os artefatos antes que a implementação comece. Essa etapa de revisão é a diferença central entre SDD e vibe coding.

Por Que os Desenvolvedores Chamam Isso de Waterfall

A crítica ao waterfall não está errada. É apenas direcionada ao mau SDD, não ao SDD em si.

O modo de falha específico é o planejamento extenso antecipado. A característica definidora do waterfall é um loop de feedback que se estende por semanas ou meses: fase de requisitos, fase de design, fase de construção, fase de teste, lançamento. O feedback chega tarde. No momento em que você descobre que a suposição de design estava errada, você já construiu sobre ela por semanas.

Quando um desenvolvedor usa o Spec Kit e gera uma lista de tarefas de 200 linhas antes de escrever uma única linha de código, e depois passa dois dias polindo o documento de requisitos antes que o agente toque em qualquer coisa, isso é waterfall. É waterfall com markdown em vez de UML, mas o modo de falha é idêntico.

Um comentarista do HN descreveu o uso do Spec Kit para uma pequena ferramenta CLI e achou que era “muito lento, muita ajuste antes de ver o código.” Essa é a versão ruim. Esse usuário estava certo em rejeitá-la para essa tarefa.

A crítica útil não é “especificações são ruins”. É “planejamento extenso antecipado antes do feedback é ruim”. Essas são afirmações diferentes.

O Meio-Termo Útil

Um bom SDD evita a armadilha do waterfall mantendo a especificação pequena e iniciando a implementação cedo.

Especificações pequenas. Um documento de requisitos para uma única funcionalidade deve caber em uma tela. Se a especificação tem dez páginas, é ou um design de plataforma ou precisa ser dividida em funcionalidades menores. Especificações muito grandes levam muito tempo para revisar e se tornam obsoletas rapidamente.

Fatias de tarefas curtas. Cada tarefa deve ser implementável em uma única sessão do agente, revisável como um diff pequeno e testável isoladamente. Se as tarefas forem muito grandes, o loop de implementação se estende e o mapeamento especificação-código torna-se difícil de verificar.

Implementação precoce. Especifique a primeira tarefa, implemente-a, valide-a e depois passe para a próxima tarefa. Não especifique tudo antes de implementar algo. A primeira implementação revelará coisas que sua especificação errou. Atualize a especificação antes de continuar.

Especificação viva. Quando a realidade difere do design – e ela diferirá – atualize a especificação, não apenas o código. A especificação só é útil se refletir o que foi realmente construído.

Testes como feedback executável. Cada critério de aceitação deve mapear para pelo menos um teste. A suíte de testes é a versão legível por máquina da especificação. Se a especificação diz “apenas usuários autenticados podem acionar isso”, deve haver um teste que verifique se solicitações não autenticadas são rejeitadas.

Este híbrido – especificações pequenas, tarefas curtas, implementação precoce, documentos vivos – é o que realmente funciona. Não é vibe coding e não é waterfall. É iteração controlada com artefatos duráveis.

Quando o SDD Vence o Vibe Coding

Use SDD – até mesmo SDD leve – quando o custo de errar for real.

Lógica de negócio arriscada. Faturamento, permissões, migrações de dados, idempotência – qualquer lógica onde o comportamento incorreto seja caro ou difícil de reverter. O vibe coding deixa esses tipos de requisitos implícitos. O SDD os torna explícitos e revisáveis antes da implementação.

Alterações de API de produção. Qualquer alteração em um contrato de API pública ou interna deve ter um documento de design. O documento de design é o que você revisa antes que o agente escreva código que quebre os chamadores.

Fluxos de trabalho multi-agente. Quando vários agentes estão implementando diferentes partes de uma funcionalidade, a especificação é a fonte única da verdade. Sem ela, cada agente otimiza localmente e as peças podem não se encaixar.

Transição de equipe. Se outro desenvolvedor ou outro agente continuar este trabalho, a especificação é o artefato de transição. Um log do git e um README não são suficientes.

Refatorações significativas. Refatorações que tocam abstrações centrais precisam de uma declaração explícita do que deve permanecer o mesmo (comportamento) e do que é permitido mudar (estrutura). Sem isso, o agente pode quebrar contratos que você pensou que foram preservados.

Quando o Vibe Coding Ainda é Melhor

O SDD é sobrecarga. Às vezes, a sobrecarga não vale a pena.

Scripts rápidos. Um script de 50 linhas para renomear arquivos ou transformar JSON não precisa de um documento de requisitos. Escreva o prompt, verifique a saída, entregue.

Experimentos. Se você está aprendendo se uma abordagem é viável – explorando uma API, testando uma biblioteca, validando uma hipótese – você precisa de velocidade, não de estrutura. Experimente primeiro, especifique se o experimento tiver sucesso.

Rascunhos de UI. O design de interação se beneficia de ver em vez de especificar. Construa várias variações rascunho rapidamente, reaja ao que você vê e especifique apenas o que você realmente vai entregar.

Automação descartável. Scripts de uso único, importações de dados, ajudantes de migração – o custo de um resultado ligeiramente errado é geralmente baixo, e o artefato será excluído após o uso de qualquer maneira.

Protótipos solitários. Se você é a única pessoa que verá este código e o objetivo é aprendizado em vez de produção, o vibe coding é mais rápido e as desvantagens são contidas.

Uma Estrutura de Decisão Simples

A questão prática não é “SDD ou vibe coding?”. É “quanta especificação eu preciso para esta tarefa específica?”

Use vibe coding quando:

  • A tarefa leva menos de um dia
  • Você está explorando ou aprendendo
  • O artefato é descartável ou de baixo risco
  • Você é a única pessoa que tocará nisso
  • A velocidade do feedback é mais importante do que a correção

Use SDD leve quando:

  • A tarefa leva dois ou mais dias
  • Múltiplos arquivos são afetados
  • Há requisitos explícitos de segurança ou correção
  • Outra pessoa ou agente continuará o trabalho
  • Você precisa escrever testes que mapeiem para requisitos

Use SDD completo quando:

  • A funcionalidade toca uma interface pública ou contrato de dados
  • Múltiplos agentes ou membros da equipe estão envolvidos
  • A organização exige uma revisão de design antes da implementação
  • Conformidade ou trilhas de auditoria são necessárias

O erro mais comum é aplicar SDD completo a tarefas que precisam apenas de SDD leve, e aplicar nenhuma especificação a tarefas que precisam de pelo menos uma leve. Qual nível você escolher, a especificação só permanece útil se algo continuar verificando-a contra o código; Mantendo Especificações, Testes e Código Sincronizados no Desenvolvimento com IA cobre as verificações de rastreabilidade que pegam uma especificação ficando obsoleta silenciosamente.

SDD ruim é waterfall com markdown. SDD bom é iteração controlada com artefatos duráveis. Vibe coding é a ferramenta certa para as tarefas certas – e a ferramenta errada para as erradas. Saber a diferença é a habilidade.

Assinar

Receba novos artigos sobre sistemas, infraestrutura e engenharia de IA.