Greg Wilson Acaba de Dar Espinha Acadêmica ao Ceticismo Sobre Produtividade de IA

Todo ensaio de ceticismo sobre medição de produtividade de IA em codificação que publicamos nos últimos seis meses carregou a mesma nota de rodapé incômoda: a maior parte dos números que estávamos rebatendo vinha de blogs de fornecedores, e a maior parte dos números que citávamos para rebater vinha de um punhado pequeno de estudos que todo mundo repete porque não há muito mais a citar. A literatura existia. Estava apenas dispersa. Ninguém havia montado.

Greg Wilson montou em 20 de maio de 2026. Twelve Ways to Be Wrong About AI-Assisted Coding é a espinha revisada por pares que faltava no debate de produtividade. Cada um dos doze modos de falha que Wilson cataloga vem com pelo menos uma fonte acadêmica por trás, e as citações são majoritariamente de 2025 e 2026, o que significa que o campo finalmente produziu trabalho empírico suficiente para fazer uma revisão de verdade.

Se você passou algum tempo argumentando contra a alegação de “40% mais rápido com nosso copilot” de algum fornecedor e se pegou alcançando as mesmas três referências, este é o documento que substitui aquele arsenal.

O Que os Estudos de Fato Dizem

A descoberta de manchete que atravessa a revisão de Wilson é que benchmarks de fornecedores e medições de campo discordam por um fator que deveria envergonhar quem ainda cita os primeiros. Becker (2025) constatou que o GitHub Copilot produziu aceleração de 55% em problemas artificiais de codificação. Rode a mesma ferramenta contra trabalho real de manutenção em código aberto e o efeito se inverte: lentidão de 19%, não aceleração. O estudo de Peng (2023) que Wilson cita como origem dos 55% foi sobre uma tarefa construída que não se parece em nada com manter uma base de código de cinco anos com dezessete contribuidores.

A descoberta sobre desenvolvedores sêniores é a que deveria fazer líderes de engenharia parar. O mesmo corpo de pesquisa que mostra desenvolvedores juniores recebendo aceleração genuína também mostra desenvolvedores sêniores experimentando queda de 19% de produtividade. O mecanismo não é misterioso. Sêniores absorvem a carga de revisão do código gerado por IA que juniores fazem merge. A saída da ferramenta vira a entrada deles, e a entrada é de qualidade inferior àquela que o sênior teria escrito sozinho. Escrevemos sobre essa dinâmica em A Armadilha da Velocidade na Codificação com IA; a revisão de Wilson agora dá citação ao argumento.

Liu (2026) mediu o arrasto de qualidade diretamente: mais de 15% dos commits gerados por IA introduzem problemas de qualidade, e cerca de 25% desses problemas persistem no longo prazo. Isso não é custo transitório. É dívida técnica sendo entregue a uma taxa que supera a capacidade de captura da revisão normal de código, e ela se compõe.

He (2026) estudou a adoção de Cursor especificamente e descobriu que os ganhos de velocidade foram transitórios enquanto os aumentos de complexidade foram persistentes. O time ficou mais rápido por um trimestre, voltou para a velocidade baseline e ficou carregando uma carga de complexidade permanentemente maior. Esse é o desacoplamento entre saída e competência sobre o qual escrevemos, agora medido longitudinalmente.

Os estudos corporativos contam a mesma história pelo lado de compras. Bakal (2025) reportou taxa de aceitação de 33% para sugestões de IA em ambientes de produção, sem rastreamento de correção atrelado. A organização que compra a ferramenta sabe com que frequência o desenvolvedor aceita a sugestão. Não sabe com que frequência a sugestão aceita estava correta. Weisz (2025) na IBM mediu ganhos desiguais entre usuários em um estudo controlado, com variância grande o suficiente para que números agregados de “lift de produtividade” virassem irrelevantes.

O piso de segurança é o que deveria fazer qualquer CISO ler o artigo duas vezes. Pearce (2022), confirmado por Dora (2025), testou cinco grandes LLMs contra padrões consolidados de segurança web. Os cinco falharam. Não “tiveram desempenho abaixo do esperado”. Falharam. A implicação é que qualquer time medindo produtividade de IA em codificação sem medir segurança de IA em codificação está calculando um numerador enquanto ignora um denominador que pode já tê-lo superado.

Por Que Isso É Revisão de Literatura e Não Mais um Ensaio

A razão pela qual o texto de Wilson importa não é que ele faça um argumento novo. O argumento já foi feito. Importa porque, pela primeira vez, dá para entregar as citações para outra pessoa.

Toda vez que escrevemos sobre o problema dos dois por cento de produtividade, ou sobre por que medir o time e não o modelo é a única jogada honesta, ou sobre a diferença do harness, estávamos argumentando em um vácuo em que o outro lado cita deck de marketing de SaaS e o nosso lado cita três estudos no replay. Wilson catalogou o resto. Becker, Peng, Liu, He, Bakal, Weisz, Pearce, Dora. Os nomes importam porque os nomes são como a conversa migra de crença para citação.

Se você senta em uma reunião em que alguém diz “nossos desenvolvedores estão 40% mais rápidos com esta ferramenta”, agora dá para fazer três perguntas com respaldo acadêmico:

Qual é a distribuição de tarefas? Becker mostrou que a aceleração de 55% colapsa para lentidão de 19% quando você sai de problemas artificiais para trabalho real de manutenção.
Qual é a distribuição de senioridade? O mesmo número de produtividade médio entre juniores e sêniores esconde uma queda na ponta sênior.
Qual é o horizonte de persistência? He mostrou que o ganho de velocidade é transitório e o custo de complexidade é permanente.

Três perguntas. Três citações. O fornecedor não pode mais responder com outro deck.

A Implementação Continua a Mesma

A revisão de Wilson não muda como se parece um programa sério de medição. Muda apenas o som da conversa em torno de compras e adoção. O trabalho de implementação que publicamos continua de pé.

Se você quer medir o seu time em vez do modelo, A Era Centauro do Software continua sendo o framework. Se você quer entender por que competência de saída e verificação precisam ser medidas separadamente, o ensaio sobre a camada de verificação continua sendo a decomposição. Se você quer saber por que o mesmo modelo produz números de produtividade diferentes em harnesses diferentes, a diferença do harness continua sendo a explicação.

O que muda é o que você coloca na frente das pessoas que não leem esses ensaios. Você coloca Wilson na frente delas. Coloca Becker, Liu, He, Pearce na frente delas. Os ensaios de ceticismo eram para praticantes. A revisão de literatura é para todos os outros.

Faça Isso Agora

Reserve trinta minutos esta semana. Leia o texto de Wilson do começo ao fim. Puxe as três ou quatro citações mais relevantes para as alegações de produtividade que você está sendo solicitado a avaliar ou rebater agora. Adicione-as ao documento compartilhado que a sua organização de engenharia usa para avaliação de fornecedores. Na próxima vez que alguém entrar com um deck de “40% mais rápido”, o documento já estará com as contra-citações carregadas.

Em seguida, dê o passo mais difícil: audite as suas próprias alegações internas de produtividade para ferramentas de IA em codificação. Se você disse a um executivo “nosso time está X% mais produtivo desde a adoção de Y”, confira essa alegação contra os doze modos de falha de Wilson. A descoberta mais comum é que a métrica mediu algo diferente do que o nome sugeria. Esse é o momento de consertar a métrica, não de defendê-la.

O debate de produtividade acabou de deixar de ser concurso de impressões. A literatura está montada. Os nomes têm citações. Os fornecedores não levam mais a última palavra por padrão.

Fontes

Greg Wilson. “Twelve Ways to Be Wrong About AI-Assisted Coding.” Maio de 2026.

A Victorino ajuda líderes de engenharia a substituir alegações de produtividade dos fornecedores por medições que sobrevivem a uma revisão por pares: contato@victorino.com.br | www.victorino.com.br