Em 2025, 84% dos desenvolvedores já usavam ou planejavam usar ferramentas de IA no dia a dia, segundo o Stack Overflow Developer Survey. A narrativa dominante é que IA multiplica produtividade. GitHub Copilot promete mais projetos por semana. Cursor promete editar arquivos inteiros com um prompt. Claude Code promete agentes autônomos no terminal.
Só que em julho de 2025, um estudo controlado randomizado jogou água fria nessa conversa. Devs experientes, usando as melhores ferramentas disponíveis, levaram 19% mais tempo para completar tarefas com IA do que sem ela. O detalhe que pega: esses mesmos devs achavam que tinham ficado 20% mais rápidos.
Esse gap entre percepção e realidade não é só uma curiosidade acadêmica. Ele afeta como você escolhe suas ferramentas, como avalia seu próprio desempenho e como empresas definem metas de produtividade.
O estudo que ninguém queria ver
A METR (Model Evaluation & Threat Research) conduziu o que é considerado o experimento mais rigoroso até hoje sobre o impacto de IA na produtividade de desenvolvedores. Publicado como paper no arXiv, o estudo recrutou 16 desenvolvedores experientes de repositórios open-source grandes, com média de 22 mil stars e mais de 1 milhão de linhas de código.
Não eram devs aleatórios. Cada participante trabalhava em seu próprio repositório, em issues reais que eles mesmos tinham listado como valiosas. Correções de bugs, features, refatorações. O tipo de trabalho que esses devs fazem no dia a dia.
O resultado central: tarefas com IA levaram 19% mais tempo, com intervalo de confiança entre +2% e +39%. A diferença é estatisticamente significativa.
Mas o dado mais revelador não é o tempo. É a percepção. Antes do experimento, os participantes estimaram que IA os aceleraria em 24%. Depois de completar as tarefas, mesmo tendo levado mais tempo, eles ainda avaliaram que a IA os tinha acelerado em 20%.
Como o experimento foi feito
O design do estudo é o que separa ele de pesquisas anteriores. A maioria dos estudos sobre produtividade com IA usa tarefas sintéticas: resolver um LeetCode, implementar um CRUD padrão, completar um exercício de tutorial. O problema é que essas tarefas não representam o trabalho real de um dev senior.
A METR fez diferente:
- 246 issues reais foram coletadas dos próprios participantes
- Cada issue foi randomicamente designada para "com IA" ou "sem IA"
- Quando IA era permitida, os devs podiam usar qualquer ferramenta (a maioria escolheu Cursor Pro com Claude 3.5 e 3.7 Sonnet)
- Quando IA era proibida, nenhuma ferramenta generativa era permitida
- O tempo era medido do início ao fim da resolução, incluindo debugging e testes
O ponto crítico: os devs conheciam profundamente o codebase. Eles tinham anos de contribuição nesses repositórios. Isso elimina a vantagem que IA tem em codebases desconhecidos, onde funciona como um "colega que já leu a documentação".
Por que você se sente mais rápido
A METR levantou algumas hipóteses para o gap percepção-realidade, e cada uma delas faz sentido quando você para para pensar.
A primeira é o custo de supervisão. Quando a IA gera 50 linhas de código em 3 segundos, você sente que avançou. Só que depois vem a revisão: verificar se a lógica está correta, se os tipos batem, se o edge case foi coberto, se a API usada ainda existe. Esse tempo de revisão é cognitivamente cansativo, mas não "parece" trabalho da mesma forma que digitar código.
A segunda hipótese é o viés de atenção seletiva. Você lembra das vezes em que a IA acertou de primeira e economizou 20 minutos. Você não lembra tão bem das vezes em que gastou 40 minutos debugando uma sugestão que parecia correta mas tinha um bug sutil. O cérebro naturalmente dá mais peso aos momentos de satisfação imediata.
A terceira é o efeito de fluência. Quando a IA gera código rápido, o fluxo parece mais ágil. Você tem a sensação de momentum. Mas momentum percebido não é a mesma coisa que progresso real. É como dirigir rápido numa estrada que te leva na direção errada: você sente velocidade, mas está se afastando do destino.
O Stack Overflow Developer Survey 2025 reforça isso por outro ângulo. A principal frustração dos devs com IA, citada por 66% dos respondentes, é lidar com "soluções que estão quase certas, mas não completamente". E a segunda frustração: "debugar código gerado por IA consome mais tempo".
O custo cognitivo invisível
Se o estudo da METR mostra o custo em tempo, uma pesquisa da UC Berkeley publicada em fevereiro de 2026 mostra o custo em energia mental.
Pesquisadores conduziram uma etnografia de oito meses em uma empresa de tecnologia americana com 200 funcionários, incluindo 40 entrevistas aprofundadas com engenheiros, PMs, designers e profissionais de operações. A conclusão é contraintuitiva: IA não reduz trabalho, ela intensifica trabalho.
O mecanismo funciona assim: quando você delega tarefas rotineiras para a IA, o que sobra no seu prato são as decisões complexas, os problemas ambíguos, as revisões que exigem julgamento. Em teoria, isso é ótimo. Na prática, o cérebro humano não foi feito para operar em intensidade cognitiva máxima por oito horas seguidas. Aquelas tarefas "chatas" que a IA automatizou serviam como respiro mental entre blocos de trabalho pesado.
Os pesquisadores identificaram um padrão que chamaram de "workload creep": o tempo que a IA economiza não volta para o dev como descanso ou pensamento profundo. Ele é imediatamente preenchido com mais trabalho, frequentemente de natureza diferente da função original. Product managers começam a escrever código. Pesquisadores assumem tarefas de engenharia. As fronteiras entre funções se dissolvem.
No sexto mês do estudo, relatos de burnout, ansiedade e paralisia decisória tinham disparado. E a parte mais traiçoeira: as métricas de produtividade da empresa continuavam estáveis. Número de PRs, velocidade de sprint, deploys por semana. Tudo normal. O que os números não capturam é a erosão silenciosa das reservas mentais.
Uma análise publicada pela Harvard Business Review em fevereiro de 2026 resume a situação: quem mais abraça IA é quem primeiro mostra sinais de burnout. Não os resistentes, não os céticos. Os entusiastas.
Quando IA realmente ajuda (e quando atrapalha)
Nada disso significa que IA é inútil para desenvolvimento. O estudo da METR tem limitações que os próprios autores reconhecem: amostra pequena (16 devs), ferramentas de uma época específica (início de 2025), e foco em devs que já conheciam profundamente seus codebases.
A METR publicou em fevereiro de 2026 que está redesenhando a metodologia do experimento. Um dos motivos: devs que não querem trabalhar sem IA passaram a recusar participação, o que pode enviesar os resultados. As ferramentas também evoluem, e os efeitos podem ser diferentes em codebases novos versus codebases familiares.
Alguns cenários onde IA tende a ajudar de verdade:
- Boilerplate e código repetitivo: testes unitários padrão, CRUDs, configurações de CI/CD. Tarefas onde o resultado correto é previsível e a revisão é rápida
- Explorar codebases desconhecidos: perguntar "como funciona o sistema de autenticação nesse projeto?" é mais rápido que ler 15 arquivos
- Prototipagem rápida: quando você quer validar uma ideia antes de investir tempo em implementação
- Tradução entre linguagens: converter um script Python para TypeScript quando a lógica já está clara
Cenários onde IA tende a atrapalhar:
- Lógica de domínio complexa: regras de negócio que exigem contexto profundo do sistema
- Debugging em produção: a IA não tem acesso aos seus logs, ao estado do banco, ao histórico de deploys
- Decisões de arquitetura: escolher entre monolito e microsserviços não é um problema de completar código
- Código crítico de segurança: segundo o GenAI Code Security Report da Veracode, código gerado por IA introduz vulnerabilidades em 45% das tarefas avaliadas
Como medir sua produtividade real
Se a percepção não é confiável, o que usar no lugar? Existem frameworks consolidados que vão além de contar linhas de código ou PRs mergeados.
O DORA (DevOps Research and Assessment) mede quatro métricas: frequência de deploy, lead time de mudanças, taxa de falha em mudanças e tempo médio de recuperação. É o framework de produtividade mais adotado entre os três. O problema: ele mede o pipeline, não o dev.
O SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) foi criado por pesquisadores da Microsoft, GitHub e University of Victoria. Ele adiciona dimensões humanas: satisfação, estado de flow, qualidade da comunicação. Complementa o DORA onde ele falha.
Para uso individual, algumas práticas concretas:
- Registre tempo real por tarefa, não tempo percebido. Use um timer. Compare tarefas similares com e sem IA ao longo de semanas, não de um único dia
- Monitore retrabalho: quantas vezes você voltou para corrigir algo que a IA gerou? Bugs introduzidos por sugestões contam como custo, não como economia
- Avalie complexidade, não volume: 10 PRs de renomeação de variáveis não valem mais que 1 PR que resolve um bug crítico em produção
- Observe seu nível de energia: se você está entregando o mesmo volume mas terminando o dia exausto, sua produtividade sustentável está caindo
A confiança dos devs na precisão das ferramentas de IA vem caindo. Em 2023 e 2024, mais de 70% dos desenvolvedores tinham sentimento positivo. Em 2025, caiu para 60%. Hoje, 46% dos devs desconfiam ativamente da precisão do output de IA, contra 33% que confiam. Apenas 3% confiam plenamente.
Isso não é pessimismo. É maturidade. Os primeiros anos de qualquer tecnologia são marcados por expectativas infladas. O que estamos vivendo agora é o ajuste de expectativas, onde o entusiasmo cede espaço para avaliação crítica.
Conclusão
O paradoxo da produtividade com IA não é sobre IA ser boa ou ruim. É sobre uma coisa mais básica: nós somos péssimos juízes do nosso próprio desempenho quando uma ferramenta muda a textura do trabalho.
Você se sente mais rápido porque a IA muda o ritmo do trabalho. Gerar código é instantâneo, revisar código é lento. O cérebro confunde a velocidade da geração com velocidade da entrega. E enquanto isso, o tempo de revisão, debugging e correção se acumula silenciosamente.
A METR planeja repetir o experimento com ferramentas mais recentes e metodologia atualizada. Os resultados podem ser diferentes. Mas o aprendizado central permanece: métricas de percepção não substituem métricas de realidade. Se você quer saber se IA te ajuda de verdade, meça. Com um timer, com dados de retrabalho, com honestidade sobre seu nível de energia no fim do dia.
As ferramentas vão melhorar. A questão é se nós vamos melhorar junto com elas na capacidade de avaliar quando elas realmente ajudam.
Referências pesquisadas nesta publicação
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR
- We are Changing our Developer Productivity Experiment Design - METR
- AI Section - 2025 Stack Overflow Developer Survey
- Developers remain willing but reluctant to use AI - Stack Overflow Blog
- AI is having the opposite effect it was supposed to, UC Berkeley researchers warn - Fortune
- AI Doesn't Reduce Work - It Intensifies It - Harvard Business Review
- The first signs of burnout are coming from the people who embrace AI the most - TechCrunch
- AI-Generated Code Security Risks - Veracode GenAI Code Security Report
- Comparing DORA, SPACE, and DX Core 4 - Swarmia