Pesquisas da Anthropic e do METR mostram risco na formação de novos engenheiros com o uso intenso de IA

A promessa que não se confirmou

Cerca de um ano antes desta palestra na QCon London, em uma conferência em Nova York, Dario Amodei, cofundador da Anthropic, afirmou que em três a seis meses a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → escreveria 90% de todo código produzido, e que em 12 meses seria praticamente 100%. Aos seis meses, ele próprio deu a declaração por confirmada, citando o número de 90% dentro da Anthropic. Isso é relatado na palestra de Alasdair Allan na QCon London, publicada pela InfoQ.

Um ano depois da previsão original, uma análise da Redwood Research concluiu que o número de 90% era enganoso: contando apenas código efetivamente commitado em repositórios, o percentual fica perto de 50%. Ele só chega a 90% somando scripts descartáveis e explorações que nunca entraram em produção. Allan compara esse dado com números internos de outras empresas: o Google reporta pouco mais de 25% de código interno gerado por IA, a Microsoft fica perto de 30%, e o GitHub Copilot tem taxa de aceitação de sugestões em torno de 30% no ambiente corporativo. Nenhum desses números mudou de forma relevante nos últimos seis meses antes da palestra.

Em resumo: a IA realmente mudou o volume de código escrito, mas não da forma essencialmente total que Amodei previu. A pergunta que interessa a Allan não é quanto código a IA escreve, e sim o que acontece com a formação de engenheiros quando a etapa de escrever código, historicamente o jeito de aprender engenharia, passa a ser feita por uma máquina.

O paradoxo da supervisão

Em julho de 2025, o METR (Model Evaluation and Threat Research) publicou um estudo controlado e randomizado, não uma pesquisa de fornecedor, que rendeu a manchete da Reuters "AI slows down some experienced software developers, study finds". Desenvolvedores experientes usando ferramentas de IA levaram 19% mais tempo para completar tarefas do que levariam sem IA. Antes de começar, eles previam que a IA os deixaria 24% mais rápidos; depois de terminar, ainda achavam que tinham sido 20% mais rápidos. A diferença entre percepção e realidade chegou a 43 pontos percentuais.

O desdobramento é mais revelador que o resultado original. Em fevereiro de 2026, o METR tentou repetir o estudo e não conseguiu: não por falha de metodologia, mas porque não achou desenvolvedores dispostos a trabalhar metade das tarefas sem IA. Uma fatia crescente de participantes recusou participar de qualquer estudo que exigisse isso. Em menos de um ano, a dependência deixou de ser opcional e se tornou estrutural antes que alguém entendesse de fato o que a ferramenta estava fazendo com quem a usa.

Eu construí isso agora significa eu dei o prompt para isso.

Alasdair Allan, CTO da Negroni Venture Studios, em palestra na QCon LondonI built this now means I prompted this.

O que o estudo da Anthropic com juniores mostrou

A Anthropic rodou seu próprio ensaio controlado: 52 engenheiros, em sua maioria juniores, aprendendo a biblioteca Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → Trio, com ou sem assistência de IA. O tempo para concluir a tarefa não teve diferença estatística relevante entre os dois grupos (p-valor de 0,391) — a IA não acelerou o aprendizado de forma mensurável.

O que teve diferença estatística significativa (p-valor de 0,01) foi o resultado de um teste de domínio aplicado depois. O grupo que usou IA tirou 50% de acerto contra 67% do grupo sem IA, uma queda de 17 pontos, concentrada justamente nas perguntas sobre depuração, a habilidade necessária para verificar se o código gerado pela IA está certo.

O ganho de produtividade dos assistentes de IA nessa tarefa não atingiu significância estatística.

Trecho do paper da Anthropic sobre o experimento com a biblioteca Trio, citado na palestra de Alasdair AllanThe productivity gain from AI assistants on this task failed to reach statistical significance.

A própria Anthropic batizou o fenômeno de "paradoxo da supervisão": usar IA exige supervisão humana, e supervisão exige exatamente as habilidades de leitura e depuração de código que se atrofiam com o uso excessivo da própria IA. Allan identificou três padrões de falha entre quem tirou nota baixa no teste:

• Delegação total: nem tentou resolver sozinho, dependeu da IA desde o início.
• Dependência progressiva: tentou por um tempo e depois passou a depender inteiramente da IA.
• Depuração iterativa da IA pela IA: usou a IA para corrigir o próprio código que a IA havia gerado, sem entender o que havia sido feito.

Todos os engenheiros nesses três grupos ficaram abaixo de 40% de acerto, contra 67% do grupo sem IA.

Onde a trilha de progressão quebra

O METR também mede o que chama de "horizonte de tarefa com 50% de confiabilidade": a duração de tarefa humana que um agente de IA consegue concluir sozinho, com metade de chance de acerto. Esse horizonte dobra a cada sete meses desde 2019, e a cada quatro meses desde 2024. Só que a curva de sucesso despenca depois de cerca de uma hora de tarefa: a IA acerta quase 100% das tarefas de poucos minutos, típicas do primeiro ano de um júnior, e menos de 10% das tarefas de mais de quatro horas, que dependem de julgamento acumulado.

Outra medição do próprio METR mostra por que esse número exagera a capacidade real: em 18 tarefas de projetos open source maduros, o Claude 3.7 Sonnet não produziu nenhum pull request aceitável em 38% dos casos, mesmo passando nos testes automatizados. Toda PR gerada tinha pelo menos três problemas de qualidade (documentação, cobertura de teste ou lint), e corrigir a PR até ficar aceitável levava em média 42 minutos, cerca de um terço do tempo que um humano gastaria fazendo a tarefa do zero.

Dois levantamentos de mercado, citados por Allan, mostram o mesmo gargalo migrando de lugar:

O gargalo não desaparece: ele sobe para a revisão de código, exatamente onde mora o julgamento sênior. E é esse julgamento que a adoção maciça entre juniores não está construindo.

O caso Amazon Kiro

Allan usa um incidente real para ilustrar o risco. Em meados de dezembro de 2025, engenheiros da AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → deram ao Kiro, ferramenta de codificação por IA da Amazon, permissões de operador equivalentes às de um engenheiro humano para alterar o AWS Cost Explorer. O agente decidiu que a melhor abordagem era apagar e recriar todo o ambiente em vez de fazer mudanças pontuais, e a AWS levou 13 horas para recuperar o serviço em uma das regiões da China.

A Amazon atribuiu o incidente a erro de configuração de controle de acesso. Quatro fontes ouvidas depois pelo Financial Times, segundo a palestra, disseram que foi o próprio Kiro quem tomou a decisão de apagar e recriar o ambiente de produção de forma autônoma, algo que um engenheiro humano experiente dificilmente faria, justamente por já ter visto esse tipo de operação dar errado antes.

O que isso significa para quem contrata e forma devs no Brasil

O recorte de Allan serve de alerta direto para squads brasileiros que hoje colocam juniores recém-saídos de bootcamp para trabalhar majoritariamente com agentes de codificação, sem rotina estruturada de revisão com sênior. Se a curva de sucesso da IA despenca depois de uma hora de tarefa, é exatamente nas tarefas longas e ambíguas, as que formam julgamento, que o júnior brasileiro precisa continuar sendo colocado para programar sem assistência, mesmo que isso pareça mais lento no curto prazo.

Para quem lidera equipe de engenharia, o dado da Faros AI sobre PRs 154% maiores e revisão 91% mais lenta é um aviso prático: o gargalo migrou para o code review, e revisor sênior sobrecarregado tende a aprovar PR grande por cansaço, não por confiança. Nenhum dos estudos citados por Allan recomenda banir IA; o ponto é que usar a ferramenta sem redesenhar como juniores praticam debugging e leitura de código legado tende a produzir, em alguns anos, um time sem gente capaz de supervisionar o que a própria IA produz.

Fonte: InfoQ