O preço do vibe coding

Em março de 2026, o Claude Code de um projeto educacional executou terraform destroy em produção. Deletou 2.5 anos de dados. 1.94 milhão de linhas. 100 mil alunos afetados. O time do DataTalks.Club não pediu para o agente destruir nada. Ele decidiu sozinho que era a coisa certa a fazer.

No mesmo mês, a Amazon teve um deploy assistido por IA que derrubou o site por 6 horas. 99% dos pedidos nos EUA pararam. Estimativa: 6.3 milhões de pedidos perdidos num único dia.

Eu leio essas histórias e não fico surpreso. Fico é pensando em quantas vezes quase aconteceu comigo.

19 incidentes e contando

O Crackr.dev mantém um registro de incidentes documentados. Na data em que escrevo são 19. Alguns dos piores:

O Moltbook expôs 1.5 milhão de tokens de autenticação e 35 mil emails por causa de um Supabase mal configurado. Os devs construíram tudo com IA e na pressa não perceberam que o banco estava aberto para a internet.

O Orchids teve uma vulnerabilidade zero-click demonstrada ao vivo na BBC. O pesquisador hackeou o laptop do reporter durante a entrevista. 1 milhão de usuários em risco.

O Replit AI Agent violou um code freeze e apagou o banco de produção do SaaStr. Meses de dados. O agente achou que precisava "reconstruir" o ambiente.

Em 2025, o time de red team da Databricks pediu para o Claude criar um jogo multiplayer. O jogo funcionava. Também tinha uma vulnerabilidade de execução remota de código que dava acesso a toda a rede. O Claude usou serialização insegura com pickle e ninguém revisou.

O padrão se repete: código que funciona, que compila, que passa nos testes que existem. E que tem um buraco do tamanho de um caminhão que nenhum linter vai pegar.

Os números são feios

A Tenzai analisou 15 apps construídos por 5 ferramentas de AI coding. 69 vulnerabilidades. Nenhum app com CSRF protection. Todos com SSRF. Zero headers de segurança. Quinze apps, cinco ferramentas, e nenhuma acertou o básico.

O Veracode 2025 GenAI Code Security Report: 45% do código gerado por IA tem falhas de segurança. XSS aparece em 86% dos casos. SQL injection em 20%. Em 2026.

A Escape.tech escaneou 5.600 apps vibe-coded. 2.000 vulnerabilidades. 400 secrets expostos. Chaves de API, tokens, credenciais jogadas no código como se fosse um tutorial do YouTube.

CVEs atribuídos a código gerado por IA: 6 em janeiro de 2026, 35 em março. Essa curva não desacelera.

Por que acontece

IA gera código que roda. Não código que é seguro.

O modelo não entende por que um check de segurança existe. Ele prevê o próximo token baseado em padrões estatísticos. Se o padrão mais comum no training data é código sem CSRF protection (porque a maioria dos tutoriais não inclui), o modelo gera código sem CSRF protection.

Quando você vibecoda, aceita o output e segue em frente, ninguém faz a pergunta que um dev sênior faria: "e se esse input vier malformado?", "o que acontece se dois requests chegarem ao mesmo tempo?", "quem tem acesso a esse endpoint?"

Ninguém faz essas perguntas porque ninguém está revisando. Esse é o ponto.

O que eu fiz de diferente

Eu uso IA para tudo. Todo o código que entra nos meus projetos passa por um agente. Mas eu não aceito nada sem revisar. E eu configurei o processo para que a revisão seja inevitável, não opcional.

Cada projeto meu tem um CLAUDE.md com regras explícitas. "Nunca commitar sem rodar testes." "Nunca alterar schema do banco sem perguntar." "Nunca expor endpoints sem autenticação."

Eu escrevo specs antes de pedir qualquer implementação. Não specs de 50 páginas. Um parágrafo: o que, por que, e como eu vou verificar que está certo.

E eu decomponho em tarefas pequenas. Em vez de "cria o sistema de pagamentos", eu peço "cria o endpoint de checkout que recebe um cartão tokenizado e retorna um ID de transação. Quando os créditos forem insuficientes, retorna 402."

Isso não elimina erros. Mas quando o agente erra, eu sei exatamente o que deveria ter acontecido. A spec é o gabarito.

O ponto

Vibe coding funciona para protótipos. Eu mesmo uso quando quero testar uma ideia em 30 minutos. Mas protótipo é uma coisa. Produção é outra.

Os 19 incidentes do Crackr.dev têm uma coisa em comum: código aceito sem revisão humana. O DataTalks.Club não revisou. O Moltbook não revisou. O SaaStr não revisou. E pagaram.

Não é a IA que falha. É a ausência de alguém que pergunta "isso está certo?" antes de ir para produção. Essa pergunta leva 5 minutos. Não fazer ela pode custar 6 horas de downtime na Amazon, 2.5 anos de dados no DataTalks.Club, ou a reputação inteira da sua empresa no Crackr.dev.