Andrej Karpathy popularizou o termo "vibe coding" em 2024: um modo de desenvolvimento em que você descreve o que quer para um LLM, aceita o código gerado, e continua sem ler o que foi escrito. "O vibes são bons" — o código funciona, você vai em frente.

Para demos, experimentos e protótipos pessoais, isso funciona. Mas existe uma conversa importante que o hype em torno do vibe coding está adiando: quais são as implicações reais de colocar em produção código que o engenheiro não leu, não entende, e não consegue manter?

O que "vibe coding" captura de verdade

A ideia por trás do vibe coding não é nova — é o mesmo argumento de sempre a favor de abstração. Quanto menos você precisa pensar em implementação, mais energia vai para o problema que realmente importa.

E há verdade nisso. Tarefas repetitivas, boilerplate, transformações bem definidas, geração de testes para casos óbvios — IA faz tudo isso bem, e há pouco valor em fazer manualmente. Aceitar código gerado para essas tarefas sem ler linha a linha é razoável.

O problema começa quando o "vibe" se estende para lógica de negócio, segurança, performance e decisões de arquitetura — as partes onde estar errado tem custo real.

O que a IA não sabe sobre o seu contexto

LLMs são excelentes em padrões. São limitados em contexto específico. Eles não sabem:

  • As invariantes de negócio do seu domínio que um bug pode violar
  • Os contratos implícitos entre partes do sistema que só existem na cabeça do time
  • As propriedades de performance que o sistema precisa manter sob carga real
  • Os requisitos de segurança específicos do seu produto e dos seus usuários
  • O histórico de decisões de trade-off que fizeram o sistema ser como é

Código gerado por IA é correto no contexto do que o modelo foi treinado. Pode ser incorreto no contexto do seu sistema — e a única forma de saber é entender o que foi gerado.

O argumento dos testes

Um contra-argumento comum: "Não preciso entender o código se tiver testes suficientes." O problema: testes também podem ser gerados por IA, com os mesmos gaps de contexto. Testes gerados cobrem o que o modelo acha que deve ser coberto — não necessariamente o que você precisa cobrir.

Além disso, código que você não entende é código que você não consegue debugar quando quebra em produção. E vai quebrar. A questão é se você vai entender por quê.

A escala do problema em produção

Em projetos pessoais e protótipos, o custo de bugs é baixo. Em produção com usuários reais:

  • Um bug de segurança introduzido por código gerado sem revisão adequada pode expor dados de usuários
  • Uma race condition em lógica de pagamento pode criar transações duplicadas
  • Um memory leak num componente gerado pode derrubar o serviço sob carga
  • Uma falha em validação de input pode abrir vetor de injection

Nenhum desses cenários é hipotético. Todos acontecem com código gerado por humanos também — mas código que o engenheiro leu, entendeu e revisou tem muito mais chances de ter esses problemas capturados antes de produção.

O modelo correto: IA como par, não como substituto

O frame mais útil: IA como pair programmer, não como desenvolvedor autônomo. Você ainda toma decisões, revisa o que foi gerado, e é responsável pelo resultado.

Na prática isso significa:

  • Você descreve o problema, a IA gera uma solução — você lê e entende antes de aceitar
  • Para lógica de negócio, você revisa com o mesmo rigor que revisaria código de um junior
  • Para código de segurança, você verifica o que está sendo feito, não só que parece funcionar
  • Você mantém a capacidade de explicar o que o código faz — se não consegue, você não revisou o suficiente

Onde o vibe coding faz sentido

Para ser justo: existe espaço legítimo para aceitar código gerado com menos revisão. Scripts de automação internos. Prototipagem rápida. Código de teste com lógica simples. Migrations bem delimitadas. Nesses contextos, o custo de uma revisão profunda é desproporcional ao risco.

A distinção que importa: o engenheiro sabe em que parte do espectro está, e ajusta o nível de revisão de acordo. Vibe coding como modo default para tudo é o problema — não a IA em si.