Quando a Medição de IA Falha: O Problema de Dependência do Estudo METR

Em janeiro, escrevi sobre o estudo do METR que mostrou desenvolvedores 19% mais lentos com IA, apesar de se sentirem 20% mais rápidos. O achado era provocativo. Também era, como o próprio METR agora reconhece, frágil.

Em fevereiro de 2026, o METR publicou os resultados de uma tentativa de redesenho do experimento. A intenção era corrigir as limitações do estudo original: amostra pequena, tarefas limitadas a repositórios open-source maduros, perfil estreito de participantes.

O que aconteceu foi mais interessante que qualquer resultado numérico. O redesenho expôs um problema que nenhuma estatística resolve: a dependência de IA já alterou o comportamento dos desenvolvedores que deveriam ser medidos.

Os Números (e Seus Limites)

O METR reconvocou 10 dos 16 desenvolvedores originais. Resultado: -18% de velocidade com IA, com intervalo de confiança entre -38% e +9%. Seis participantes do estudo anterior não voltaram.

Recrutaram também 47 novos desenvolvedores. Resultado: -4%, com intervalo entre -15% e +9%. Menos negativo. Também menos conclusivo.

Nenhum dos dois resultados é estatisticamente significativo. Os intervalos de confiança cruzam zero. Se alguém usar esses números para provar que IA desacelera ou acelera, está abusando da estatística.

Mas os números são a parte menos reveladora do estudo.

O Viés que Quebra o Experimento

Entre 30% e 50% dos desenvolvedores contatados para participar admitiram que evitariam enviar tarefas onde IA mais os ajudaria. O raciocínio é simples: se a tarefa pode cair no grupo de controle (sem IA), preferem não arriscar.

Releia. Metade dos candidatos filtraria suas tarefas para evitar ficar sem IA nas situações em que mais dependem dela.

Isso não é viés de seleção comum. É um sinal de que o grupo experimental e o grupo de controle já não representam a mesma atividade. Desenvolvedores que usam IA intensamente desenvolvem fluxos de trabalho diferentes. Pedem para trabalhar sem IA e a resposta não é desconforto. É recusa.

Um dos participantes disse: “I’m torn. I’d like to help provide updated data but also I really like using AI!” Outro: “My head’s going to explode if I try to do too much the old fashioned way.”

Essas não são frases de quem usa uma ferramenta opcional. São frases de quem incorporou a ferramenta no processo cognitivo.

O Problema do Pagamento

O estudo original pagava US$ 150 por hora. O redesenho reduziu para US$ 50. A justificativa era ampliar a base de participantes. O efeito foi o oposto.

Desenvolvedores seniores com experiência significativa em repositórios open-source maduros (o perfil necessário para o estudo) ganham bem acima de US$ 50/hora no mercado. A redução de pagamento afastou exatamente os participantes que tornavam o estudo original relevante: profissionais experientes trabalhando em código que conhecem profundamente.

O que resta é uma amostra enviesada na direção de quem aceita ganhar menos, o que correlaciona com menos experiência ou menos demanda no mercado. O estudo mede um subconjunto, e não sabemos se esse subconjunto representa alguma coisa além de si mesmo.

A Medição do Tempo Não Funciona Mais

Existe uma limitação técnica que o METR identifica e que poucos estudos abordam: ferramentas agênticas quebram a métrica de tempo.

Quando um desenvolvedor usa Copilot ou autocompletação, o fluxo é síncrono. Ele digita, a ferramenta sugere, ele aceita ou rejeita. O tempo gasto na tarefa é mensurável.

Quando um desenvolvedor usa Claude Code ou ferramentas similares, o fluxo muda. Ele delega uma subtarefa ao agente e faz outra coisa enquanto espera. Revisa e-mail. Responde mensagens. Pesquisa um problema diferente. Quando o agente termina, ele revisa o resultado e continua.

Como medir o tempo dessa tarefa? O relógio de parede inclui tempo em que o desenvolvedor fazia outra coisa. O tempo de teclado exclui o tempo em que o agente trabalhava sozinho. Nenhuma métrica simples captura o que realmente aconteceu.

O METR nota que aproximadamente 4% dos commits no GitHub já vêm do Claude Code. Se parte significativa da produção é assíncrona, qualquer estudo que mede “tempo até conclusão” de forma síncrona está medindo a coisa errada.

O Que Isso Significa Para Quem Decide

O estudo do METR não prova que IA desacelera desenvolvedores. O estudo anterior também não provava, apesar de ter sido usado dessa forma por dezenas de artigos e apresentações (incluindo um post meu). O que a sequência dos dois estudos demonstra é algo diferente e mais importante.

Primeiro: medir produtividade com IA está ficando impossível com métodos tradicionais. Randomized controlled trials exigem que os dois grupos façam a mesma atividade em condições comparáveis. Quando um grupo não consegue funcionar sem a ferramenta, a comparação perde sentido.

Segundo: a velocidade de adoção cria fatos consumados. Enquanto pesquisadores tentam montar experimentos controlados, o mercado já decidiu. Desenvolvedores integram IA nos seus fluxos. Empresas compram licenças. Processos mudam. A pergunta “IA torna desenvolvedores mais produtivos?” está sendo respondida não por estudos, mas por comportamento revelado.

Terceiro: a pergunta certa talvez não seja “mais rápido ou mais lento?” mas “para quais tarefas, com qual nível de governança, medido como?” Velocidade bruta de conclusão de tarefas individuais ignora qualidade do código, dívida técnica, carga de revisão e custo de manutenção. Otimizar para velocidade sem medir esses fatores é otimizar para retrabalho.

O Paradoxo da Irreversibilidade

Há algo na situação do METR que merece atenção de quem lidera equipes de engenharia.

Se a dependência de IA já é forte o suficiente para impedir a condução de estudos controlados, isso significa que decisões sobre produtividade com IA estão sendo tomadas sem evidência confiável. As organizações adotam primeiro e medem depois (se medem).

Isso não é necessariamente ruim. Empresas tomam decisões com informação incompleta o tempo todo. O risco está em confundir falta de evidência negativa com evidência de benefício. “Não conseguimos provar que IA desacelera” não é o mesmo que “IA acelera.”

Para líderes de engenharia, a implicação prática é clara. Não espere por estudos acadêmicos para decidir. Construa sua própria infraestrutura de medição. Meça tempo de ciclo, taxa de defeitos, carga de revisão e frequência de deploy no seu contexto, com suas equipes, nos seus repositórios. Compare períodos e tipos de tarefa. Os dados que importam são os seus, não os de um estudo com 10 participantes.

E se seus desenvolvedores não conseguem trabalhar sem IA, essa é uma informação relevante por si só. Não sobre produtividade. Sobre resiliência.

---

Este artigo é um follow-up de Medindo IA no Desenvolvimento de Software: O Que os Dados Realmente Mostram, publicado em janeiro de 2026. Fonte: METR Blog - Redesigned AI Productivity Study.

Para discutir como sua organização pode construir medição de produtividade com IA que funcione, entre em contato: contato@victorino.com.br | www.victorino.com.br