Em fevereiro de 2025, Andrej Karpathy publicou um post no X que definiria o vocabulário da engenharia de software pelos meses seguintes. Ele descreveu um jeito novo de programar onde você "se entrega completamente às vibes, abraça as exponenciais e esquece que o código sequer existe". Chamou isso de vibe coding. O Collins English Dictionary elegeu o termo como palavra do ano em 2025.

Um ano depois, em fevereiro de 2026, a Bloomberg publicou uma matéria com um título que conta outra história: "AI Coding Agents Like Claude Code Are Fueling a Productivity Panic in Tech". Entre um termo e outro, algo mudou. Ou melhor, algo ficou visível.

Esse artigo tenta entender o que acontece no espaço entre gerar código com IA e manter software funcionando em produção. Spoiler: o espaço é maior do que parece.

O que a Bloomberg chamou de "productivity panic"

A reportagem da Bloomberg de 26 de fevereiro de 2026 descreve um fenômeno específico. Agentes de IA como Claude Code e OpenAI Codex não libertaram engenheiros para uma vida de lazer. Em vez disso, criaram o que a matéria chama de "productivity paranoia" entre executivos. A lógica é simples e brutal: se um agente de IA consegue produzir mais código que um humano em menos tempo, então ele deve fazer isso. O tempo todo.

Greg Brockman, presidente da OpenAI, disse que "parece uma oportunidade desperdiçada cada momento em que seus agentes não estão rodando". Essa frase sintetiza bem o clima. A promessa era que a IA faria o trabalho pesado enquanto engenheiros focavam em problemas interessantes. O que aconteceu na prática foi uma corrida para produzir mais, mais rápido, a qualquer custo.

O que me incomoda nessa narrativa é a premissa silenciosa: que engenharia de software se mede em volume de código produzido. Qualquer pessoa que já manteve um sistema em produção por mais de dois anos sabe que a parte difícil nunca foi escrever código. A parte difícil é fazer código funcionar junto, em produção, sob carga, por anos.

Vibe coding e o elefante na sala

O conceito de Karpathy tem uma honestidade que falta em boa parte do discurso sobre IA e programação. Ele não disse que vibe coding era engenharia de software. Disse que era um jeito de construir coisas usando linguagem natural, onde você aceita o código gerado pela IA sem revisar a estrutura interna e confia nos resultados para guiar mudanças.

Para protótipos, projetos pessoais e provas de conceito, isso funciona. O problema começa quando organizações tratam vibe coding como processo de engenharia. E é exatamente isso que está acontecendo.

Simon Willison, criador do Django, escreveu em março de 2025 que "nem toda programação assistida por IA é vibe coding". A distinção importa. Usar IA como autocomplete sofisticado enquanto você entende cada linha que entra no repositório é diferente de delegar a construção inteira para um agente e torcer para funcionar. O segundo caso é o que gera dívida técnica em escala industrial.

O estudo que ninguém queria ver

Em julho de 2025, a METR publicou um estudo controlado randomizado que deveria ter causado mais barulho do que causou. Eles recrutaram 16 desenvolvedores experientes de repositórios open source grandes (média de 22 mil stars, mais de 1 milhão de linhas de código). Cada desenvolvedor tinha em média 5 anos de experiência no projeto. Foram 246 tarefas reais, atribuídas aleatoriamente para serem feitas com ou sem ferramentas de IA.

O resultado: desenvolvedores levaram 19% mais tempo quando usaram IA. O intervalo de confiança ficou entre +2% e +39% mais lento.

Mas o dado que realmente me pega é outro. Antes do estudo, os desenvolvedores esperavam que a IA os acelerasse em 24%. Depois de completar as tarefas e constatar que foram mais lentos, eles ainda acreditavam que a IA os tinha acelerado em 20%. A percepção e a realidade se separaram completamente.

O estudo tem limitações claras: 16 desenvolvedores é uma amostra pequena, e os resultados se aplicam a desenvolvedores experientes em codebases familiares. Mas a desconexão entre percepção e realidade é difícil de ignorar. A METR tentou rodar uma segunda versão do estudo em 2026, mas encontrou um problema: muitos desenvolvedores se recusaram a participar porque não queriam trabalhar sem IA. O vício na sensação de produtividade já se instalou.

O código que a IA esquece de manter

A GitClear analisou 211 milhões de linhas de código alteradas entre 2020 e 2024. Os números contam uma história sobre o que acontece depois que o código é gerado.

Blocos de código com 5 ou mais linhas duplicadas aumentaram 8 vezes durante 2024. Linhas classificadas como "copy/paste" (clonadas) subiram de 8,3% para 12,3% entre 2021 e 2024. Código novo que precisou ser revisado nas duas semanas seguintes ao commit cresceu de 3,1% em 2020 para 5,7% em 2024.

E o número que diz mais sobre a saúde do código: a proporção de linhas associadas a refatoração caiu de 25% em 2021 para menos de 10% em 2024. Pela primeira vez, o volume de código copiado e colado superou o volume de código movido e reorganizado.

Isso parece abstrato até você parar para pensar no que significa na prática. Mais duplicação, menos refatoração. Mais código que faz a mesma coisa em lugares diferentes. Mais bugs que aparecem em um lugar e não no outro porque alguém copiou uma função em vez de extraí-la. É dívida técnica acumulando em velocidade que antes não era possível.

O InfoQ resumiu bem: código gerado por IA é "altamente funcional mas sistematicamente desprovido de julgamento arquitetural". A IA sabe escrever uma função que resolve o problema imediato. Ela não sabe que essa função já existe em outro módulo, que o padrão do projeto usa uma abstração diferente, ou que a equipe decidiu há seis meses migrar para uma abordagem nova.

Segurança: o custo invisível da velocidade

A Veracode testou mais de 100 modelos de linguagem em 80 tarefas de codificação com potencial para vulnerabilidades de segurança, cobrindo Java, JavaScript, Python e C#. Em 45% dos testes, os modelos introduziram falhas classificadas no OWASP Top 10.

Java foi a linguagem com pior resultado: 72% de taxa de falha em segurança. Os modelos falharam em proteger contra Cross-Site Scripting (CWE-80) em 86% das amostras relevantes e contra injeção de log (CWE-117) em 88% dos casos.

O dado mais preocupante do relatório da Veracode: enquanto os modelos ficaram melhores em escrever código sintaticamente correto e funcional ao longo do tempo, a maioria não ficou melhor em escrever código seguro. A curva de melhoria em funcionalidade não se traduziu em melhoria de segurança.

Um survey da Aikido Security de 2026, com 450 profissionais de segurança, estima que código gerado por IA já é a causa de uma em cada cinco brechas nas organizações pesquisadas. A Opsera coloca o número em 15-18% mais vulnerabilidades em código gerado por IA comparado com código escrito por humanos.

Essas não são estatísticas sobre cenários hipotéticos. São medições feitas em código que está rodando em produção, atendendo usuários reais.

O "messy middle" que ninguém vende

Entre a demo impressionante onde um agente de IA constrói uma aplicação inteira em 10 minutos e o software funcionando em produção sob carga real, existe um espaço enorme. É o que vou chamar de "messy middle".

Nesse espaço moram os code reviews que ninguém quer fazer em código que ninguém escreveu. Moram os testes de integração que o agente não criou. Mora a observabilidade que precisa ser configurada. Moram as decisões de arquitetura que nenhum modelo de linguagem vai tomar por você, porque ele não sabe que o time decidiu usar event sourcing, ou que o cliente exige compliance com SOC 2, ou que o datacenter em São Paulo tem latência diferente do us-east-1.

O que organizações estão descobrindo em 2026 é que a IA acelera uma parte do ciclo de desenvolvimento. Escrever o primeiro rascunho do código ficou mais rápido. Mas escrever o primeiro rascunho sempre foi a parte mais fácil. O que consome tempo e energia de verdade é tudo que vem depois: fazer funcionar com o sistema existente, cobrir edge cases, passar no code review, sobreviver ao primeiro pico de tráfego, ser mantido por alguém que não escreveu o código original.

O desenvolvedor em 2026 está virando o que alguém descreveu como "auditor forense". Em vez de escrever código do zero, gasta tempo verificando se o código gerado pela IA faz o que deveria, se não quebra o que já existe, se não abre uma porta de segurança. Não sei se isso é mais produtivo. Sei que é diferente.

Conclusão

Gerar código nunca foi o gargalo da engenharia de software. Se fosse, copiar e colar do Stack Overflow teria resolvido o problema há uma década. O gargalo sempre foi entender o problema, tomar decisões de design que sobrevivam ao tempo, e manter sistemas complexos funcionando de forma confiável.

A IA está redefinindo o trabalho de quem desenvolve software, mas não da forma que o marketing promete. Ela não eliminou a complexidade. Ela mudou onde a complexidade aparece. Em vez de gastar tempo escrevendo código, gastamos tempo verificando código. Em vez de dívida técnica acumulada ao longo de anos por decisões humanas, acumulamos dívida técnica em semanas por volume gerado.

O "productivity panic" da Bloomberg não é sobre IA ser boa ou ruim. É sobre uma indústria que mede produtividade pela métrica errada e está surpresa com os resultados. Linhas de código por hora nunca mediram qualidade de software. Agora que temos ferramentas que maximizam essa métrica, os efeitos colaterais ficaram impossíveis de ignorar.

Não tenho uma resposta limpa para isso. O que sei é que as organizações que vão se dar melhor em 2026 são as que tratam código gerado por IA como primeiro rascunho, não como entrega final. As que investem em code review, testes automatizados e observabilidade com a mesma intensidade que investem em ferramentas de geração. As que entendem que velocidade de escrita e velocidade de entrega são coisas diferentes.

O vibe coding de Karpathy é divertido para projetos de fim de semana. Para software em produção, a vibe é outra.

Referências pesquisadas nesta publicação