Faros: em equipes com agentes de IA, o tempo mediano de revisão de código subiu 441%

A telemetria da Faros, com 22 000 desenvolvedores, mostra que, em equipes com alta adoção de IA, o tempo mediano de revisão de código subiu 441%, e os pull requests sem qualquer revisão passaram a ser mesclados 31% mais vezes. O tempo que os agentes economizam acaba sendo gasto pelas próprias pessoas em novas tarefas e na checagem de código alheio. Em setembro, um autor do Habr escreveu para conhecidos que haviam começado a trabalhar com agentes de IA dois meses antes e perguntou como estavam as coisas.

Ele esperava histórias de aceleração, e elas apareceram: um deixou de analisar logs manualmente, outro começou a pegar tarefas de frontend, backend e DevOps. Mas, na maioria das vezes, as respostas foram outras: o volume de revisões cresceu muito, passa por eles muito mais informação e, no fim do dia, não sobra energia para o projeto pessoal. Daí a pergunta: isso é uma fase ruim passageira ou a nova norma?

Os desenvolvedores gastam sozinhos o tempo economizado

Pesquisadores de Berkeley Haas acompanharam por oito meses uma empresa de tecnologia americana com cerca de 200 pessoas (os resultados foram publicados pela HBR). Com IA generativa, os funcionários trabalham mais rápido, assumem tarefas mais amplas e terminam mais tarde, embora ninguém exija isso. Os prompts saem na hora do almoço, durante reuniões por chamada e enquanto um arquivo carrega. O ganho inicial de produtividade, com o tempo, dá lugar a queda de qualidade e rotatividade.

Os dados da Faros batem com essa observação: as pessoas simplesmente deixam de dar conta de verificar o fluxo de mudanças. O estudo da BCG esclarece a causa do cansaço. Quando a IA assume o trabalho de rotina, o burnout diminui. Quando o trabalho vira supervisão constante de um agente, crescem a fadiga de decisão e a vontade de pedir demissão. Escreve-se menos código, mas aumentam a definição de tarefas, a verificação e as decisões, e a maioria dos desenvolvedores não aprendeu essa habilidade de forma deliberada.

Primeiro piora: curva de aprendizado e sensações enganosas

O estudo mais citado sobre lentidão é o de julho da METR (laboratório que mede o efeito real da IA no trabalho). 16 desenvolvedores experientes de open source resolveram tarefas nos próprios repositórios e, com IA, levaram 19% mais tempo. Antes do experimento, eles esperavam uma aceleração de 24% e, depois, ainda assim achavam que tinham ficado 20% mais rápidos. Os participantes usaram o Cursor por apenas algumas dezenas de horas, e os autores escrevem explicitamente que não é possível descartar um efeito de aprendizado após 50+ horas.

Uma nova medição, seis meses depois, com dez participantes que voltaram, mostrou uma aceleração de cerca de 18%. O intervalo de confiança, porém, inclui o zero, e os próprios autores chamam o sinal de pouco confiável: muitos se recusaram a trabalhar sem IA, e a amostra ficou enviesada. Na pesquisa da METR, as pessoas avaliam o benefício como cerca de duas vezes maior, e, segundo medições anteriores, superestimam o efeito em média em 40 pontos percentuais.

A conclusão do autor: sem habilidade e sem um projeto preparado, a IA realmente pode atrasar, e as sensações enganam. Quem desiste no fundo do poço conclui: «IA não funciona». Quem passa por ele conclui: «sem isso, não consigo mais». O perigo está no meio do caminho: a pessoa vê no feed dez agentes que zeraram o backlog durante a noite, instala mais um framework e cinco MCPs, roda agentes em paralelo e entra em um estado de ansiedade constante.

Confiança é igual a verificabilidade: a ordem da adoção

A pesquisa Stack Overflow 2026 mostra o limite: em decisões importantes, 6% dos desenvolvedores confiam na IA, mas quase metade confia se puder verificar o resultado. Sem uma verificação automática rápida, restam dois extremos desgastantes: ler cada linha ou aceitar o «pronto» na palavra e lidar com as consequências uma semana depois. Uma postura sensata é a de um tech lead: controlar o «tronco e os galhos» (arquitetura, billing, modelo de dados, testes críticos) e não mexer em cada folha.

Na enquete no canal do autor no Telegram, apenas 2 de 32 respondentes apontaram a escolha da ferramenta como principal problema, e 19 citaram a sistematização do conhecimento. A ordem a que ele chegou:

• base de engenharia, sem a qual não se distingue uma mudança que funciona de uma que apenas parece plausível;
• definição da tarefa com critérios de aceitação antes de escrever o código;
• feedback loop: tipos, linter, testes, navegador, logs, para que o agente verifique a si mesmo;
• extensões (skills, MCP, plugins) somente depois disso;
• conhecimento sobre o projeto, plano para tarefas grandes e revisão por requisitos;
• agentes paralelos, só no final.

Uma etapa pulada sai mais cara depois. Um erro típico é pular direto para Spec-Driven Development, orquestradores e cinco agentes. Iniciantes ficam com specs 3–5 vezes maiores que o código, que ninguém lê, limites de uso esgotados e a sensação de caixa-preta. A instalação às cegas de extensões ainda representa risco na cadeia de suprimentos: em fevereiro de 2026, a Koi Security encontrou 341 skills maliciosos entre 2 857 no marketplace ClawHub.

O jeito de aprender também importa. No experimento da Anthropic, juniores que aprenderam uma nova biblioteca com IA fizeram 50% no teste, contra 67% sem IA. Já os que faziam perguntas conceituais ao agente e resolviam os erros por conta própria fizeram 65% ou mais.

A conclusão do autor: a fase ruim passa, mas o volume de trabalho de verificação não, e essa é a nova norma. É possível reduzir a carga entregando as verificações de rotina a ferramentas e a um segundo agente com contexto limpo, ficando apenas com o que é crítico e não mantendo abertos mais agentes do que se consegue revisar. O autor apresentará sua palestra sobre o tema na conferência online AI Dev Live, em 12 de novembro.