Estudo METR: por que IA deixou devs 19% mais lentos

A METR pegou 16 desenvolvedores que já trabalhavam havia anos nos próprios repositórios open source, cronometrou cada tarefa em segundos reais com e sem ferramenta de IA, e comparou o tempo medido com o que cada um achava que tinha gastado. O resultado que virou manchete foi “19% mais lento”. O que quase ninguém reproduziu foi o desenho do experimento que chegou nesse número, e é aí que a conclusão vira outra. Esse é o problema de todo estudo que vira meme: a manchete sobrevive, a metodologia morre no caminho. No caso do estudo METR sobre IA e programação mais lenta, a metodologia é praticamente a notícia inteira.

Esse post não é sobre “IA é boa ou ruim pra programar”. É sobre ler o paper com atenção antes de usar o número dele como arma em qualquer discussão.

O que a METR mediu de verdade: um experimento controlado, não uma pesquisa de opinião sobre produtividade

A primeira coisa que separa esse estudo de 99% do que circula por aí sobre produtividade com IA é o desenho: é um ensaio randomizado controlado, não survey, não autorrelato espontâneo, não extrapolação de telemetria de uso de ferramenta. A METR (Model Evaluation and Threat Research) pegou tarefas reais de issues abertas em repositórios open source de verdade, sorteou aleatoriamente se cada tarefa seria feita com ou sem assistência de IA (modelos de código do início de 2025, incluindo Claude 3.5/3.7 Sonnet, conforme descrito no próprio relatório), e cronometrou o tempo de execução em segundos, do início ao fim, sem depender de o desenvolvedor lembrar ou estimar depois.

Isso importa porque a maioria dos números que a galera cita sobre “produtividade com IA” vem de pesquisa de satisfação ou de relatório interno de empresa que vende a própria ferramenta. A METR fez o oposto: mediu comportamento, não opinião, e comparou com o que os próprios devs diziam sentir. Esse contraste entre tempo real e percepção gera o dado mais interessante do estudo, e eu volto nele mais adiante.

Quem são os devs do estudo: por que “experiente em repositório de 1 milhão de linhas” não é o seu dia a dia

Aqui mora o primeiro ponto cego de quem repete a manchete sem ler o paper. Os 16 participantes não são devs genéricos pegos de qualquer empresa. São mantenedores e contribuidores sêniores de projetos open source grandes e maduros, segundo a METR, com média de 22 mil estrelas no GitHub e mais de 1 milhão de linhas de código nos repositórios avaliados. Pensa no tipo de projeto que entra nessa faixa: algo do porte de um framework web consolidado, uma biblioteca numérica usada por meio mercado, um runtime com uma década de histórico de commits.

Cada participante já carregava na cabeça um modelo mental enorme do próprio código. Sabia onde cada função esquisita vivia, por que aquela decisão de arquitetura antiga continuava lá até hoje, quais módulos eram minados de dívida técnica silenciosa. É um tipo de conhecimento tácito que nenhum copiloto de IA acessa, porque não está escrito em lugar nenhum. Está na cabeça de quem viveu o projeto.

Compara isso com o cenário mais comum do mercado: um dev pleno chegando num microsserviço de seis meses de vida, ou alguém abrindo um projeto novo do zero num hackathon. Nesses casos a IA não compete com conhecimento tácito acumulado, compete com ignorância do contexto, e aí a vantagem muda de lado. O estudo não testou esse cenário. Testou o oposto: especialista máximo contra sistema legado máximo.

A tarefa escolhida e o motivo de ela favorecer o pior cenário pra IA

O segundo detalhe que a manchete engole é o tipo de tarefa. Não eram tarefas de “escreva uma função que valida CPF” ou “crie um CRUD novo”. Eram issues reais, do tipo que mantenedor de projeto grande recebe todo dia: bug em código legado, pouca ou nenhuma documentação, dependência de decisões arquiteturais antigas e, ponto que a METR registra no relatório, repositórios onde o uso prévio de ferramentas de IA generativa era baixo ou inexistente antes do experimento.

É o padrão comum de quem já abriu o Copilot ou o Cursor pra debugar código legado mal documentado: a IA sugere algo plausível, sintaticamente correto, que parece resolver o problema, e o dev gasta um tempo generoso revisando essa sugestão até perceber que ela ignora uma regra de negócio que só existe implicitamente em três arquivos diferentes. Esse tempo de revisão (ler, entender por que está errado, descartar, voltar ao raciocínio manual) é exatamente o custo que o cronômetro da METR capturou e que a percepção subjetiva do dev tende a não contabilizar direito.

A METR não testou “IA genérica fazendo programação genérica”. Testou IA numa combinação específica de fatores de alta dificuldade: legado, baixa documentação, repositório pouco acostumado com esse tipo de ferramenta. É um cenário real e relevante, mas é um cenário, não o universal.

O buraco de 43 pontos: 19% mais lento contra 24% de sensação de mais rápido

Esse é, pra mim, o dado mais valioso do paper inteiro, e o que menos aparece repetido nas redes. Os desenvolvedores, depois de completar as tarefas com IA, foram perguntados se achavam que tinham ficado mais rápidos ou mais lentos. A resposta média: acreditavam ter ganhado 24% de velocidade. O tempo cronometrado de fato: 19% mais lento. Um gap de 43 pontos percentuais entre sensação e realidade.

Isso reproduz um padrão psicológico bem documentado em ergonomia cognitiva e em estudos de autopercepção de desempenho, não é exclusivo de IA. A sensação de “terminei rápido” tende a vir da fluidez da interação (digitar menos, ver sugestão pronta, sentir que delegou esforço mental), não do tempo real gasto até fechar a tarefa. É o mesmo mecanismo por trás de quem acha que resolveu um problema rápido porque não sentiu o peso cognitivo de pensar sozinho, mesmo gastando mais minutos revisando e corrigindo o que a ferramenta entregou.

Pra quem trabalha com métricas de produtividade em time de desenvolvimento, isso devia acender um alerta grande: se você mede adoção de IA por pesquisa de satisfação do time, esse estudo é um aviso de que a régua subjetiva pode estar sistematicamente errada, em qualquer direção, pra cima ou pra baixo, dependendo do tipo de tarefa.

Onde a IA ganha tempo e o estudo nem tentou testar

É preciso ser honesto com o que o paper não cobriu, porque é fácil usar o “19%” pra generalizar além do que os dados permitem. A METR testou manutenção de código legado em projeto grande e maduro. Ela não testou prototipagem rápida de código novo sem dívida técnica acumulada, geração de código descartável (script de automação, scraper, utilitário de uso único), projetos pequenos ou médios onde não existe o peso de contexto tácito acumulado por anos, nem tarefas repetitivas e bem especificadas, tipo boilerplate de API ou configuração de infraestrutura.

O contraste entre usar IA pra escrever código novo do zero e usar IA pra navegar um sistema que você não escreveu é, na minha leitura, o eixo real que separa quando a ferramenta ajuda e quando atrapalha. Código novo tem menos restrições invisíveis, a IA não precisa adivinhar decisão arquitetural nenhuma, porque a decisão ainda não existe. Código legado é o oposto. Cada sugestão da IA carrega o risco de ignorar uma regra que nunca foi documentada.

O checklist que tiro do paper pra decidir quando vale confiar no copiloto

Lendo o desenho experimental, dá pra montar um critério prático, sem precisar acreditar em fé nem em pânico.

Legado com baixa documentação tende a reduzir o ganho de IA, porque a revisão da sugestão consome o tempo que a geração economizou. Projeto novo ou prototipagem tende a favorecer a IA, já que há menos contexto tácito pra ela violar. Repositório com uso histórico baixo de IA pesa contra, como mostrou o próprio estudo: o time ainda não calibrou prompt, convenção de código pra IA entender, nem fluxo de revisão. E a pergunta que eu faria antes de qualquer outra é se você está medindo por sensação ou por cronômetro. Depois desse paper, eu desconfiaria de qualquer relato de ganho de produtividade que não venha de medição objetiva de tempo de entrega.

Ferramentas como GitHub Copilot, Cursor ou Claude Code não são vilãs nem milagre. São instrumentos cujo resultado depende brutalmente do tipo de tarefa e do grau de familiaridade do time com elas. O erro não é usar a ferramenta. É escolher mal onde usar.

Fontes consultadas

• METR (Model Evaluation and Threat Research), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10/07/2025, link
• diginomica, Report – AI tools slow down experienced developers by 19%. A wake up call for industry hype?, 2025, link
• ActuIA, A METR Study Reveals that AI Slows Down Experienced Developers, 2025, link
• Let’s Data Science, AI Coding Tools Made Developers 19% Slower: METR Study, link
• arXiv (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089), 2025, link