Vibe Coding vs SDD: Qual Abordagem Realmente Funciona em Produção?

Andrei Karpathy cunhou o termo "vibe coding" em fevereiro de 2025, e desde então ele virou uma das expressões mais usadas — e mais mal entendidas — do mundo de desenvolvimento de software.

A definição original de Karpathy é precisa: você descreve o que quer em linguagem natural, o modelo gera o código, você aceita sem ler muito, e continua. O objetivo é velocidade de prototipagem extrema. "Não se trata de entender o código", disse Karpathy. "Você deixa o LLM fazer tudo."

O problema é que em 2026, muita gente está usando vibe coding em sistemas de produção. E aí a coisa complica.

Do outro lado do espectro está o Spec-Driven Development (SDD) — a abordagem de escrever especificações estruturadas antes de qualquer linha de código, usando essas specs como o contrato que governa o que os agentes geram. Em 2026, três plataformas lançaram tooling dedicado a SDD: GitHub Spec Kit, AWS Kiro e Tessl Framework. O mercado está votando com código.

Este post analisa as duas abordagens com dados reais, sem torcida declarada, para ajudar você a tomar a decisão certa para o seu contexto.

O Que É Vibe Coding, de Verdade

Para a discussão ser útil, precisamos ser precisos sobre o que estamos comparando.

Vibe coding não é simplesmente "usar IA para escrever código". Isso seria a definição de qualquer uso de ferramenta de AI coding. Vibe coding tem características específicas:

Iteração rápida sem especificação prévia. Você parte de uma ideia de alto nível, gera código, vê o que saiu, ajusta o prompt, gera de novo. O design emerge da iteração, não de uma especificação.

Aceitação de outputs sem revisão profunda. A ideia central é aceitar o código que "parece funcionar" sem necessariamente entender cada linha. A verificação é comportamental ("funciona como esperado") e não estrutural ("é construído da forma certa").

Foco em velocidade sobre manutenibilidade. Vibe coding otimiza para "chegar lá rápido". As consequências de decisões de design ruins ficam para depois.

Em contextos adequados — prototipagem, exploração, projetos pessoais descartáveis — essa abordagem é genuinamente poderosa. Em 4 horas você valida uma ideia que levaria dias de desenvolvimento tradicional.

O problema emerge quando "contexto adequado" não é a realidade.

O Problema: A Parede dos 3 Meses

Existe um padrão documentado em times que adotaram vibe coding para desenvolvimento de produto real: os primeiros meses são mágicos. Velocidade de entrega alta, stakeholders animados, demos impressionantes. Então, por volta do terceiro mês, algo muda.

As features novas começam a demorar mais. Cada mudança quebra algo inesperadamente. O contexto que o agente precisa para fazer alterações simples cresce exponencialmente porque o codebase virou uma teia de decisões implícitas que ninguém documentou.

O motivo técnico é simples: vibe coding acumula dívida técnica de forma acelerada porque cada decisão de design é tomada localmente, sem considerar o sistema como um todo. Quando o agente gera código para "adicionar autenticação", ele faz isso da forma mais direta possível — sem considerar como autenticação vai interagir com o sistema de permissões que vai vir a seguir, com o contexto de multitenancy que alguém vai pedir depois, com os requisitos de auditoria que a equipe jurídica vai impor em 6 meses.

Um dev humano com experiência pensa nessas coisas preventivamente. O agente de vibe coding não pensa — ele executa.

Gráfico mostrando a velocidade de entrega ao longo do tempo com vibe coding versus SDD: vibe coding começa mais rápido mas declina com dívida técnica, SDD começa mais lento mas mantém velocidade consistente

O Que É SDD: Especificação Como Contrato

Spec-Driven Development parte de uma premissa diferente: antes de qualquer geração de código, você define o contrato.

O contrato inclui:

O que o componente/feature deve fazer (comportamento esperado)
O que ele não deve fazer (restrições e limites explícitos)
Como ele se integra com o sistema existente (interfaces e dependências)
Critérios de aceitação verificáveis

Essa spec vira o briefing para o agente. O agente gera código dentro das restrições da spec, não em campo aberto. O resultado é código que, desde o início, respeita as decisões de arquitetura do sistema.

A diferença não é só filosófica. É operacional. Quando você tem uma spec, o code review muda: você não está perguntando "isso parece certo?", está perguntando "isso atende a spec?". A verificação é mais rápida, mais objetiva e mais confiável.

Mais importante: quando você precisa modificar o sistema depois, você modifica a spec primeiro, e então regenera o código. A spec é a fonte de verdade, não o código.

2026: O Mercado Escolheu

Em 2026, o mercado passou de uma discussão teórica para um sinal claro: três plataformas lançaram tooling dedicado a SDD em sequência.

GitHub Spec Kit — integrado ao GitHub Copilot Enterprise, permite que times definam specs em YAML estruturado que governam o comportamento do agente de coding. Pull requests incluem a spec como artifact de revisão, não só o código.

AWS Kiro — a IDE agêntica da Amazon nasceu com SDD como princípio central. O fluxo começa obrigatoriamente com uma fase de especificação antes de qualquer geração de código. A ideia é que agentes bem instruídos entregam consistentemente melhor do que agentes livres.

Tessl Framework — focado em times de produto, separa explicitamente a fase de "o que construir" (spec) da fase de "como construir" (geração). Permite que PMs participem da definição da spec sem precisar escrever código.

O fato de três players grandes apostarem em tooling específico para SDD — e não para vibe coding — não é coincidência. É evidência de que times de produto em escala estão enfrentando os problemas da abordagem não estruturada e buscando alternativas.

Isso não significa que vibe coding vai desaparecer. Significa que o mercado está delimitando onde cada abordagem pertence.

Fluxo do Spec-Driven Development: fase de especificação → revisão da spec → geração de código → validação contra spec → merge — comparado com o fluxo de vibe coding sem especificação

Quando Usar Cada Um: O Framework de Decisão

A pergunta não é "qual é melhor?". É "qual é melhor para este contexto?".

Use Vibe Coding quando:

Está validando uma hipótese. Você não sabe se a feature vai ser útil. O objetivo é aprender rápido, não construir para durar.
O código é descartável. Scripts internos, protótipos de demo, ferramentas pessoais que só você vai usar.
Está explorando um domínio novo. Às vezes você precisa escrever código para entender o problema. Vibe coding é ótimo para exploração.
A velocidade é o único critério. Hackathon, PoC para deadline de amanhã. Qualidade pode esperar.

Use SDD quando:

O código vai para produção. Qualquer coisa que vai ser mantida, modificada e estendida ao longo do tempo.
Tem mais de uma pessoa no projeto. Specs são a forma mais eficiente de alinhar entendimento entre membros do time — e entre humanos e agentes.
O sistema tem integrações. Quando seu código se conecta com outros sistemas, as fronteiras precisam ser explícitas. Spec é como você define e documenta essas fronteiras.
Tem requisitos não-funcionais. Performance, segurança, observabilidade — essas restrições precisam estar na spec para que o agente as respeite.
A dívida técnica tem custo real. Em qualquer contexto de negócio onde velocidade futura importa, SDD paga dividendos.

A Abordagem Híbrida que Times Maduros Estão Usando

Na prática, os times mais eficientes em 2026 não escolheram um ou outro — eles sequenciam os dois de forma intencional.

Fase 1 — Exploração (Vibe Coding): para entender o domínio, testar hipóteses, validar que a abordagem técnica é viável. O código aqui é descartável por definição.

Fase 2 — Especificação (SDD): com o entendimento adquirido na fase 1, você escreve a spec do que vai ser construído de verdade. A exploração informou as decisões; agora as decisões são documentadas.

Fase 3 — Implementação Guiada (SDD): agentes geram a implementação dentro das restrições da spec. Code review valida contra spec. Merge com confiança.

Esse sequenciamento captura o melhor dos dois mundos: a velocidade de aprendizado do vibe coding na fase de descoberta, e a confiabilidade e manutenibilidade do SDD na fase de construção.

Como Escrever Specs Que Funcionam Com Agentes

Se você decidiu adotar SDD — e os dados sugerem que deveria para projetos de produção — a pergunta prática é: o que faz uma spec boa?

Spec ruim é aquela que poderia ser interpretada de múltiplas formas e o agente vai escolher uma interpretação sem avisar. Spec boa é aquela que remove ambiguidade estruturalmente — não porque foi escrita de forma elegante, mas porque cobre as dimensões que os agentes mais frequentemente erram.

Comportamento esperado com exemplos concretos. Não basta dizer "o componente deve validar o email do usuário". Diga: "para o input '[email protected]' o resultado deve ser válido; para 'user@', 'user.domain.com', '' e null o resultado deve ser inválido com as mensagens X, Y, Z e W respectivamente." Exemplos concretos eliminam uma classe inteira de ambiguidade.

Restrições explícitas. O que o componente não deve fazer é tão importante quanto o que deve. "Não deve fazer chamadas de rede síncronas", "não deve modificar o estado do componente pai", "não deve lançar exceções — sempre retorna Result<T>". Agentes tendem a fazer o que não foi proibido se for a solução mais natural que aprenderam no treinamento.

Interface de integração. Como esse componente se conecta com o que já existe? Quais são os tipos de entrada e saída? Quais são as invariantes que o código existente assume sobre esse componente? Essa é a parte mais frequentemente omitida e a que mais gera problemas de integração.

Critérios de aceitação verificáveis. Como você vai saber que o agente entregou o que você pediu? Critérios de aceitação que começam com "o componente deve funcionar corretamente" são inúteis. "O componente deve processar 10.000 requests por segundo em hardware de staging com p99 < 50ms" é um critério verificável.

Dependências e contexto do sistema. Quais partes do sistema existente esse código vai usar ou modificar? Quais são as convenções de nomenclatura, padrões de erro, e estrutura de logging que o time usa? O agente não conhece essas convenções a menos que estejam na spec — e se não estiver, ele vai inventar as suas.

Uma spec com essas cinco dimensões pode levar 30-60 minutos para escrever. O código vai ser gerado em minutos. O ratio de investimento parece desfavorável, mas não é: você está comprando confiabilidade de integração, manutenibilidade e um processo de revisão muito mais eficiente.

O Problema de Ego que Ninguém Fala

Tem uma dimensão cultural nessa discussão que é raramente abordada.

Vibe coding tem uma estética atraente para devs. Você digita três frases e aparece um sistema funcionando. É impressionante. Dá uma sensação de poder que desenvolvimento tradicional não dá.

SDD é menos cinematográfico. Você passa horas escrevendo uma spec que nenhum usuário final vai ver. Não tem a mesma adrenalina.

Mas existe uma inversão de ego importante aqui: o dev que escreve specs claras o suficiente para que agentes gerem código confiável é, de fato, mais habilidoso do que o dev que aceita qualquer coisa que o agente gere. A spec é o artefato de maior valor intelectual no SDD. Escrever specs boas é difícil, exige entendimento profundo de sistema, e é uma skill que se desenvolve com prática.

Ironicamente, é muito mais fácil fazer vibe coding do que fazer SDD bem feito. O que parece a abordagem "preguiçosa" exige, na verdade, mais competência.

Conclusão

O debate vibe coding vs SDD vai continuar por um tempo porque ambas as abordagens têm casos de uso legítimos. O problema não é a existência das duas — é aplicar a abordagem errada no contexto errado.

Para projetos de produção em 2026, a tendência é clara: SDD está se tornando o padrão de facto para times que trabalham com agentes em escala. O tooling confirma isso. Os dados de manutenibilidade confirmam isso. O próprio Karpathy, ao posicionar vibe coding para "projetos de fim de semana", estabeleceu o limite de forma explícita.

Isso não significa que todo dev precisa adotar SDD amanhã em tudo. Significa que quem está construindo sistemas que vão durar, que vão crescer, que vão ser mantidos por outras pessoas — precisa ter uma resposta melhor do que "estou vibing com o agente."

A spec é essa resposta.

Vibe Coding vs SDD: Qual Abordagem Realmente Funciona em Produção?

Receba os melhores artigos toda semana

Vibe Coding vs SDD: Qual Abordagem Realmente Funciona em Produção?

O Que É Vibe Coding, de Verdade

O Problema: A Parede dos 3 Meses

O Que É SDD: Especificação Como Contrato

2026: O Mercado Escolheu

Quando Usar Cada Um: O Framework de Decisão

Use Vibe Coding quando:

Use SDD quando:

A Abordagem Híbrida que Times Maduros Estão Usando

Como Escrever Specs Que Funcionam Com Agentes

O Problema de Ego que Ninguém Fala

Conclusão

Fontes

Receba os melhores artigos toda semana

eltonjose