Devs viciados em IA: produtividade real ou ilusão cara?
Em 2026, tirar as ferramentas de IA das mãos dos desenvolvedores é praticamente impossível. A galera se apegou de um jeito que não larga. Mas, enquanto a IA realmente acelera a produção de código, a grande questão é: ela está entregando um código melhor? Parece que não. E isso pode virar um problemão no futuro.
Em fevereiro de 2026, o pessoal do METR, um laboratório de pesquisa em IA super respeitado, soltou uma bomba: a maioria dos desenvolvedores simplesmente não topa mais trabalhar sem IA, mesmo que seja para tarefas simples. Eles queriam atualizar uma pesquisa anterior, de 2025, que falava sobre a produtividade da IA na programação. Naquela época, os devs disseram que a IA os deixava mais produtivos, mas a surpresa veio quando descobriram que, na verdade, ela os atrasava.
Sim, o código saía mais rápido, mas aí vinha a parte chata: gastar um tempão corrigindo erros, ‘guiando’ a IA e esperando ela terminar as coisas. Quando o METR tentou refazer o experimento para ver os avanços da IA, não conseguiu. Os devs não quiseram participar, porque, pasmem, não queriam trabalhar sem IA, nem que fosse só para o estudo!
Então, o METR fez uma pesquisa em maio, onde os profissionais podiam contar como a IA impactava a produtividade deles. E, claro, a percepção geral era que a IA os tornava duas vezes mais valiosos. Mas, olha, com as notícias recentes sobre o custo absurdo do ‘tokenmaxxing’ e outras pesquisas pipocando, essa autopercepção começa a ficar meio duvidosa.
O ‘tokenmaxxing’, que é basicamente usar o número de tokens como métrica de produtividade com IA, virou febre em 2026. Mas parece que a moda já está passando. A Amazon, por exemplo, fechou seu ranking interno de tokens, o Kirorank, porque a galera estava usando IA demais, só para subir no ranking, e os custos foram lá pra cima. Isso mostra que usar IA não significa automaticamente mais produtividade.
A Uber, por sua vez, torrou todo o orçamento de IA de 2026 nos primeiros quatro meses do ano. O COO, Andrew Macdonald, comentou em um podcast que todo esse gasto não trouxe um aumento visível em projetos ou produtividade. E tem mais: código gerado por IA nem sempre diminui a manutenção, e pode até aumentar. O programador James Shore, que é fera no assunto, disse em um post que viralizou:
“Você escreve código duas vezes mais rápido agora? É bom torcer para ter diminuído pela metade seus custos de manutenção. Caso contrário, você está ferrado. Está trocando um aumento temporário de velocidade por uma escravidão permanente.”
Outras evidências reforçam isso. Um tweet viral da Aiswarya Sankar, CEO da Entelligence AI, revelou que empresas gastam 44% dos tokens para corrigir bugs que a própria IA gerou. E a CodeRabbit, empresa de ferramentas de revisão de código, analisou ‘pull requests’ de código aberto e descobriu que a IA produziu 1.7x mais problemas do que o código feito por humanos.
Ok, a gente sabe que esses números vêm de empresas que vendem soluções para revisar código. Mas pesquisadores independentes também estão encontrando problemas parecidos. A Singapore Management University, por exemplo, alertou que “código gerado por IA pode introduzir custos de manutenção de longo prazo em projetos de software reais”.
Então, se os programadores amam suas IAs, qual a saída? O pessoal que vende ferramentas de IA diz que é só usar mais IA para corrigir os problemas que a própria IA criou. O Scott Wu, da Cognition (que faz o Devin, um agente de IA para codificação), sugere isso. Mas até ele admite que, por mais que o Devin trabalhe sozinho, a habilidade dele está entre um programador júnior e um de nível médio, dependendo da tarefa. Ou seja, não é para largar de mão e esquecer.
Os pesquisadores da SMU sugerem uma abordagem mais humana: os programadores precisam saber exatamente o que a IA faz bem e o que não faz, tão bem quanto conhecem suas linguagens de programação favoritas. É preciso ter sistemas de controle de qualidade robustos, feitos para IA, e revisar o trabalho da IA com o mesmo cuidado que se revisaria o trabalho de um dev júnior. E, no fim das contas, a parte de arquitetura de software e segurança, que exige uma visão mais ampla, continua sendo coisa para humanos.
