Reavaliação do experimento da METR: em tarefas complexas e revisões, desenvolvedores com IA perdem 24% das horas

Em 2025, o centro de pesquisa independente METR mediu o trabalho de 16 desenvolvedores experientes de código aberto em 246 tarefas reais extraídas de seus próprios repositórios: com assistentes de IA, o tíquete típico era concluído 19% mais lentamente do que manualmente. O pesquisador independente Solomon Shalom Lijo, no artigo "Counting the Bandages: On measuring the time that AI saves" (publicado no arXiv em 23 de outubro de 2026), recalculou, a partir dos registros públicos da METR, o gasto total de horas da equipe. Considerando os atrasos prolongados em tarefas complexas, os desenvolvedores que usaram IA perderam, na verdade, 24% do tempo de trabalho (e, sem o ajuste para o tamanho inicial das tarefas, esse número sobe para 34%), sendo que a correção das observações feitas na revisão de código levava em média 14,9 minutos por tíquete, contra 9,7 minutos sem a rede neural.

A seguir, o autor analisou o benchmark GDPval da OpenAI e, em 540 sessões do Claude Code, mostrou por que parar o cronômetro no momento da entrega do rascunho não faz sentido: os minutos economizados na geração se transformam em bugs não detectados e horas de retrabalho.

De onde vieram os números 19%, 24% e 34% dos mesmos registros

Lijo reproduziu os cálculos a partir do repositório público da METR e mostrou que as mesmas 246 tarefas concluídas geram três números diferentes, dependendo de como se calcula o tempo da equipe:

• Mais 19% de tempo é o resultado da média geométrica dos logaritmos, número que os autores da METR destacaram em seu título. Ele reflete o desvio típico em uma única tarefa isolada.
• Mais 24% de tempo surge ao se dividir todas as horas realmente gastas com IA pelas horas gastas sem IA. Com a rede neural, a dispersão do tempo é visivelmente mais ampla: quando um programador fica travado em iterações frustradas de prompting em um tíquete grande, essas "caudas" de várias horas consomem o fundo total de tempo de forma muito mais severa do que a média logarítmica sugere.
• Mais 34% de tempo aparece nas horas brutas, sem correção para o viés inicial da amostra. No sorteio, o grupo que usou IA recebeu, por acaso, tíquetes maiores: antes de começar o trabalho, os próprios programadores estimavam esses tíquetes em 116 minutos em média, contra 106 minutos no grupo de controle.
• As correções pós-revisão de código foram medidas em 230 das 246 tarefas: ajustar o código devolvido pelo revisor levava 14,9 minutos com IA, contra 9,7 minutos manualmente. Ainda assim, os limites estatísticos de Makarov aplicados aos mesmos dados deixam um corredor amplo: a IA de fato acelerou o trabalho em algo entre 2,6% e 82,1% das tarefas individuais. Um único número médio esconde em quais tíquetes a ferramenta economiza horas e em quais ela afunda o resultado.

Por que a aceleração de 100 vezes do GPT-5 encolhe para 1,1–3,6 vezes

O engenheiro Frank Gilbreth, há cem anos, tentou se barbear com duas navalhas ao mesmo tempo: economizou 44 segundos diante do espelho, mas gastou dois minutos colando curativos nos cortes. Benchmarks modernos de IA repetem o mesmo erro quando excluem a verificação do resultado da medição.

Um exemplo claro é o teste prático GDPval, da OpenAI. No anúncio, a empresa afirmou que os modelos de ponta resolvem tarefas de especialistas de diversos setores cerca de 100 vezes mais rápido e mais barato: o GPT-5 gera uma resposta em 4,5 minutos, contra 404 minutos de trabalho manual de um especialista. Mas, dentro do próprio artigo científico do GDPval, há um fluxo de trabalho com aceitação obrigatória de cada resposta:

• a leitura e verificação de um rascunho por um especialista humano levam 109 minutos (27% do tempo total de trabalho manual);
• pela lei de Amdahl, mesmo com um modelo sem erros, a aceleração de todo o processo tem um teto de `404 / (4,5 + 109) = 3,56x`, ou seja, no máximo 3,6 vezes;
• as respostas do GPT-5 superaram as dos especialistas em apenas 39% das tarefas, então, considerando o retrabalho dos rascunhos fracos, os próprios autores do artigo GDPval estimam a aceleração real em apenas 1,12–1,39 vez.

A mesma bifurcação aparece em um experimento de campo com consultores de negócios (Dell'Acqua et al., 2026), em tarefas fora da zona de confiabilidade do modelo. Com o GPT-4, os participantes entregavam a solução em 26,2 minutos, em vez dos 37,7 minutos do grupo de controle, mas a proporção de respostas corretas caía de 84,5% para 60,0%. Pela fórmula do limiar de equilíbrio de defeitos que Lijo introduz, os 11,5 minutos economizados só compensam se detectar e corrigir um erro que chegou ao cliente custar menos de 47 minutos de trabalho do consultor.

Experimento com 540 sessões do

Claude Code: como a confiança excessiva desativa a verificação

Para medir, na prática, como a reputação do autor de um rascunho influencia a profundidade da revisão, Lijo conduziu uma série de testes controlados com agentes de IA. A base foram relatórios financeiros trimestrais de empresas americanas no formato 10-Q, extraídos do banco de dados da Comissão de Valores Mobiliários dos EUA (SEC), referentes ao período até 30 de junho de 2026. Os relatórios foram publicados após 1º de julho de 2026 — depois da data de corte do treinamento dos modelos —, portanto a rede neural não poderia "lembrar" os números a partir de seus pesos.

O agente autor (`claude-haiku-5-5`) montava um resumo com 9 indicadores (receita, lucro líquido e margem operacional de três empresas), no qual, em 30% dos casos, um erro era deliberadamente inserido: uma linha de outra empresa, um trimestre antigo ou números trocados de posição. Em seguida, o documento era verificado por um agente revisor (`claude-sonnet-5-5`, em uma sessão isolada do Claude Code), que tinha uma ferramenta para conferência linha a linha com a fonte original da SEC. Pelas condições do prompt, verificar um número custava 3 minutos (as 9 linhas inteiras, 27 minutos), enquanto um erro que passasse despercebido até o cliente era penalizado em 10 horas (600 minutos).

A conferência completa só se justificava economicamente quando a taxa de erro superava 4,5%.

O experimento revelou três efeitos concretos:

• Modo "tudo ou nada". Quando se informava honestamente ao revisor uma taxa de erro alta (entre 10% e 30%), em todos os 40 testes pareados ele conferia as 9 linhas e corrigia 100% dos erros. Mas não havia uma verificação amostral gradual: perto do limiar de 4,5%, o modelo alternava abruptamente entre a conferência completa e nenhuma consulta à fonte.
• Cegueira causada pela subestimação da taxa de erro. Nos mesmos rascunhos, com 30% de erros reais, o revisor foi informado no prompt de que o autor errava dez vezes menos (apenas 3% dos casos). Em 29 das 40 sessões, o `Sonnet 5.5` nem chegou a abrir o relatório original, verificando em média apenas 2 dos 9 números. Economizou-se 21 minutos na revisão, mas o número falso acabou chegando ao relatório do cliente em 22,5% dos resumos, em vez de zero — uma perda líquida de 135 minutos por documento.
• Inutilidade das ressalvas no prompt. Em um ramo separado do teste, adicionou-se à cifra "3% de erros" uma instrução explícita para tratar essa estimativa como não verificada. Em 26 das 40 execuções, o modelo concordava, em seu raciocínio, que não deveria confiar no número — e, mesmo assim, entregava o resumo sem fazer nenhuma conferência. A âncora numérica pesou mais do que o alerta em texto.

Como medir o benefício da IA em uma equipe sem se autoenganar

Em vez de um único cronômetro "até o primeiro commit", o autor propõe acompanhar três indicadores ao adotar ferramentas de IA (o código e os registros brutos estão abertos no GitHub, no repositório `tsb-bench`, e também no Zenodo):

1. Quantas horas, no total, a equipe gasta na tarefa como um todo, incluindo a revisão de código e o retrabalho de pull requests devolvidos. 2. Quantos erros extras passam para o resultado final — com base em uma aceitação "cega" comparando os grupos com e sem IA. 3. A que preço de bug a aceleração deixa de valer a pena, e quando é possível desativar o controle manual: para remover a revisão obrigatória com 95% de confiança, aceitando uma taxa de erro de 0,85%, a ferramenta precisa primeiro entregar 352 tarefas verificadas consecutivas, sem nenhuma falha.