Vibe coding não é engenharia: a diferença entre velocidade e dívida

Deixar a IA escrever código é maravilhoso — até você ter que mantê-lo. O que separa aceleração de dívida não é a IA. É o processo.

Eu repito isso para todo time com quem converso. E cada vez mais os números chegam para confirmar.

O termo “vibe coding” nasceu em fevereiro de 2025, num post do Andrej Karpathy, um dos fundadores da OpenAI e ex-diretor de IA da Tesla. A definição dele: “existe um novo tipo de programação que eu chamo de vibe coding, onde você se entrega totalmente às vibes, abraça as exponenciais e esquece que o código existe”. Ele mesmo descreveu o fluxo: “aceito tudo”, “não leio mais os diffs”. Mas repara no que o próprio Karpathy escreveu logo em seguida: “não é tão ruim para projetos descartáveis de fim de semana”. Esse era o escopo. Projeto de fim de semana. O resto do mundo ouviu só a primeira parte.

Do outro lado do debate, a comunidade reagiu do jeito dela. No Reddit, o embate virou frase de efeito: “as IAs vão te superar muitas vezes… acabou. Não serão vocês escrevendo o código”. E o Uncle Bob, Robert C. Martin, autor do Código Limpo, respondeu com o que ele de fato faz hoje: “eu não reviso código escrito por agentes. Eu meço coisas como cobertura de teste, estrutura de dependências, complexidade ciclomática, tamanho dos módulos, mutation testing. O código em si eu deixo para a IA.” Percebe? Ele não disse “pare de usar IA”. Ele disse: mude o processo de qualidade. Métricas e testes no lugar da leitura linha a linha.

E o debate saiu da internet quando bateu no caixa das empresas.

A Amazon passou por dois apagões sérios em março de 2026. No dia 2, cerca de 120 mil pedidos perdidos e 1,6 milhão de erros no site, com o assistente de IA Q apontado como um dos principais contribuintes. No dia 5, uma queda de 99% dos pedidos na América do Norte: 6,3 milhões de pedidos perdidos. A resposta foi um “code safety reset” de 90 dias: em cerca de 335 sistemas críticos, ninguém muda código sem a revisão de duas pessoas antes. Eles chamaram de “fricção controlada”. A frase que ficou comigo veio do relato interno: “quando essa avalanche de código novo encontra os processos tradicionais de revisão, problemas aparecem”.

Repara num detalhe que quase ninguém comentou: o porta-voz da Amazon disse que só um dos incidentes tinha relação com IA, e nenhum envolvia código 100% escrito por IA. O reset não foi contra a IA. Foi contra a falta de processo. É exatamente o meu ponto.

Agora olha o outro lado. A Stripe integra mais de 1.300 pull requests por semana produzidos 100% por agentes de código — todos revisados por humanos antes de entrar. A própria Stripe escreveu: “fazer vibe coding de um protótipo do zero é fundamentalmente diferente de contribuir código para o codebase da Stripe”. Mesma IA. Processo diferente. Resultado diferente.

O Wes McKinney, criador do pandas, resumiu a defesa final numa frase: “quando o código é grátis, dizer não é a nossa última defesa”. E completou: “cada feature nova é barata de criar, mas cara de manter. Cada uma adiciona superfícies para bugs, confusão e futuros erros de agentes.”

Porque é disso que estamos falando. Dívida.

Um estudo de pesquisadores da Carnegie Mellon testou agentes de código em 200 tarefas reais de repositórios open source. O melhor resultado: 61% das soluções funcionalmente corretas. Só 10,5% seguras. Ou seja: de cada cinco soluções que funcionam, quatro têm falha de segurança. A IA é ótima em fazer funcionar. Péssima em aguentar o tranco.

E a dívida acumula rápido. A GitClear analisou 623 milhões de mudanças de código entre 2023 e 2026: a duplicação de blocos subiu 81%, e a refatoração — o trabalho de manter o código limpo — despencou de 21% para 3,8% do volume de mudanças. O fechamento do relatório é a melhor definição de dívida técnica que eu li: “o maior risco não é a IA escrever código que o seu time não consegue manter. É ela escrever esse código mais rápido do que nunca — e a conta chegar quando você menos pode pagar.”

Velocidade sem processo não é agilidade. É dívida que ainda não venceu.

Agilidade, a de verdade, é o processo de revisão, teste e responsabilidade. É o ciclo curto. É a definição de pronto antes de começar. É a revisão obrigatória antes de subir. É alguém responder pelo que entrou. Isso nunca foi burocracia. É o que separa quem voa de quem cai.

O Simon Willison colocou a fronteira com precisão: “se um LLM escreveu cada linha do seu código, mas você revisou, testou e entendeu tudo, isso não é vibe coding no meu livro. É usar um LLM como assistente de digitação.”

A IA acelera. O processo ágil doma. A Amazon aprendeu isso do jeito caro. A Stripe transformou em vantagem competitiva. A diferença entre as duas histórias não é a IA. É o processo.

Então a pergunta que eu deixo: no seu time, o que precisa existir antes de um código gerado por IA entrar em produção? Qual é a sua definição de pronto?

Esse é o terceiro texto da série Agilidade com Dados. Se você chegou agora, comece pelo primeiro: A fábrica invisível.

Me conta nos comentários. Eu leio e respondo.