IA dobrou entregas de código, mas também dobrou a fila de revisão

As medições mostram um ganho real, mas localizado: em um estudo empresarial, o throughput de pull requests por pessoa chegou a 2,09 vezes a linha de base, enquanto a carga por revisor aproximadamente dobrou. A IA acelerou a produção de mudanças sem ampliar na mesma proporção a capacidade de verificá-las.

“Entregas” significa aqui pull requests produzidos por pessoa, não implantações em produção. “Fila de revisão” reúne dois efeitos medidos separadamente: mais trabalho para cada revisor no estudo longitudinal e espera 4,6 vezes maior até a primeira revisão em outro benchmark. Os percentuais não podem ser somados nem tratados como uma estimativa universal.

O que realmente dobrou no estudo longitudinal

O estudo longitudinal no arXiv acompanhou 802 desenvolvedores e 196.212 pull requests não automatizados entre janeiro de 2024 e abril de 2026. Na amostra de estimação, formada por 564 profissionais com pelo menos três meses ativos, a média passou de 21,2 para 44,3 PRs por desenvolvedor ativo: 2,09 vezes a base de janeiro a abril de 2025.

O volume total de PRs cresceu 3,1 vezes, mas o grupo de profissionais que atuavam como revisores aumentou apenas 1,5 vez. Com isso, a carga por revisor chegou a aproximadamente duas vezes a base. A cobertura de revisão automatizada subiu de cerca de 19% para 84%, enquanto a parcela de PRs com ao menos uma revisão humana caiu de 89% para 68%.

O resultado não estabelece que a IA, sozinha, causou toda a duplicação. A adoção e a intensidade de uso não foram distribuídas aleatoriamente, o caso envolve uma única empresa jovem e favorável à IA, e o efeito se concentrou em código mais novo. Os próprios autores apresentam 2,09 vezes como um resultado alcançável em condições favoráveis, não como efeito imediato ou típico.

O benchmark separa velocidade de escrita e tempo de espera

O segundo levantamento usa outra população e outra unidade. O benchmark empresarial da Opsera, baseado em dados de mais de 250 mil desenvolvedores de mais de 60 organizações durante 2025, encontrou melhora média de 48% a 58% no tempo até a abertura do PR. Para PRs gerados com IA, porém, a espera pela revisão foi 4,6 vezes maior que para mudanças escritas por humanos.

Esse multiplicador não descreve a duração do trabalho ativo do revisor. O relatório localiza o pico principalmente entre a submissão do PR e o início da primeira revisão; depois disso, também registra maior carga cognitiva até o merge. A distinção importa porque uma fila sem responsável exige capacidade ou roteamento, enquanto uma análise demorada pode indicar mudanças grandes, pouco contexto ou verificações insuficientes.

O relatório é publicado por uma fornecedora de plataforma DevOps e apresenta resultados agregados. Ele serve para identificar um padrão empresarial, mas não informa detalhamento suficiente para reproduzir todos os cálculos ou transferir seus percentuais diretamente a uma equipe específica.

Por que os percentuais não formam uma única taxa de produtividade

Os dois estudos observam etapas diferentes. O número de 2,09 vezes compara PRs mensais por desenvolvedor ativo dentro de uma empresa; a faixa de 48% a 58% mede redução do tempo até o PR em uma amostra empresarial agregada; e 4,6 vezes compara a espera de PRs atribuídos à IA e a humanos. Somar essas medidas produziria um indicador sem unidade coerente.

Uma pesquisa de percepção reforça o diagnóstico, mas não substitui a telemetria. No levantamento do GitLab conduzido pela Harris Poll, 85% dos 1.528 desenvolvedores e compradores de tecnologia consultados em seis países concordaram que o gargalo migrou da escrita para revisão e validação. O resultado mede concordância dos participantes, não duração de ciclo.

Linhas de código também não resolvem a comparação. Mais linhas podem representar uma mudança maior sem entregar mais valor e ainda elevar o esforço de leitura. Contar PRs isoladamente tampouco revela tamanho, risco, incidentes, reversões ou correções posteriores.

Uma planilha conceitual para dimensionar a revisão

Antes de transformar ganho de geração em meta de produção, a liderança pode estimar a capacidade semanal com dados do próprio fluxo. Uma unidade útil é o minuto ativo de revisão por classe de risco, separado da espera na fila. Mudanças simples, normais e críticas devem ter estimativas próprias, de preferência baseadas em medianas e percentis.

• Entrada: PRs recebidos por semana, distribuídos por classe de risco.
• Esforço: minutos ativos por revisão, número médio de rodadas e proporção de PRs com retrabalho.
• Capacidade: número de revisores multiplicado pelas horas efetivamente reservadas, descontadas reuniões, suporte e interrupções.
• Demanda: PRs de cada classe multiplicados pelo tempo de revisão e pelo número médio de rodadas.
• Saturação: demanda total dividida pela capacidade. Acima de 1, a fila tende a crescer; perto de 1, picos e ausências já produzem espera.

Em um exemplo hipotético, 100 PRs semanais com 30 minutos de revisão e média de 1,4 rodada exigem 70 horas. Se existem 60 horas efetivas, a saturação é 1,17. Elevar a entrada para 120 PRs, sem mudar o perfil das alterações, aumenta a demanda para 84 horas e amplia o acúmulo.

A automação só deve entrar como capacidade quando houver redução observada do trabalho humano. Tempo poupado precisa ser confrontado com triagem de falsos positivos, novas rodadas de correção e risco transferido para testes, segurança ou operação.

O teste precisa acompanhar a mudança até a produção

Uma avaliação interna deve estabelecer a linha de base por aplicação ou serviço e acompanhar tempo até o PR, espera pela primeira revisão, tempo ativo de revisão, rodadas de alteração, lead time até produção, reversões, falhas e retrabalho. A orientação de métricas da DORA separa throughput de instabilidade, recomenda preservar o contexto de cada serviço e alerta contra transformar uma única métrica em meta.

Medianas mostram o caso típico; percentis revelam a cauda que alimenta a fila. Os resultados também devem ser segmentados por repositório, risco, experiência do autor e participação da IA, sem atribuir causalidade automática a diferenças observadas.

O critério de sucesso é o fluxo completo: menor tempo até produção, espera controlada e estabilidade ao menos equivalente à base. Se os autores abrem mais PRs, mas revisão e retrabalho absorvem o ganho, a IA acelerou a escrita — não a produtividade do sistema.