Faros AI: agentes de IA geraram +98% de pull requests, mas o tempo de revisão subiu 91%

Equipes com agentes de IA escrevem código mais rápido, mas o código não chega à main mais rápido e, em alguns casos, chega até mais devagar. O Habr analisou esse paradoxo com dados da Faros AI, da CircleCI e da DORA. O número mais citado do relatório da Faros AI, construído com telemetria de mais de 10 mil desenvolvedores: quem usa IA ativamente tem 21% mais tarefas concluídas e 98% mais pull requests mesclados. O tempo de revisão, porém, aumentou 91%.

A lógica é simples. Gerar código ficou quase de graça, mas a verificação continua sendo trabalho humano. Se a entrada do pipeline recebe o dobro de material e na saída continua o mesmo revisor, a fila cresce.

Onde o código trava

O problema não está na quantidade de PRs, mas no tamanho deles. De acordo com a Faros AI, o pull request médio em equipes com alta adoção de IA cresceu cerca de 154%. O agente faz um grande refatoramento sem cerimônia, adiciona testes e mexe em módulos vizinhos. O revisor precisa manter mais contexto na cabeça, e uma revisão cuidadosa de um diff de 800 linhas leva bem mais tempo do que a de um de 300.

O segundo ponto de perda está no QA. A Faros AI registrou um aumento de cerca de 9% no número de bugs por desenvolvedor. Cada defeito adicional devolve a tarefa ao ciclo: comentários, correções, nova execução do CI, nova revisão. A métrica de "tarefas concluídas" sobe, enquanto o lead time até a produção fica parado ou aumenta.

Os dados da DORA mostram o mesmo quadro por outro ângulo. No relatório de 2024, um aumento de 25% na adoção de IA se correlacionou com uma queda de 1,5% na vazão de entregas e de 7,2% na estabilidade. Mais tarde, a DORA passou a descrever a IA como um amplificador: ela acelera os bons processos e expõe os fracos. A CircleCI olha o problema pelos pipelines de CI. Os dados dela mostram onde se acumulam builds com falha e execuções demoradas, ou seja, onde a velocidade de escrita esbarra na velocidade de verificação.

Métricas que vale acompanhar

Para encontrar o gargalo, estatísticas de commits não bastam. É preciso uma visão de ponta a ponta, do primeiro commit ao deploy:

• Tempo até a primeira revisão: quanto um PR espera até que alguém sequer olhe para ele.
• Tempo total de revisão: da abertura até o approve.
• Tamanho do PR em linhas e arquivos, incluindo a mediana e o percentil 90.
• Proporção de PRs devolvidos para ajustes após a revisão ou o QA.
• Change failure rate e tempo de recuperação após um incidente.
• Lead time for changes: do commit até a produção.

Se os dois primeiros indicadores crescem junto com a quantidade de PRs, o problema está na revisão. Se aumentam a proporção de devoluções e o change failure rate, o limite está na qualidade do próprio código gerado e dos testes.

O que as equipes podem fazer

Primeiro: limitar o tamanho das mudanças. Muitas equipes estão adotando um limite rígido por PR e pedindo aos agentes que dividam o trabalho em partes pequenas e atômicas. Isso sai mais barato do que contratar mais dois revisores.

Segundo: usar IA também do lado da verificação. Revisão automática inicial, linters, análise estática e geração de testes tiram a rotina das mãos das pessoas e deixam para elas as questões de arquitetura. Mas a qualidade dessa revisão também precisa ser medida, senão o gargalo apenas muda de lugar.

Terceiro: rever as métricas de produtividade. Na era dos agentes, a quantidade de PRs e de tarefas concluídas por pessoa diz quase nada. Lead time e estabilidade das releases são mais reveladores, justamente as métricas que a DORA usa há muitos anos.

Quarto: reforçar as verificações automáticas antes da revisão. Quanto mais confiáveis o CI e a cobertura de testes, menos trabalho sobra para as pessoas. Um teste prático para qualquer líder de equipe: pegue os últimos 100 PRs mesclados e veja quanto tempo cada um passou esperando revisão, e não em desenvolvimento. Provavelmente é ali que está o ganho que os agentes prometeram a você.