Pergunte a quem usa agente de IA para programar se ficou mais rápido, e a resposta quase sempre é sim. Um estudo recente cronometrou isso de verdade, e a resposta certa foi não.
O estudo que furou o balão
O METR, organização independente que mede capacidade e impacto real de sistemas de IA, rodou entre fevereiro e junho de 2025 um experimento controlado e randomizado com 16 desenvolvedores experientes, cada um com anos de histórico nos próprios repositórios open source que já mantinha. A metodologia era simples de entender e difícil de discutir: cada uma das 246 tarefas reais foi sorteada para ser feita com IA liberada (os devs usaram Cursor Pro e Claude 3.5 ou 3.7 Sonnet) ou com IA proibida, e o tempo de cada tarefa foi cronometrado.
O resultado foi o oposto do esperado por todo mundo envolvido: economistas apostavam numa aceleração de 39%, pesquisadores de IA apostavam em 38%, os próprios devs apostavam em 24%. Na prática, quem usou IA levou 19% mais tempo para terminar a mesma tarefa.
A parte que importa mais não é o 19%, é o que veio depois. Mesmo tendo acabado de viver a lentidão, cronometrada e registrada, os desenvolvedores continuaram achando, depois do experimento, que a IA os tinha deixado cerca de 20% mais rápidos. A sensação de velocidade sobreviveu ao próprio dado que a contradizia.
Por que isso importa: se nem quem está debruçado no código consegue sentir a própria lentidão, "parece que ficou mais rápido" não é um critério. É preciso medir, porque a sensação mente de um jeito consistente e na mesma direção.
Isso é regra ou exceção?
O relatório anual de 2025 da DORA, equipe de pesquisa do Google Cloud que há mais de dez anos mede o que separa organização de engenharia de alta performance do resto, foi o primeiro a tratar isso como pergunta central: a IA ajuda, atrapalha, ou depende? A pesquisa cruza nível de adoção de IA com indicadores reais de entrega (throughput e estabilidade) em milhares de profissionais de tecnologia, segmentados em sete perfis de equipe.
A resposta que a DORA chegou é que a IA funciona como amplificador, não como correção. Equipes que já tinham prática de entrega madura, os perfis que o relatório chama de "pragmatic performers" e "harmonious high-achievers", aumentaram throughput sem piorar estabilidade. Para a maioria dos outros perfis, a IA amplificou o problema que já existia antes dela chegar, piorando instabilidade em vez de compensar a falta de prática.
O estudo do METR mostrou o sintoma num grupo pequeno e controlado. A DORA mostra a mesma coisa na escala de uma indústria inteira: o resultado da IA não é uma propriedade da ferramenta, é uma propriedade de quem já estava construindo antes dela existir.
O que realmente separa quem ganha de quem perde
Isso deixa uma pergunta prática: separa o quê, exatamente? A própria Anthropic, fabricante do Claude, publica no guia oficial de boas práticas para o Claude Code uma resposta direta, baseada no que funciona nas equipes internas e em quem usa a ferramenta todos os dias. O ponto central do documento não é sobre prompt nem sobre modelo. É sobre verificação.
A tese é esta: o agente para de trabalhar quando o resultado parece pronto, e sem uma checagem que ele mesmo possa rodar, "parece pronto" é o único sinal que existe. Teste que passa ou falha, build que quebra ou não, captura de tela comparada com o design: qualquer coisa que devolva uma resposta binária fecha o ciclo. Sem isso, cada erro espera alguém notar, e quem nota é a mesma pessoa que devia estar economizando tempo.
Essa é a peça que faltava nos dois estudos anteriores. No experimento do METR, boa parte da lentidão vinha do próprio tempo gasto revisando e corrigindo o que a IA produzia, porque os desenvolvedores aceitaram menos de 44% do código gerado como está. No relatório da DORA, os perfis que ganharam com IA são justamente os que já tinham prática de entrega madura, ou seja, já tinham o próprio ciclo de verificação rodando antes da IA chegar. A ferramenta não criou essa disciplina, só multiplicou o que já existia.
O que muda em como a Mutagex constrói
Na prática isso vira regra, não princípio bonito. Nenhuma tarefa entra em produção sem um jeito de confirmar que o resultado é o esperado: teste que roda, checagem automática no pipeline, ou alguém lendo o diff de ponta a ponta antes do merge. O agente escreve rápido. A pergunta que decide se isso virou produtividade de verdade é quem confere, e onde isso acontece.
Sem essa checagem, a sensação de ter ido mais rápido com IA é real, só que é exatamente isso: uma sensação. Os três estudos deste texto medem a mesma coisa de três ângulos diferentes, e os três chegam na mesma linha.