Vibe coding: o que é, o que não é, e por que está dividindo a indústria
RESUMO
Karpathy cunhou vibe coding como aceitar diffs sem ler. Em 2026 o termo cobre três práticas opostas. A versão útil é uma escolha sobre leitura, modelo e ferramenta — não uma postura genérica de 'usar IA pra programar'.
Karpathy cunhou o termo em fevereiro de 2025 num post no X — "eu vejo o que diz, copio e colo, rodo, vejo o que dá errado, copio e colo o erro de volta". Um ano depois, "vibe coding" significa três coisas diferentes na boca de três pessoas diferentes, e a maior parte da briga online é gente discutindo práticas opostas com o mesmo nome.
Para mim, a versão útil do termo é específica: aceitar o diff sem ler, deixar o modelo conduzir, sair do loop de revisão linha a linha. Isso é uma escolha técnica. Não é "usar IA para programar" — isso é outra coisa, que a indústria chama de AI-assisted coding, e que envolve ler tudo que o modelo escreve antes de aceitar. As duas práticas têm sobreposição zero no que pedem do programador, e juntá-las no mesmo guarda-chuva é o que faz a discussão andar em círculos.
As três decisões que vibe coding embute
Quando escolho fazer vibe coding genuíno — e eu faço, regularmente — estou tomando três decisões juntas, mesmo que não as escreva no papel.
Primeira decisão: leio ou não leio. Vibe coding é o lado "não leio" do espectro. Não é descuido — é uma aposta calculada de que o custo da falha cabe no orçamento, então o tempo gasto lendo o diff não compensa. AI-assisted coding é o outro lado: leio tudo, aceito por trecho, intervenho na arquitetura. As duas são legítimas. Confundi-las é o problema.
Segunda decisão: qual modelo. Vibe coding com Claude Sonnet 4.5 num script de glue code tem perfil de risco diferente de vibe coding com um modelo open-source de 8B parâmetros num endpoint de produção. O termo, sozinho, não carrega essa informação. Quem usa "vibe coding" como bandeira ideológica geralmente está omitindo qual modelo, e essa omissão sustenta metade dos desentendimentos.
Terceira decisão: qual ferramenta. Cursor com auto-aceitar e teste rodando a cada salvamento é uma coisa. Copiar e colar do chat para o editor sem nenhum gate automático é outra. Lovable gerando 170 apps com controle de acesso invertido é uma terceira. As três aparecem juntas nas conversas de Twitter como se fossem a mesma prática, e não são.
Onde eu faço, onde eu não faço
Semana passada precisei de um script que pegasse uma planilha exportada de um sistema antigo, casasse colunas por aproximação de nome, e cuspisse um JSON normalizado. Tarefa morta — escrevi o prompt, deixei o Claude conduzir, aceitei o que veio, rodei, vi que faltava tratar um caso de acentuação, devolvi o erro, aceitei a correção. Vinte minutos. Não li nada além do output. Vibe coding genuíno, e a escolha foi consciente: se o script errasse, eu rodava de novo. O custo do erro era um café perdido.
No mesmo dia, mexi num trecho que lidava com webhook de pagamento de um cliente. Mesmo modelo, mesma ferramenta, postura completamente diferente. Li cada linha do diff, questionei a estrutura do retry, mandei reescrever a parte de idempotência três vezes. Não foi vibe coding. Foi AI-assisted coding com a IA na função de digitar mais rápido do que eu. As duas tarefas usaram o mesmo Cursor, o mesmo modelo, o mesmo prompt-base — e exigiram modos de trabalho irreconciliáveis.
A diferença não é o ferramental. É a resposta à pergunta "o que acontece se isso der errado?". Glue code que dá errado roda de novo. Webhook de pagamento que dá errado vira ticket, vira reembolso, vira CNPJ na lista do Procon.
O custo de não fazer a escolha
A versão útil do vibe coding economiza horas reais. Não horas teóricas — horas de verdade, que eu meço pelo número de tarefas chatas que saem do backlog por semana. Confesso isso sem nuance: para trabalho de baixa consequência, ler o diff é desperdício, e fingir o contrário é teatro de seriedade.
O custo, e ele precisa estar na mesma frase, é que quando algo dá errado num código que você nunca leu, você não tem o modelo mental para depurar. Reescrever do zero pode ser mais rápido do que entender o que o modelo fez. Isso é tolerável para um script de migração; é catastrófico para o sistema que processa os pedidos da Black Friday. A regra prática é: vibe coding vale quando o custo da eventual reescrita cabe no ROI da economia inicial. Quando não cabe, leia.
A maior parte das histórias de terror que circulam sobre vibe coding não é sobre a prática em si. É sobre alguém que caiu no termo por inércia — viu no Twitter, copiou a vibe, aplicou em código que merecia leitura, e descobriu tarde que tinha confundido glue code com sistema de produção. O termo foi usado como álibi para não decidir.
A pergunta prática, então, não é "vibe coding ou não". É: você fez a escolha conscientemente para esta tarefa específica, ou só caiu no termo?
Tem um caso onde isso se aplica? Vamos conversar sobre como implementar.