O Backlash do Vibecoding É Real — Mas Também Está Perdendo o Ponto
Esta semana, dois posts chegaram ao Hacker News com horas de diferença e ambos ultrapassaram 100 pontos antes do meio-dia. O primeiro: “The 100-Hour Gap Between a Vibecoded Prototype and a Working Product” — 315 pontos, 238 comentários, engenheiros compartilhando histórias de guerra sobre codebases geradas por IA que explodiram em produção. O segundo: “I’m 60 Years Old. Claude Code Killed a Passion” — 169 pontos, 124 comentários, devs mais velhos lamentando o que sentem como a automatização lenta do ofício de programar.
Dois posts, a mesma semana, a mesma comunidade. O backlash do vibecoding é oficialmente mainstream.
Está justificado? Sim e não. Aqui está o mapa real.
O que disparou o backlash
Quando Andrej Karpathy cunhou “vibe coding” no início de 2025, descreveu-o como entregar-se ao fluxo do output da IA — aceitar o código sem lê-lo muito, iterar por intuição. Viralizou porque era honesto e um pouco rebelde. Para meados de 2025, o interesse de busca em “vibe coding” havia saltado 6.700% (Exploding Topics).
Depois terminou a lua de mel.
Uma revisão de segurança de 15 aplicações construídas com ferramentas populares de vibecoding encontrou 69 vulnerabilidades. Investigações separadas descobriram que o código gerado por IA introduzia fatores de risco OWASP em 45% das amostras. Uma análise do CodeRabbit encontrou 1,7x mais bugs graves e 2,7x mais vulnerabilidades de segurança em código escrito por IA vs. código escrito por humanos.
E talvez o dado mais contraintuitivo: o estudo do METR descobriu que desenvolvedores experientes trabalhando em repositórios familiares eram na verdade 19% mais lentos usando ferramentas de IA — apesar de acreditarem que eram mais rápidos.
Enquanto isso, um artigo da Fast Company chamou-o de “vibe coding hangover”: engenheiros sênior lidando com codebases enormes geradas por IA que ninguém entendia completamente.
A raiva da comunidade faz sentido. Muita gente se moveu rápido, despachou software ruim, e agora está lidando com as consequências.
Mas os críticos também estão errando o ponto
Isto é o que os posts do backlash tendem a confundir: vibecoding como prática e vibecoding como filosofia.
O framing original de Karpathy — “esqueça que o código existe” — sempre foi a parte perigosa. Ninguém sério adotou isso ao pé da letra. Mas usar IA para gerar porções significativas do seu codebase? Isso está em todos os lugares agora. Google revelou que mais de 25% do seu código novo é gerado por IA. Gartner projeta que 60% de todo código novo será gerado por IA em 2026. O batch de inverno de 2025 do Y Combinator teve 25% de founders gerando 95%+ do seu código com IA.
A pergunta não é se usar IA no seu workflow. Esse barco já partiu. A pergunta é onde você a aplica e que nível de supervisão você traz.
Há uma divisão útil: zona verde vs. zona vermelha.
| Zona | O que contém | Risco do vibecoding |
|---|---|---|
 Verde |
Componentes UI, protótipos, ferramentas internas, scaffolding, CRUD | Baixo — itere rápido, os erros são baratos |
 Vermelha |
Business logic, autenticação, fluxos de pagamento, camada de dados, paths críticos de segurança | Alto — a IA não conhece suas políticas de segurança |
Aplicar geração por IA indiscriminadamente em ambas as zonas é onde as coisas saem do controle. Usá-la cirurgicamente na zona verde, com revisão real na zona vermelha, é onde vêm os ganhos de produtividade de 51% que todos mencionam.
O gap de 100 horas é real — e previsível
O título do post no HN acerta o problema real: existe um gap genuíno entre um protótipo vibecodeado que se parece bem em um demo e um produto pronto para produção. Nem sempre são 100 horas, mas o gap é real e vem de fontes previsíveis:
1. Débito técnico que se acumula. Os modelos de IA otimizam para “funciona agora”, não para “mantível em seis meses.” O resultado costuma ser código acoplado e não modular que é perfeito para demos e brutal para iterar. Um analista projeta $1,5 trilhão em débito técnico gerado por IA para 2027.
2. Gaps de segurança que você não sabia que existiam. A IA não conhece as políticas de segurança específicas da sua organização, suas regras de classificação de dados, nem essa API legada que espera um header em formato específico. Ela preenche os espaços em branco de maneiras que costumam introduzir vulnerabilidades que apenas aparecem sob condições reais.
3. Perda de contexto em escala. Os protótipos começam pequenos, mas os codebases crescem. Quanto mais longe você está da geração inicial, mais difícil é guiar a IA produtivamente sem uma spec estruturada à qual ela possa se referir. Por isso existem ferramentas como workflows baseados em specs e arquivos CLAUDE.md — são uma resposta direta a este problema.
A pergunta do ofício é mais difícil
O post “tenho 60 anos e Claude Code matou uma paixão” está tocando um nervo diferente. Não um técnico — um de identidade.
Vale a pena levá-lo a sério, mesmo que você não tenha 60. Há uma diferença real entre programar como ofício — a satisfação de resolver um problema através do seu próprio entendimento — e programar como mecanismo de entrega. A IA colapsa o segundo. Não toca o primeiro.
Dario Amodei em Davos disse que os engenheiros da Anthropic já pararam de escrever código manualmente — eles dirigem a IA e revisam o output. Sam Altman disse que a IA já escreve até 50% do código em muitas organizações. Ambos vendem ferramentas de IA, então desconte o hype. Mas a direção é clara: o meio de expressão está mudando.
Os devs que melhor estão navegando isso não são os que “se entregam aos vibes” nem os que se recusam a usar IA. São os que redefiniriam em que consiste sua habilidade. Menos: “Escrevo funções.” Mais: “Projeto sistemas, especifico o intent com precisão, e sei como deve parecer o output correto.”
Isso continua sendo um padrão alto. Apenas é um diferente.
Um framework prático para decidir
Antes de pegar uma ferramenta de vibecoding para qualquer tarefa, pergunta a si mesmo:
1. Isso é descartável ou vai para produção?
Prototipagem, ferramentas internas e MVPs — gere livremente, revise seletivamente. Sistemas de produção — gere com spec ajustado, revise tudo na zona vermelha.
2. Posso fazer debug do que retorna?
Se você não consegue ler e entender o código gerado, não pode se apropriador dele. O gargalo passa de geração para verificação — e se você não estiver equipado para verificar, está acumulando risco, não velocidade.
3. O repositório é familiar ou novo?
A desaceleração de 19% no estudo do METR veio de devs trabalhando em codebases existentes e complexos. Em código novo, a IA é mais rápida. Em sistemas legados com muito contexto que a IA não tem, a matemática costuma se inverter.
4. Isso toca autenticação, pagamentos ou dados?
Zona vermelha. Aplique critério de engenharia humana antes de fazer deploy de qualquer coisa gerada por IA nesses paths.
A conclusão
O backlash do vibecoding é um sinal de maturidade, não uma sentença de morte. Quando uma tecnologia passa de “magia” para “isso causou problemas reais e as pessoas estão enojadas”, significa que está sendo usada de verdade — em escala, em produção, por gente que tem algo em jogo.
O caminho a seguir não é abandonar o código gerado por IA. É ser explícito sobre seus modos de falha e construir workflows que os contemplem. Os devs que ganham em 2026 não são os que vibecodearam mais forte nem os que se recusaram a tocar o output da IA. São os que sabem exatamente quando deixar a IA correr e quando voltar a pegar o volante.
Você concorda que o backlash é um sinal de maturidade, ou acredita que há algo mais profundo em jogo? Deixe sua opinião nos comentários. 