Vibe coding: onde quebra e o que fazer depois do protótipo

Vibe coding virou o termo do momento. Saiu de um tweet jogado num sábado e chegou ao dicionário Collins como palavra do ano de 2025. Todo grupo de dev fala disso, toda thread no X discute, e tem gente entregando produto inteiro sem ler uma linha do que a IA escreveu.

A promessa é sedutora: você descreve o que quer, o modelo cospe o código, e o software simplesmente aparece. Parece mágica. Até o dia em que você precisa debugar quatro mil linhas que ninguém entende — nem a IA que escreveu.

Neste post a gente separa o que vibe coding é de verdade, onde ele acelera o seu trabalho, e onde ele vira dívida técnica silenciosa. Com número, fonte e dor de produção real. Sem hype e sem pânico.

TL;DR

• O que é: construir software conversando com a IA, aceitando o código gerado sem revisar a fundo.
• Origem: termo cunhado por Andrej Karpathy em 6 de fevereiro de 2025, num tweet que passou de 4,5 milhões de visualizações.
• Onde brilha: protótipo, MVP, script descartável, validar uma ideia no fim de semana.
• Onde quebra: produção, código que precisa durar, segurança e qualquer coisa que outra pessoa vá manter.

O que é vibe coding, de verdade

O termo nasceu na mão do Andrej Karpathy, ex-diretor de IA da Tesla e fundador da OpenAI. A definição original dele é literal:

"Tem um novo tipo de programação que eu chamo de 'vibe coding', onde você se entrega totalmente às vibes, abraça os exponenciais e esquece que o código existe."

Repara na última parte: esquecer que o código existe. Você fala com o agente, ele escreve, você nem abre o diff. Deu erro? Cola a mensagem de volta e pede pra arrumar. Não funcionou? Pede uma mudança aleatória até parar de reclamar.

O detalhe que quase todo mundo ignora: o próprio Karpathy descreveu isso para projetos descartáveis de fim de semana. Não para o sistema que processa o pagamento do seu cliente.

O Simon Willison afiou a definição e fez a distinção que importa:

"Se um LLM escreveu o código pra você, e você revisou, testou direito e garantiu que consegue explicar como funciona... isso não é vibe coding, é desenvolvimento de software."

Essa é a linha. Vibe coding não é "usar IA pra programar". Vibe coding é abrir mão da compreensão. Usar Cursor, Claude Code, Codex ou Copilot, ler o que eles produzem, testar e entender — isso é engenharia com IA. Continua sendo o seu trabalho. A diferença não está na ferramenta. Está na sua relação com o resultado. Se você quer o mapa de quando cada abordagem performa, a gente já comparou vibe coding, SDD e agentic code lado a lado.

Onde vibe coding acelera (e é legítimo)

Não vou cair no time do hate. Vibe coding tem lugar.

Quando o custo de errar é zero, velocidade ganha de rigor. Quer testar se uma ideia de produto faz sentido antes de investir uma semana? Vibe coda o protótipo. Precisa de um script que roda uma vez pra limpar um CSV de dez mil linhas? Vibe coda e joga fora. Tá explorando uma API que nunca usou e quer ver a forma da resposta? Conversa com o modelo e descobre rápido. Hoje isso nem passa mais só pelo editor: geradores de app como Lovable, v0, Bolt e Replit entregam um protótipo navegável em minutos, e Cursor, Claude Code e Codex fazem o mesmo dentro do repositório.

Nesses cenários, o código não precisa durar. Não vai para produção. Ninguém vai manter. O valor está em chegar na resposta, não no artefato. É aqui que a velocidade da IA é uma arma absurda — e seria burrice não usar.

A pesquisa confirma a adoção. Pela Stack Overflow Developer Survey de 2025, 84% dos desenvolvedores profissionais já usam ou planejam usar ferramentas de IA. O problema não é a adoção. É achar que o que funciona no protótipo funciona em produção.

Onde vibe coding quebra — a dívida técnica silenciosa

Aqui mora o perigo. E os números de 2025 e 2026 são desconfortáveis.

A Veracode testou mais de 100 LLMs em tarefas de código sensível a segurança. O resultado: 45% das amostras geradas por IA introduzem alguma vulnerabilidade do OWASP Top 10. 86% falharam em se defender de cross-site scripting. 88% eram vulneráveis a log injection. Isso não é caso de borda. É quase metade.

E vai além do código. Segundo a Cloud Security Alliance, os CVEs formalmente atribuídos a código gerado por IA saltaram de 6 em janeiro de 2026 para 35 em março de 2026 — e os pesquisadores estimam que o número real seja de 5 a 10 vezes maior, porque a maioria das ferramentas não deixa rastro no commit. Commits assistidos por IA expõem segredos (chaves, senhas, tokens) a mais que o dobro da taxa de commits feitos só por humanos: 3,2% contra 1,5%.

A conta de produtividade engana. Dá pra commitar de 3 a 4 vezes mais rápido com IA. Mas se você introduz problemas de segurança a 10 vezes a taxa normal, você não ganhou velocidade — você adiou o pagamento. E a fatura vem com juros. A própria CodeRabbit mediu que código de IA carrega 1,7x mais bugs e 1,4x mais problemas críticos que código humano.

A dívida técnica do vibe coding tem uma assinatura específica:

O código funciona.

Você não sabe exatamente por quê.

Aí ele quebra em produção, três da manhã.

E você está lendo um código que você não escreveu, debugando uma lógica que você nunca aprendeu.

Esse é o momento em que a mágica cobra o preço. A IA escreveu rápido. Mas ela não entende o seu sistema melhor do que você — e quando você não entende o sistema, ninguém entende.

Protótipo vs. produto: a lista do que falta

O protótipo vibe-codado funciona. Esse é justamente o problema. Ele funciona o bastante pra você mostrar pro time, o time gostar e alguém dizer "então sobe em produção". A distância entre esses dois estados não é mais código — são quatro decisões que ninguém tomou porque ninguém precisou tomar. Elas nunca aparecem no dia 1. Aparecem juntas, na semana 3.

1. Estado: não há persistência pensada. O protótipo guarda o histórico numa lista em memória do processo, ou joga o objeto inteiro num JSON por sessão. Funciona com um usuário e um worker. O sintoma da semana 3: o app subiu com dois containers atrás de um load balancer e o usuário perde o contexto sempre que a requisição cai no outro pod. Quando alguém "resolve" salvando tudo no banco, a leitura de uma conversa de 200 turnos passa a puxar alguns megabytes só pra remontar o prompt. Ninguém decidiu o que é fonte de verdade, o que é cache, o que expira e o que pode ser resumido. O modelo escolheu a estrutura mais rápida de escrever, não a mais fácil de operar.

2. Custo: ninguém mediu token. No protótipo você roda dez vezes e a conta é irrelevante. O sintoma da semana 3 é o alerta de billing — e quase sempre pela mesma causa: o agente remonta o contexto inteiro a cada passo. Faça a conta com números redondos: 12 mil tokens de input por chamada, 8 chamadas por tarefa, mil tarefas por dia dá 96 milhões de tokens de input por dia. Multiplique pelo preço da sua tabela e o número deixa de ser abstrato. Nada disso foi decidido no protótipo: ninguém separou o prefixo estático (system prompt, definição de tools, documentos fixos) pra aproveitar cache de prompt, ninguém truncou ou resumiu histórico, ninguém escolheu um modelo menor pra etapa de roteamento. Custo por tarefa é métrica de produto, e ela simplesmente não existe no código que a IA escreveu.

3. Avaliação: não existe teste pra saída não-determinística. O dev até tenta escrever o teste, faz um assertEquals na resposta do modelo, ele quebra na segunda execução porque veio um "Claro!" antes do JSON — e o teste é deletado. O sintoma da semana 3: alguém mexe em uma linha do prompt pra corrigir um caso específico, faz merge, e três fluxos que ninguém tocou passam a responder errado em silêncio. Não tem regressão porque nunca houve baseline. O que falta é chato e barato: um dataset de 30 a 50 casos reais rotulados, structured output pra travar o formato da saída, asserção determinística nos campos que importam e LLM-as-judge só no que é genuinamente subjetivo — rodando no CI a cada PR que toca prompt. Um eval desse tamanho leva minutos e custa centavos. Não ter é escolha, não é limitação técnica.

4. Debug: não há log de decisão. Quando o usuário reclama, você tem a resposta final e mais nada. Não tem o prompt exato que foi montado, nem quais tools o agente chamou, com quais argumentos, nem o que cada uma devolveu. O sintoma da semana 3: um bug que acontece 1 em 50 vezes, com temperatura acima de zero, e você não consegue nem reproduzir — porque o input real se perdeu. Tracing aqui não é luxo: um span por chamada de modelo e por chamada de tool, carregando prompt, argumentos, retorno, contagem de tokens e latência, tudo correlacionado por um id de trace que também aparece no log da aplicação. As convenções semânticas de GenAI do OpenTelemetry já padronizam esses atributos, e as ferramentas de tracing de LLM plugam em cima delas. Sem isso, "debugar" vira reler o código e adivinhar.

Repara no padrão: nenhum dos quatro é sobre o modelo ser bom ou ruim. É arquitetura. E é a mesma lista que sobe um degrau de exigência quando você deixa o agente escrever, executar e testar o próprio código — lá cada item deixa de ser "bom ter" e vira pré-requisito do primeiro deploy. Não é coincidência: essa lista do que falta é a ementa dos dois dias do AI Engineering Lab.

Como não cair na armadilha (sem voltar pra digitar tudo na mão)

A saída não é abandonar a IA. É mudar a sua relação com o que ela produz. Três hábitos resolvem a maior parte:

1. Leia o diff. Sempre. Soa óbvio, mas é exatamente o que vibe coding manda você ignorar. Antes de aceitar, lê. Se você não consegue explicar o que aquele bloco faz para outro dev, você não terminou.

2. Peça contexto, não só código. Um prompt melhor muda o jogo. Em vez de "faça funcionar", peça a decisão de arquitetura junto:

Implemente a autenticação por JWT neste endpoint.
Antes de escrever, me explique:
- onde o token vai ser validado e por quê
- quais erros de segurança comuns você está evitando aqui
- o que você está deliberadamente NÃO fazendo e o trade-off
Depois escreva o código e aponte as 3 linhas mais arriscadas.

A IA vira par de programação em vez de máquina de cuspir código. Você continua no comando do raciocínio.

3. Trate código de produção como código de produção. Teste, revisão, lint, scan de segurança. As mesmas travas de sempre. A IA escreveu mais rápido — ótimo, então sobra tempo pra revisar direito. Não para pular a revisão.

FAQ rápido

Vibe coding é a mesma coisa que usar Copilot, Cursor ou Claude Code? Não. A ferramenta é neutra. Vibe coding é aceitar o que ela gera sem entender. Usar Cursor lendo, testando e entendendo o resultado é engenharia com IA — continua sendo o seu trabalho.

Então vibe coding é sempre ruim? Não. Para protótipo, MVP e script descartável, é excelente — velocidade vale mais que rigor quando o código não vai durar. O erro é levar a mesma postura para produção.

O que falta pra transformar um protótipo vibe-codado em produto? Quatro coisas, nessa ordem: persistência de estado pensada, medição de custo por tarefa, um conjunto de evals pra saída não-determinística e tracing das decisões do agente. Sem esses quatro, o que você tem é uma demo com URL pública.

Por que meu código vibe-codado vaza segredo ou tem falha de segurança? Porque o modelo otimiza pra "funcionar", não pra "ser seguro". 45% do código gerado por IA traz vulnerabilidade do OWASP Top 10. Sem revisão e scan, a falha passa direto.

Como saber se eu cruzei a linha do vibe coding? Teste do Willison: você consegue explicar como o código funciona para outra pessoa? Se não consegue, você não programou — você vibe-codou. E aí o problema é seu quando quebrar.

O futuro não é menos IA. É mais arquitetura.

Vibe coding não é uma moda passageira nem o fim da profissão. É uma ferramenta nova com uma zona de uso clara: rápida e descartável de um lado, perigosa e cara do outro. Quem confunde os dois lados acumula a dívida técnica que já está vencendo ao longo de 2026.

O próximo salto do desenvolvedor não é programar mais rápido com IA. É saber arquitetar sistemas em que a IA é uma peça confiável — com contexto, avaliação, limites e responsabilidade técnica. É exatamente essa diferença entre "pedir código" e "projetar solução" que a gente coloca na mesa, com agents rodando de verdade, no Workshop Arquitetando Soluções de IA.

Porque no fim, a IA não substituiu a engenharia. Ela só deixou mais óbvio quem tem.