"Devs com IA são 19% mais lentos": os autores publicaram uma ressalva — e o nicho não leu

Foto: RDNE Stock project via Pexels

Em fevereiro de 2026, a METR — o laboratório de pesquisa por trás do estudo mais citado deste nicho, o do "devs com IA são 19% mais lentos" — publicou um segundo experimento. Cinquenta e sete desenvolvedores, cento e quarenta e três repositórios, mais de oitocentas tarefas. E, por baixo desses números, um detalhe que corrói todos eles: entre 30% e 50% dos devs disseram que estavam deixando de submeter tarefas ao experimento — porque não queriam fazer aquilo sem IA.

Isso foi publicado em 24 de fevereiro de 2026. Pelos mesmos autores do estudo que você viu citado na última thread que leu.

Você conhece o número deles. "Devs experientes com IA são 19% mais lentos." Ele virou o argumento de encerramento de qualquer discussão sobre produtividade com agente de código. É o link que alguém cola quando quer ganhar a conversa.

E aqui está a parte incômoda: o número continua de pé, e mesmo assim quem o repete hoje está desatualizado. Não porque a METR se retratou — ela não se retratou. Mas porque ela publicou depois uma coisa que quase ninguém abriu.

Este artigo não é sobre a IA ser boa ou ruim. É sobre como este nicho cita ciência.

O que a METR publicou em fevereiro de 2026

Comece pelo título do post, que já entrega o tom: "We are Changing our Developer Productivity Experiment Design". Não é uma nota triunfal. É uma equipe dizendo que o instrumento de medição tem um problema. (O post está aberto e de graça, no blog da própria METR, sob o endereço metr.org/blog/2026-02-24-uplift-update. Leia depois deste texto — ou antes, se preferir.)

O estudo original usou dados de fevereiro a junho de 2025 e encontrou, nas palavras deles, que "the use of AI causes tasks to take 19% longer, with a confidence interval between +2% and +39%". (Curiosidade que diz muito: o próprio texto novo da METR resume o estudo antigo como um "20% slowdown". Até os autores arredondam o próprio número.)

Depois veio um estudo posterior, com dados do fim de 2025: 57 devs, 143 repos, 800+ tarefas. Dez deles eram participantes do estudo original; os outros 47 foram recrutados novos, de repositórios mais diversos — menores, mais greenfield, menos maduros.

E o que eles acharam? A resposta honesta é: não o suficiente para você colar num tweet.

A frase que interessa

Esta é a sentença central do post, e ela merece leitura devagar:

"Based on conversations with study participants, we believe it is likely that developers are more sped up from AI tools now — in early 2026 — compared to our estimates from early 2025. However, because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase."

Repare na engenharia dessa frase. A crença de que melhorou vem de conversas com participantes. E a evidência de dados é classificada, pelos próprios autores, como "only very weak evidence".

Ou seja: a METR não está anunciando vitória da IA. Ela está dizendo que o experimento dela não consegue mais medir direito a coisa que se propôs a medir. É uma admissão metodológica, não uma manchete.

O mecanismo: o viés de seleção

Aqui está o problema, e ele é bonito de tão simples.

O experimento precisa que o dev faça algumas tarefas sem IA, para servir de comparação. Só que, em 2026, o dev não quer mais fazer tarefa sem IA. Então ele simplesmente não submete aquela tarefa ao estudo.

"30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI."

Pare e pense no que isso faz com a amostra. Quais tarefas um dev mais recusa fazer sem IA? Justamente aquelas em que a IA ajudaria mais. A METR escreve exatamente isso:

"This implies we are systematically missing tasks which have high expected uplift from AI."

E conclui:

"Together, these effects make it likely that our estimate reported above is a lower-bound on the true productivity effects of AI on these developers."

Um piso, não um teto. É uma diferença que muda o sentido inteiro da citação.

E então vem a frase que o nicho deveria conhecer tão bem quanto conhece os 19%:

"However the true speedup could be much higher among the developers and tasks which are selected out of the experiment."

A parte em que eu travei — e por que ela é o artigo inteiro

Aqui eu preciso ser honesto com você, porque o contrário seria cômico num texto com esta tese.

Vou colocar dois números aqui do jeito exato como a fonte os escreve, e vou deixá-los sem interpretação de propósito. O parágrafo seguinte explica por quê.

A METR reporta, para o subgrupo dos devs originais, "a speedup of -18% with a confidence interval between -38% and +9%". E para os recrutados novos, "-4%, with a confidence interval between -15% and +9%".

Passei um bom tempo tentando determinar com certeza se aquele sinal negativo significa mais rápido ou mais lento naquela convenção. Cheguei a uma leitura que considero a mais coerente com o resto do texto — mas não a suficiente para eu afirmar aqui como fato. Então não vou afirmar. Se esse ponto importa para o seu argumento, abra a fonte e leia você mesmo.

Isso não é covardia editorial. É o ponto:

Eu, escrevendo um artigo cuja tese é "ninguém abre a fonte primária", quase repeti um resumo que não tinha verificado.

Porque existe uma coisa que independe da convenção de sinal, e é ela que sustenta tudo: os dois intervalos de confiança cruzam o zero. De −38% a +9%. De −15% a +9%. Um intervalo que contém o zero não distingue estatisticamente o efeito de "nenhum efeito" — para qualquer lado. Somado ao "only very weak evidence" dos próprios autores, a leitura defensável é: esse estudo posterior não prova speedup nem prova slowdown. Ele prova que o experimento precisa mudar.

Que é, literalmente, o título do post.

Seja justo com o estudo original

Um parêntese necessário, porque a tentação de virar a mesa é grande e seria a mesma desonestidade de sinal trocado.

O estudo original da METR não era lixo. Era um RCT — ensaio controlado randomizado, com devs sorteados entre fazer a tarefa com e sem IA — bem feito num campo onde quase todo mundo publica anedota com print de terminal. O viés de seleção não é uma trapaça descoberta por um crítico externo — é um problema metodológico honesto, identificado, medido e publicado pelos próprios autores, que ainda por cima estão redesenhando o experimento por causa dele.

Isso é ciência funcionando exatamente como deveria. Um artigo que ridiculariza a METR é pior que um que a cita mal.

O réu aqui não é a METR. É quem cola o link sem ler o que veio depois.

Não é um caso isolado — é o padrão do nicho

Se fosse só a METR, era azar. Não é. Toda vez que fomos atrás da fonte primária de um número famoso deste nicho, achamos a mesma coisa.

• O paper de context rot da Chroma — a empresa do banco de dados vetorial de mesmo nome. Circulam por aí, atribuídos a ele, uma "queda de 30%+" de performance e um "orçamento seguro de 150K–400K tokens". Nenhum dos dois existe no paper. Nasceram em blog de SEO, foram atribuídos a uma fonte respeitável e viraram fato por repetição. O achado real do paper é mais interessante que a invenção — e mais incômodo: em 18 modelos, mesmo em tarefa simples, o desempenho fica cada vez menos confiável conforme a entrada cresce. Sem limiar, sem número seguro. Não há um ponto a partir do qual você deve se preocupar.
• Os relatórios da GitClear sobre clonagem de código. Você já viu "+81%" ou "8x" de aumento em código clonado. Aqui eu preciso desmentir uma coisa que eu mesmo achava: esses números existem. Não são invenção de blog. O "+81%" vem de outro relatório da casa, The Maintainability Gap, sobre 623 milhões de mudanças de código: duplicação de bloco saindo de 40,3 em 2023 para 73,0 em 2026, um aumento de 81% sobre 2023. E o "8x" mede blocos duplicados de cinco linhas ou mais — outra régua, outro denominador. O número que quase todo mundo tem na cabeça como sendo "o" dado da GitClear, 8,3% → 12,3% sobre 211 milhões de linhas, é do relatório de 2025 e mede porcentagem de linhas. Nenhum é falso. Eles só não são a mesma medida, e são citados como se fossem. E a confusão começa na própria fonte: a GitClear titula a página de 2025 como "4x Growth in Code Clones" enquanto o corpo reporta os 8,3% → 12,3% — que dão cerca de 1,5x em termos relativos.

Três números famosos. Três fontes sérias. Três leituras que a fonte não autoriza — e nenhuma delas culpa do pesquisador.

O nicho não tem um problema de opinião. Tem um problema de citação.

O que fazer na prática

Não é sobre virar cético profissional de thread. É um hábito pequeno e barato:

1. Quando um número aparecer, ache o primário antes de repetir. Não o blog que cita, não o tweet que resume: o paper, o relatório, o post do laboratório.
2. Procure o que veio depois. A data do estudo não é a data da verdade. A METR publicou a ressalva oito meses depois. O link que circula é o de 2025.
3. Leia o intervalo de confiança — o IC — e não só o ponto. "19%" com IC de +2% a +39% é uma frase muito diferente de "19%".
4. Procure a seção de limitações. É onde o autor honesto já escreveu o contra-argumento que você ia levar dois dias para formular.
5. Se não deu para verificar, diga que não deu. Custa uma frase e vale a sua credibilidade inteira.

Perguntas frequentes

A METR retratou o estudo dos 19%? Não. Isso é importante e não pode ser distorcido no sentido contrário. Eles não retrataram, não retiraram e não desautorizaram o estudo original. Publicaram uma atualização informando que os dados posteriores sofrem de viés de seleção severo, que essa evidência é fraca e que o desenho do experimento será mudado.

Então a conclusão é que a IA deixa o dev mais rápido? Não é isso que o material sustenta. Os autores dizem acreditar — com base em conversas com participantes, não em dados robustos — que o efeito em 2026 é melhor que o estimado em 2025, e que o número medido é provavelmente um piso. "Provavelmente um piso" não é "está provado". Quem transformar esta atualização em "a ciência agora diz que a IA acelera" está cometendo exatamente o erro que este texto descreve, só que na direção oposta.

Ainda posso citar os 19%? Pode — citando o que ele é: um RCT com dados de fevereiro a junho de 2025, com IC de +2% a +39%, cujos autores publicaram em fevereiro de 2026 uma ressalva sobre viés de seleção e estão redesenhando o experimento. Isso é uma citação. "Está provado que devs com IA são 19% mais lentos" não é.

Por que você não afirmou a direção do −18%? Porque não consegui confirmar a convenção de sinal com a certeza que uma afirmação pública exige, e o assunto deste artigo é precisamente não afirmar o que não se verificou. O que dá para afirmar sem depender disso: os dois intervalos cruzam o zero e os autores chamam o conjunto de "very weak evidence".

Voltando ao placar

57 devs. 143 repos. 800+ tarefas. 30% a 50% recusando-se a fazer tarefa sem IA.

Esse placar não diz quem ganhou a discussão sobre produtividade com IA. Ele diz outra coisa, mais desconfortável: o número mais repetido do nicho tem uma nota de rodapé escrita pelos próprios autores, publicada há meses, em inglês, de graça, num blog aberto — e o nicho continua citando a versão de 2025.

A distância entre o número e a nota de rodapé não é uma falha de pesquisa. É uma falha de leitura.

E a correção não é ficar mais cético. É abrir a aba.