O dia em que o criador do BitTorrent perdeu a paciência

Bram Cohen não é exatamente o tipo de pessoa que sai por aí reclamando na internet. O cara criou o BitTorrent, revolucionou a distribuição de arquivos e geralmente mantém um perfil técnico, focado. Mas na primeira semana de abril de 2026, ele publicou um texto com o título “The Cult of Vibe Coding is Insane” — e o Hacker News explodiu.

O post atingiu mais de 400 pontos em poucas horas. E a razão é simples: ele disse em voz alta o que muita gente no mercado já sentia, mas tinha medo de falar. Que essa história de “vibe coding” — aceitar código gerado por IA sem nem olhar o que tá ali dentro — não é produtividade. É negligência.

E ele não tá sozinho. Um estudo recente da Tenzai testou 5 das ferramentas de código com IA mais populares e encontrou 69 vulnerabilidades em apenas 15 aplicações. Seis delas críticas. Nenhuma das apps tinha proteção CSRF. Zero headers de segurança. E todas — todas — tinham falhas de SSRF.

Mas antes de entrar nos números, vale entender como chegamos aqui.

Vibe coding: de meme a metodologia (e isso é o problema)

O termo “vibe coding” nasceu com Andrej Karpathy em fevereiro de 2025. Num tweet, ele descreveu seu novo fluxo de trabalho: abrir o cursor, descrever o que queria em linguagem natural, aceitar tudo que a IA sugeria e seguir em frente. “I just see things, say things, run things, and copy-paste things, and it mostly works.”

Era uma piada. Um experimento de fim de semana. Mas a internet é a internet — e o que era brincadeira virou filosofia de trabalho para milhares de devs.

A ideia central do vibe coding é deliberadamente não ler o código que a IA gera. Você descreve o que quer, a IA produz, você testa se funciona e segue adiante. Se quebrar, pede pra IA consertar. Olhar o código é, na prática, “trapaça”.

Eu entendo a atração. Sério. Quem nunca quis pular aquele boilerplate chato de autenticação e ir direto pro que interessa? O problema é que boilerplate chato de autenticação é exatamente onde mora a segurança da sua aplicação.

69 vulnerabilidades, 15 apps, 5 ferramentas: o estudo que ninguém queria ver

A Tenzai publicou em dezembro de 2025 um dos estudos mais importantes sobre segurança de código gerado por IA. O setup era simples: pegar cinco ferramentas populares — Claude Code, OpenAI Codex, Cursor, Replit e Devin — e pedir para cada uma construir três aplicações web idênticas a partir dos mesmos prompts.

Quinze apps. O mesmo conjunto de requisitos. Sem instruções extras de segurança (porque vibe coders não dão instruções extras de segurança).

Os resultados:

Total: 69 vulnerabilidades. Cerca de 45 classificadas como low-medium, várias como high, e meia dúzia como críticas.

Mas o número absoluto não é o mais assustador. O padrão é.

O que as IAs acertam

Pra ser justo, as ferramentas se saíram bem em algumas coisas:

• SQL Injection: zero vulnerabilidades exploráveis em todas as 15 apps. Os frameworks modernos (ORMs, prepared statements) resolvem isso por padrão, e as IAs usam esses frameworks corretamente.
• XSS: também zero casos exploráveis, pelo mesmo motivo — React, Vue e similares escapam output por padrão.

Ou seja: quando o framework resolve o problema automaticamente, a IA não atrapalha. Ótimo.

O que as IAs erram — sempre

Agora o bicho pega:

• SSRF (Server-Side Request Forgery): 100% das ferramentas introduziram essa vulnerabilidade. Todas. Cinco de cinco.
• CSRF: nenhuma — zero — das 15 aplicações implementou proteção contra Cross-Site Request Forgery.
• Headers de segurança: nenhuma app incluiu Content-Security-Policy, Strict-Transport-Security ou X-Frame-Options.
• Rate limiting: apenas uma ferramenta tentou implementar — e fez errado.
• Autorização: falhas consistentes em lógica de autorização complexa. Tipo, um usuário conseguir editar dados de outro.
• Validação de negócio: quantidades negativas, preços negativos — coisas que nenhum dev humano deixaria passar num code review.

A conclusão da Tenzai é cirúrgica: “Coding agents cannot be trusted to design secure applications without explicit security directives.”

Traduzindo: a IA é boa quando o framework faz o trabalho pesado. Quando a segurança depende de contexto — de entender o que aquele endpoint específico faz e por que ele precisa de proteção — ela falha. Consistentemente.

O argumento de Bram Cohen: “Software ruim é uma escolha”

O texto de Cohen no Substack vai além das vulnerabilidades. Ele ataca a filosofia em si.

O ponto central dele: vibe coding puro é impossível. Mesmo quem diz que não olha o código ainda define a infraestrutura, escolhe frameworks, configura o ambiente. A diferença é que, ao se recusar a examinar o que a IA produziu, você torna toda essa contribuição humana menos eficaz.

Ele dá um exemplo concreto. Um revisor humano encontrou duplicação massiva de código no sistema do Claude — coisas classificadas simultaneamente como “agents” e “tools”, criando redundância que ninguém na equipe tinha identificado. Por quê? Porque ninguém estava olhando.

E aqui tá a ironia que Cohen destaca: a IA é excelente para limpeza de código. Ele pessoalmente usa prompts como “Let’s audit this codebase for unreachable code” ou “This function makes my eyes bleed” para iniciar conversas produtivas de refatoração. A ferramenta é poderosa — quando você direciona. Quando você não direciona, ela produz lixo com confiança.

“Bad software is a decision you make.” Software ruim é uma decisão sua. Não da IA.

Os números que assustam: code churn, duplicação e dívida técnica

O problema do vibe coding não é só segurança. É manutenabilidade.

Um relatório da CodeRabbit analisou 470 pull requests open-source no GitHub e encontrou que código co-autorado por IA generativa continha aproximadamente 1.7x mais issues “major” comparado a código escrito por humanos. As taxas de erros de lógica — dependências incorretas, fluxo de controle falho — eram significativamente mais altas. E vulnerabilidades de segurança? 2.74x mais frequentes.

Outros números que circulam na indústria:

• Code churn (código escrito e deletado rapidamente) subiu 41%
• Duplicação de código quadruplicou
• Refatoração — o tipo de trabalho cuidadoso que mantém uma codebase saudável — caiu de 25% das linhas alteradas em 2021 para menos de 10% em 2024

Pense nisso um segundo. Estamos gerando mais código, mais rápido, com mais bugs, mais duplicação, e fazendo menos manutenção. Isso não é uma receita de produtividade. É uma bomba-relógio.

“Mas funciona na minha máquina!”

Eu já ouvi esse argumento dezenas de vezes em discussões sobre vibe coding: “Tá, mas eu testei e funciona.” E é verdade — funciona. Num ambiente controlado, com dados de teste, sem atacantes, sem edge cases, sem escala.

O problema é que “funciona” e “é seguro” são coisas completamente diferentes. Uma aplicação com SSRF funciona perfeitamente — até alguém descobrir que pode fazer seu servidor chamar endpoints internos. Uma app sem CSRF funciona lindamente — até alguém criar uma página maliciosa que faz ações no nome do seu usuário logado.

E aqui tá o ponto que a galera do vibe coding ignora: você não sabe o que não sabe. Se você não lê o código, não sabe quais proteções estão faltando. Você não sabe que o endpoint de upload aceita qualquer tipo de arquivo. Não sabe que a API de admin tá exposta sem autenticação. Não sabe que o rate limiting não existe e seu serviço pode ser derrubado com um loop.

Ignorância não é proteção. É exposição.

O paradoxo dos 92%

Uma pesquisa recente mostrou que 92% dos desenvolvedores já usam alguma forma de assistência de IA no código. Ao mesmo tempo, a confiança nessas ferramentas desabou. O que tá acontecendo?

Simples: a galera começou a usar em produção.

Enquanto vibe coding era coisa de side project, de protótipo, de hackathon — tudo bem. Ninguém se importa se o app de lista de compras do seu fim de semana tem uma vulnerabilidade de SSRF. Mas quando empresas começaram a colocar código vibe-coded em produção, os problemas apareceram. Apps quebraram. Falhas de segurança foram encontradas. Codebases ficaram unmaintainable.

E agora temos uma geração de desenvolvedores que aprendeu a gerar código sem nunca ter aprendido a ler código. Isso é mais perigoso do que qualquer vulnerabilidade individual.

O caminho do meio: IA como ferramenta, não como piloto

Antes que alguém me acuse de ser ludita: eu uso IA pra escrever código. Todo dia. E ela é absurdamente útil — quando usada direito.

O que funciona:

• Geração de boilerplate: setup de projeto, configuração, scaffolding. Coisas onde o padrão é bem definido.
• Refatoração guiada: “extraia esse bloco em uma função”, “converta isso para async/await”, “remova código morto nesse arquivo”.
• Code review assistida: pedir pra IA analisar um diff e apontar possíveis problemas.
• Testes: gerar testes unitários a partir de código existente. A IA é surpreendentemente boa nisso.
• Documentação: gerar docstrings, comentários de API, exemplos de uso.

O que não funciona:

• Aceitar output sem ler: o estudo da Tenzai deixou claro que isso gera vulnerabilidades.
• Delegar decisões de arquitetura: a IA otimiza localmente, não globalmente. Ela não entende o contexto do seu negócio.
• Ignorar code review: se você não revisaria código de um junior sem review, por que revisaria código de uma IA?
• Pular testes de segurança: a IA não vai colocar headers de segurança se você não pedir. Ponto.

Bram Cohen resumiu bem: a IA é uma ferramenta de limpeza extraordinária quando você dá direção. O problema nunca foi a ferramenta. Foi a decisão de não olhar.

SSRF, CSRF e a sopa de letrinhas que vai te hackear

Pra quem não é da área de segurança, vale um resumo rápido das vulnerabilidades que as IAs consistentemente ignoram:

SSRF (Server-Side Request Forgery): o atacante faz seu servidor enviar requisições para onde ele quiser. Isso pode expor serviços internos, metadata de cloud (chaves AWS, por exemplo), ou servir como pivot para ataques mais sérios. Presente em 100% das apps do estudo.

CSRF (Cross-Site Request Forgery): o atacante cria uma página que faz seu navegador executar ações numa aplicação onde você está logado. Sem proteção CSRF, qualquer site pode transferir dinheiro, mudar senhas ou deletar dados em nome do usuário. Zero proteção nas 15 apps.

Headers de segurança ausentes: Content-Security-Policy previne XSS em cenários que o framework não cobre. HSTS força HTTPS. X-Frame-Options impede clickjacking. Sem eles, sua aplicação tá aberta a uma série de ataques que frameworks sozinhos não resolvem.

Falhas de autorização: a IA frequentemente implementa autenticação (verificar quem é o usuário) mas esquece a autorização (verificar o que ele pode fazer). Resultado: usuários acessando dados de outros usuários.

Nenhuma dessas é novidade. Estão todas no OWASP Top 10 há anos. Mas a IA continua ignorando — porque são problemas de contexto, não de padrão.

Uma anedota pessoal (e um alerta)

Eu recentemente testei algo parecido com o setup da Tenzai, numa escala menor. Pedi pra uma IA gerar uma API REST simples com autenticação JWT, CRUD de usuários e upload de arquivos. Levou menos de 5 minutos.

Tudo funcionava. Login, cadastro, upload, listagem. Bonito até.

Aí eu olhei o código. O token JWT era assinado com uma chave hardcoded “secret123”. O endpoint de upload aceitava qualquer extensão — incluindo .exe. E o endpoint de listar usuários retornava os hashes de senha no response. Três vulnerabilidades graves em cinco minutos de geração. Teria levado dois minutos de code review pra pegar todas.

Mas se eu estivesse vibe coding de verdade, eu teria testado no Postman, visto que funcionava, e feito deploy. Com uma chave JWT quebrável em 3 segundos.

O que muda daqui pra frente

Vibe coding, no sentido original de Karpathy — aceitar output de IA sem revisão e seguir em frente — já morreu como estratégia profissional legítima. Os dados mataram.

O que veio pra ficar é o que eu chamaria de AI-assisted coding com supervisão: usar a IA para acelerar, mas manter o humano no loop. Ler o código. Rodar análise estática. Ter um checklist de segurança. Fazer code review — mesmo que seja você revisando seu próprio código gerado por IA.

A conferência EASE 2026 vai até ter um workshop chamado VibeX sobre o tema. A academia percebeu que isso é sério.

E talvez a lição mais importante: velocidade sem qualidade não é produtividade. É dívida. E dívida técnica, como dívida financeira, cobra juros compostos.

Eu prefiro levar 30 minutos a mais num feature e dormir tranquilo sabendo que meu endpoint não tá aberto pro mundo. E você?

Fonte de inspiração: The Cult of Vibe Coding is Insane, por Bram Cohen (Hacker News, abril 2026) e Bad Vibes: Comparing the Secure Coding Capabilities of Popular Coding Agents, por Tenzai.

👉 Leia também:
• Claude Encontrou um Bug no Linux que Ninguém Viu por 23 Anos
• 5 Comandos Git que Ninguém Te Ensinou (Mas Deveria)

• A IA Escapou da Caixa: Os Piores Bugs, Vazamentos e Falhas de Segurança Causados por Inteligência Artificial