Desenvolvimento Orientado a Especificações vs. Vibe Coding: Cascata?

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

Conteúdo da página

O Desenvolvimento Orientado por Especificação (Spec-Driven Development) entrou em 2026 como a resposta séria dos desenvolvedores à deriva do “vibe coding”.

O argumento é simples: agentes de IA produzem resultados melhores e mais consistentes quando implementam com base em uma especificação revisada, em vez de um prompt improvisado. É difícil discordar disso em teoria.

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

Ambos os lados têm um ponto válido.

Spec-Driven Development versus Vibe Coding

O Caso a Favor do 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 notavelmente bem para trabalhos pequenos, exploratórios e descartáveis. Durante os primeiros seis meses de 2025, foi o padrão dominante de codificação com IA. Os desenvolvedores lançaram scripts, protótipos e ferramentas simples mais rápido do que nunca.

Então, os projetos cresceram. Funcionalidades que envolvia múltiplos arquivos começaram a se desviar. Restrições estabelecidas na primeira sessão eram esquecidas na terceira. Premissas de segurança foram descartadas. Decisões de arquitetura mudaram no meio da funcionalidade porque o agente não tinha memória duradoura da intenção.

O Desenvolvimento Orientado por Especificação (SDD) surgiu 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 com base nesses 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 outros suportes de comunidade como Superpowers, são todas implementações dessa ideia. As ferramentas são reais. O interesse é real. A reação contrária também é real.

No Que o Vibe Coding é Bom

Antes de descartar o vibe coding, vale a pena ser preciso sobre no que ele é bom.

Protótipos exploratórios. Quando você não tem certeza do que quer 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, especificações são prematuras.

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

Automação descartável. Scripts de uso único, trabalhos de extração de dados, auxiliares de migração – esses raramente precisam de um documento de design. O custo de errar um pouco é baixo. O custo de um processo lento e cerimonioso é 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 atrasaria isso sem benefício.

O erro é levar 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 para errar.

Onde o Vibe Coding Falha

O vibe coding se degrada previsivelmente à medida que o escopo e os riscos aumentam.

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

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

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

Premissas de segurança ocultas. Regras de autorização, fronteiras de validação de entrada, tratamento de segredos – esses são exatamente o tipo de requisitos implícitos que são perdidos quando o agente está otimizando para código funcional plausível em vez de código correto e restrito.

Handoff para a equipe. Se você construiu por meio de prompting iterativo, 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ção Muda

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

Em vez de iterar sobre o código e inferir a intenção a partir de diffs, você itera sobre a especificação e então implementa. A especificação se torna o artefato que registra o que foi decidido, por quê e o que está fora do escopo – servindo a uma função semelhante à dos Registros de Decisão de Arquitetura , mas orientado em torno da 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 um ponto de controle de revisão humana em cada etapa. Veja Fluxo de Trabalho de Desenvolvimento Orientado por Especificação: De Requisitos a Código para o processo completo, modelos e pontos de verificação. O agente participa da maioria das fases, mas 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 de Waterfall

A crítica do waterfall não está errada. Ela apenas mira no SDD ruim, não no SDD em si.

O modo de falha específico é o planejamento preliminar longo. A característica definidora do Waterfall é um ciclo 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. Na hora em que você descobre que a premissa de design estava errada, você já construiu em cima dela 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 então gasta 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 de CLI e encontrou-o “muito lento, muito ajuste fino antes de ver o código”. Essa é a versão ruim. Aquele usuário estava certo em rejeitá-lo para aquela tarefa.

A crítica útil não é “especificações são ruins”. É “planejamento preliminar longo 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 começando 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, é um design de plataforma ou precisa ser dividida em funcionalidades menores. Especificações que são grandes demais levam muito tempo para revisar e ficam 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 de forma isolada. Se as tarefas forem grandes demais, o loop de implementação se estica e o mapeamento de especificação para código se torna difícil de verificar.

Implementação precoce. Especifique a primeira tarefa, implemente-a, valide-a e então avance para a próxima tarefa. Não especifique tudo antes de implementar qualquer coisa. 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 vai – 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 disparar isto”, deve haver um teste que verifique que requisições não autenticadas são rejeitadas.

Esse 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 – mesmo um SDD leve – quando o custo de errar é real.

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

Alterações em APIs 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 (callers).

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

Handoff para a equipe. Se outro desenvolvedor ou outro agente vai continuar esse trabalho, a especificação é o artefato de handoff. 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 o que é permitido mudar (estrutura). Sem isso, o agente pode quebrar contratos que você pensava que foram preservados.

Quando o Vibe Coding Ainda é Melhor

O SDD é sobrecarga (overhead). À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, lance.

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 vê e especifique apenas o que você realmente vai lançar.

Automação descartável. Scripts de uma vez, importações de dados, auxiliares de migração – o custo de um resultado ligeiramente errado geralmente é baixo, e o artefato vai ser deletado após o uso de qualquer forma.

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

Um Framework de Decisão Simples

A pergunta prática não é “SDD ou vibe coding?”. É “quanto de 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 vai tocar nisso
  • A velocidade do feedback importa mais 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 vai continuar o trabalho
  • Você precisa escrever testes que mapeiem para requisitos

Use SDD completo quando:

  • A funcionalidade toca em 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
  • Rastreabilidade de conformidade ou auditoria é necessária

O erro mais comum é aplicar SDD completo a tarefas que só precisam de SDD leve, e aplicar nenhuma especificação a tarefas que precisam de pelo menos uma leve. Seja qual nível você escolher, a especificação só permanece útil se algo a verificar constantemente contra o código; Mantendo Especificações, Testes e Código em Sincronia 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.

Subscrever

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