Vibe code com IA é desastre: como o desenvolvimento com IA exige rigor

TL;DR

Vibe code é a prática de aceitar output de IA porque parece certo, sem critério explícito de aceitação. O problema é que “parece certo” não é contrato — é chute. Código gerado por IA sem especificação precisa funciona até o momento em que para de funcionar, em condição de contorno que ninguém previu porque ninguém escreveu teste que cobrisse. A escolha entre vibe code e desenvolvimento rigoroso com IA é a diferença entre protótipo descartável e sistema em produção. Este post mostra cinco práticas de rigor — especificação, teste, code review, ADR e métricas — que distinguem código que sobrevive ao primeiro incidente de código que vira o incidente.

• Especificação precisa — funciona como contrato entre intenção e implementação; reduz alucinação do output de IA.
• Teste como validação — código com cobertura de teste passa em produção com taxa muito maior do que código sem teste.
• Code review exigente — o revisor presume opacidade do código gerado por IA e exige explicação linha a linha.
• ADR para cada bloco crítico — registro de contexto, decisão, consequências e validação antes de integrar.
• Métricas acordadas antes da geração — taxa de erro, p95/p99, cobertura de branches, complexidade, vulnerabilidades.

Especificação como defesa contra alucinação

A diferença de qualidade entre prompt vago e prompt preciso para geração de código é exponencial, não linear. Quando a especificação é vaga, a IA alucina com confiança — produz código sintaticamente correto que resolve um problema diferente do que foi pedido. Quando a especificação é precisa, a taxa de erro do output cai cerca de 60%. Especificação é a primeira camada de defesa em desenvolvimento com IA.

Exemplo do mesmo pedido, em dois níveis de especificação:

• Vago: “Crie uma função que valida email.”
• Preciso: “Crie função que valida endereço de email conforme RFC 5322, rejeita domínios descartáveis (Guerrillamail, Tempmail, Mailinator), suporta subdomínios, não aceita endereços com mais de 254 caracteres, retorna código de erro tipado.”

A versão vaga delega à IA a decisão sobre o que significa “válido”. Como modelos generativos não são determinísticos na semântica, a função gerada pode decidir diferente a cada execução — e a próxima mudança de modelo refaz tudo. A versão precisa funciona como contrato entre intenção e implementação. Sem contrato, a IA decide; com contrato, o desenvolvedor decide e a IA executa.

Especificação inclui: input válido e inválido, comportamento sob erro, limites numéricos, dependências externas e formato de retorno. Quanto mais precisa a especificação, menor a chance de a IA preencher lacunas com suposições não declaradas. A prática operacional é simples: se a especificação couber em uma frase curta, a IA vai ter liberdade demais para alucinar.

Teste é validação, não aspiração

Vibe code assume “deve estar certo”. Código rigoroso verifica “está certo”. A diferença entre as duas frases é a diferença entre protótipo descartável e sistema em produção. Teste não é burocracia nem aspiração — é mecanismo de detecção de alucinação no desenvolvimento com IA.

Processo mínimo para cada bloco de código gerado por IA:

• (1) Escrever teste que especifica comportamento esperado (input, output, edge cases)
• (2) Gerar código com IA a partir do teste como especificação
• (3) Rodar teste contra código gerado
• (4) Se falha: refinar especificação ou rejeitar código e pedir nova geração
• (5) Se passa: revisar o código quanto a legibilidade, complexidade, edge cases não cobertos

Métrica observável em ambientes com geração assistida por IA: código com cobertura de teste passa em produção cerca de 85% das vezes. Código gerado sem teste tem cerca de 30% de chance de conter bug silencioso que se manifesta apenas em condição de contorno específica. A diferença não é de velocidade de escrita — é de taxa de falha em produção.

Teste executado antes de aceitar o código força a IA a produzir comportamento verificável em vez de comportamento plausível. Quando o teste falha de forma consistente, a causa raiz está na especificação, não no gerador. Refinar a especificação e regerar é mais barato do que investigar em produção.

Code review como pedagogia, não burocracia

Revisor de código gerado por IA tem função diferente de revisor de código humano. Em código humano, o revisor presume intenção e valida implementação. Em código gerado por IA, o revisor presume opacidade e exige explicação. A mudança de presunção é o que transforma o review de burocracia em pedagogia.

Perguntas que o revisor deve fazer ao autor de código gerado por IA:

• Por que a IA escolheu essa estrutura de dados? Qual seria a alternativa e por que foi rejeitada?
• Qual é a complexidade de tempo do algoritmo gerado? Em que cenário ela se degrada?
• Quais edge cases estão cobertos? Quais estão silenciosamente ignorados?
• Que bibliotecas externas foram importadas? Todas são necessárias? Alguma é overkill?
• Que suposições sobre o ambiente (versão de runtime, encoding, locale) estão implícitas no código?

Se o autor não consegue responder essas perguntas, o código não deve passar. Código sem explicação é código sem dono — e código sem dono é o primeiro candidato a bug silencioso em produção. Code review de output de IA é pedagogia porque obriga o autor a reivindicar a decisão mesmo que não tenha sido ele quem escolheu a estrutura. A IA é ferramenta; a decisão é do desenvolvedor. Quem submete, responde.

A diferença operacional: em código humano, o review pergunta “está correto?”. Em código gerado por IA, o review pergunta “o autor entende o que está submetendo?”. A segunda pergunta é mais barata de fazer e mais valiosa de responder.

Trace-back de decisão como prática obrigatória

Cada bloco de código gerado por IA precisa ter resposta documentada para a pergunta: “por que isso aqui, e não a alternativa?” Se a única resposta possível é “a IA sugeriu assim”, é alerta vermelho. O desenvolvedor precisa entender e concordar com cada decisão antes de integrar o código à base.

Prática operacional: manter arquivo de Architecture Decision Record (ADR) que, para cada trecho crítico gerado por IA, registra:

• Contexto: qual problema o código resolve
• Decisão: o que a IA gerou e qual alternativa o autor considerou
• Consequências: que trade-offs foram aceitos (complexidade, dependências, performance)
• Validação: que teste ou métrica confirma que a decisão está correta

O ADR não é documentação para futuro distante — é trilha de auditoria imediata que permite explicar ao próximo desenvolvedor (ou ao próprio autor três meses depois) por que o código está como está. Sem ADR, a única forma de recuperar o raciocínio é reverter o commit e reescrever do zero. O custo do ADR é baixo (uma página por decisão) e o custo da ausência é alto (retrabalho integral ou bug não rastreável).

Em times que praticam rigor com IA, o ADR é parte do critério de aceitação. Código sem ADR correspondente não entra em produção. A regra elimina o cenário em que a justificativa de uma decisão crítica desaparece junto com a janela de contexto da sessão de geração.

Métricas definem qualidade, não sensação

Vibe code usa critério subjetivo: “parece bom”. Código rigoroso usa critério mensurável: “atende as seguintes métricas”. A transição de sensação para número é o que separa review de opinião de review de engenharia.

Métricas mínimas a estabelecer antes de aceitar código gerado por IA:

• Taxa de erro em produção: número de incidentes por release, não volume de logs
• Tempo de resposta (p95, p99): latência sob carga real, não benchmark sintético
• Cobertura de teste: percentual de branches cobertos, não linhas executadas
• Complexidade ciclomática: limite máximo por função, com gate no code review
• Vulnerabilidades conhecidas: scan automatizado (Snyk, Trivy, dependabot) com bloqueio de merge

A regra é simples: métrica acordada antes da geração, não sensação depois. O oposto disso é a porta de entrada para o desastre em câmera lenta que o vibe code promete. Desenvolvimento com IA sem critério mensurável tem data de expiração: funciona até o primeiro release em que a suposição implícita deixa de ser verdadeira.

Métricas funcionam como detector de drift. Sem métrica acordada, o time detecta problema de qualidade apenas quando o cliente reclama. Com métrica acordada, o time detecta no momento do merge. O custo de detecção na borda do merge é ordens de grandeza menor do que o custo de detecção em produção.

Leitura relacionada

• Programação em par com IA: aceleração evolutiva — onde o rigor de aceite é substituído por alucinação compartilhada entre duas pessoas.
• Programação em par com IA: contexto define — onde a ausência de critério de aceitação vira justificativa para pular validação.
• Seu ORM não está salvando você — onde a IA substitui o critério humano de qualidade sem assumir a responsabilidade da decisão.