Vibe Coding funciona até produção. Aí você precisa de Spec

Pull request aberto, builds verdes, code review aprovado pelo agente e por dois humanos. A feature entra em produção e o suporte começa a receber tickets de usuários relatando comportamento estranho no login. Você abre o código e tudo está sintaticamente correto, com testes passando. O problema é que a regra de negócio nunca chegou ao código. Ela ficou na sua cabeça quando você escreveu o prompt.

Esse é o ponto que o pasquadev levanta no vídeo recente sobre Vibe Coding e que vale destrinchar. Vibe Coding funciona. Mas existe uma camada de uso profissional que ele não cobre, e ignorar isso está custando caro.

O que está acontecendo

Vibe Coding é o termo informal para o jeito que a maioria dos devs pede coisas pra IA hoje. Você abre o Cursor, o Claude Code, o Copilot, e digita “implementa autenticação de usuário com e-mail e senha”. A IA gera 500 linhas, parece bonito, você commita.

O problema é estrutural. LLM (Large Language Model, modelo de linguagem grande) escolhe o próximo token com base em probabilidade. Ele não tem fonte da verdade sobre qual é o contrato que você espera. Ele infere. Pega o mesmo prompt vago, rode 10 vezes, e você recebe 10 implementações diferentes. Algumas vão usar JWT, outras sessão. Algumas vão validar antes de consultar o banco, outras depois. Algumas vão revelar se o e-mail existe na mensagem de erro, expondo uma vulnerabilidade de enumeração de usuários.

Aqui entra o detalhe que pouca gente percebe: quanto mais capaz o modelo, pior fica esse problema. Há dois anos, um prompt vago quebrava cedo. Código não compilava, teste falhava, você percebia em minutos que tinha que ser mais específico. Hoje, o mesmo prompt vago produz 500 linhas que compilam, têm testes passando, e ainda assim violam as regras de negócio que você tinha na cabeça.

Por que você deveria prestar atenção

A indústria evoluiu o artefato primário do desenvolvimento. No modelo tradicional, o código era o que importava. Você escrevia o código baseado na sua intuição, e a documentação vinha depois (quando vinha). Com TDD (Test-Driven Development, desenvolvimento guiado por testes), o artefato primário virou o teste: você escreve o teste primeiro, ele falha, você implementa até passar.

Spec-Driven Development (SDD) sobe um nível. O artefato primário é a especificação do comportamento. Você descreve o contrato antes de escrever qualquer linha de código ou de teste. Da spec deriva o design. Do design derivam os testes. Dos testes deriva o código.

Isso não é firula acadêmica. Faz sentido prático na era da IA por um motivo simples: a IA é excelente em executar instruções específicas e horrível em adivinhar intenção. Probabilidade não é regra de negócio. Quando você delega para a IA a decisão de “qual status retornar quando o e-mail não existe”, você está pedindo para ela decidir uma regra do seu produto. Ela vai escolher a opção mais provável estatisticamente, não a correta para o seu domínio.

O custo de não fazer SDD não é o código que sai pior. É o código que sai aparentemente certo e está silenciosamente errado.

Como aplicar isso amanhã

Spec não é prompt longo. Esse é o erro mais comum. Você pode escrever 800 caracteres de prompt vago e continuar sem spec. O que define uma spec é o contrato, não o tamanho.

Uma spec mínima viável para uma feature de autenticação tem quatro elementos:

Contrato de entrada. Qual endpoint, qual método HTTP, qual schema de body, quais headers obrigatórios.
Contrato de saída. Para cada caso possível (200, 401, 422, 429), qual o corpo da resposta. Inclua o tipo de erro como código (account_locked, invalid_credentials, email_not_found_obfuscated).
Edge cases. O que acontece quando o e-mail não existe? A resposta correta na maioria dos casos é a mesma de senha errada, para não vazar enumeração de usuários. Você precisa decidir isso explicitamente.
Regras de negócio. Bloqueio após 5 tentativas, janela de tempo, hash do password, expiração do token. Coisas que são decisão sua, não da IA.

Esses quatro elementos viram um documento de uma página. Você passa para a IA junto com o pedido de implementação. A diferença no resultado é absurda.

Vibe Coding: construindo na prática

Vou mostrar a diferença com o mesmo objetivo (autenticação por e-mail e senha) escrita dos dois jeitos.

Abordagem 1: Vibe Coding puro

Prompt Vibe Coding

Implementa autenticação de usuário com e-mail e senha. Usa JWT. Se errar, mostra erro. Bloqueia depois de várias tentativas.

Resultado típico: a IA escolhe o framework, define o status code do erro, decide se valida antes ou depois do banco, escolhe o tempo de expiração do token, e revela ou não a existência do e-mail na mensagem de erro. Cada uma dessas decisões é uma regra de negócio implícita. Você não tomou nenhuma delas.

Abordagem 2: Spec-Driven

Prompt Spec-Driven

Implemente o endpoint POST /auth/login seguindo a spec abaixo. CONTRATO DE ENTRADA - POST /auth/login - Body: { email: string, password: string } - Content-Type: application/json CONTRATO DE SAÍDA - 200: { token: string, expiresIn: 3600 } - 401 invalid_credentials: { error: "invalid_credentials" } (usado tanto para email inexistente quanto senha errada, para evitar enumeração) - 423 account_locked: { error: "account_locked", retryAfter: number } - 422 invalid_input: { error: "invalid_input", fields: string[] } REGRAS DE NEGÓCIO - Bloqueio após 5 tentativas falhas em janela de 15 minutos - Bloqueio dura 30 minutos - Token JWT com expiração de 1 hora, assinado com HS256 - Password hasheado com Argon2id antes de comparar - Validar formato do e-mail antes de consultar o banco NÃO FAÇA - Não revelar se o e-mail existe nas mensagens de erro - Não retornar 404 quando e-mail não existe - Não logar a senha em texto plano em nenhum lugar

Resultado: a IA implementa exatamente o que você descreveu. Zero adivinhação. Se ela precisar tomar uma decisão fora da spec, vai perguntar ou vai marcar como TODO. O comportamento em produção é previsível.

Comparativo de eficiência

Abordagem	Tokens	Custo	Qualidade	Tempo
Vibe Coding puro	~80	$0.001		8s
Spec-Driven	~450	$0.006		22s

O Spec-Driven custa 6x mais em tokens e demora quase 3x mais para a IA gerar. Em troca, você não tem retrabalho, não tem bug de regra de negócio em produção, não tem code review descobrindo problema crítico tarde demais. O ROI é absurdo.

Glossário

Vibe Coding: estilo de programação assistida por IA onde o desenvolvedor descreve a tarefa de forma curta e vaga, deixando a IA inferir os detalhes. Funciona para protótipo, falha em produção.
Spec-Driven Development (SDD): abordagem onde a especificação formal do comportamento é o artefato primário, escrito antes do design, dos testes e do código. Evolução natural de TDD e BDD.
TDD (Test-Driven Development): ciclo de escrever o teste primeiro, ver ele falhar, implementar o mínimo para passar, refatorar.
BDD (Behavior-Driven Development): variação do TDD onde os testes descrevem comportamentos esperados em linguagem próxima do domínio do negócio.
SDLC (Software Development Life Cycle): ciclo tradicional de desenvolvimento, com fases de planejamento, requisitos, design, implementação, teste e manutenção.
LLM (Large Language Model): modelo de linguagem grande, como GPT-5 ou Claude 4.7. Gera texto escolhendo o próximo token mais provável, não consulta uma fonte da verdade.

Sua próxima ação

Escolha uma feature que você vai implementar essa semana. Antes de abrir o editor, abra um arquivo .md e escreva os quatro blocos: contrato de entrada, contrato de saída, edge cases, regras de negócio. Leve 15 minutos nisso. Depois passe esse documento para a IA. Compare o resultado com a sua última feature feita no estilo Vibe Coding. A diferença vai ser óbvia no primeiro try.

Fontes

Vibe coding não é suficiente — pasquadev