Agentes de IA: pull requests sobem 98%, mas a revisão atrasa 91%. Para onde foi a fila?

Sergey Proshchaev, Tech Lead e responsável pelo desenvolvimento Java | Kotlin em FinTech & E-commerce, analisou três grandes estudos de 2025-2026 e encontrou um padrão: a IA acelerou a escrita de código, mas desacelerou a entrega em produção.

A observação básica é simples. Um desenvolvedor com um agente de IA monta em uma noite uma funcionalidade que antes levaria uma semana. Abre um PR de mil e quinhentas linhas. Depois o MR fica três dias em revisão (com mais quatro iguais esperando na fila), recebe um comentário sobre o nome de uma variável, segue para o QA, e lá também trava. Uma semana depois, algo que ninguém realmente leu aparece em produção.

A IA acelerou a geração mais rápido do que a equipe consegue revisar, integrar e entregar. O gargalo não desaparece — ele só se desloca para mais adiante no pipeline.

Três estudos, uma conclusão: gerar é barato, verificar não

Faros AI: The AI Productivity Paradox (julho de 2025) — dados de 10 mil desenvolvedores em 1.255 equipes. O resultado parece positivo: desenvolvedores que usam ativamente assistentes de IA fecham 21% mais tarefas e enviam 98% mais pull requests. Mas um detalhe muda o quadro: o tempo de revisão subiu 91%, o tamanho médio do PR, 154%, e o número de bugs por desenvolvedor, 9%. No nível da empresa, os pesquisadores não encontraram correlação significativa com os resultados.

Faros AI: The Speed Trap (18 de setembro de 2026) — 22 mil desenvolvedores em 4 mil equipes ao longo de 12 meses. O tempo em QA cresceu 300,6% — a piora mais forte entre todas as métricas de fluxo. O tamanho médio do PR está 71,8% mais alto, e os incidentes mensais subiram 125,4%. Um dado alarmante: os PRs fundidos sem revisão saltaram de 31,3% para 76,3%.

CircleCI: Software Delivery Report 2026 — 28,7 milhões de execuções de CI em setembro de 2025. O número médio de execuções diárias cresceu 59% ano a ano, mas, na equipe mediana, a atividade em branches de funcionalidades subiu apenas 15%, enquanto na main caiu 7%. A taxa de builds bem-sucedidos na main caiu para 70,8% (mínima em cinco anos), e o tempo de recuperação até um build verde foi de 72 minutos. Menos de 5% das equipes conseguiram aumentar ao mesmo tempo o desenvolvimento e a passagem de mudanças pela main.

DORA 2025: em 2024, um aumento de 25% no uso de IA veio acompanhado de uma queda de 1,5% na velocidade de entrega e de 7,2% na estabilidade. Em 2025, o quadro mudou: a relação da IA com a velocidade de entrega e os resultados do produto se tornou positiva, mas com a estabilidade permaneceu negativa. Os autores chamam a IA de "espelho e multiplicador" — ela acelera o desenvolvimento, mas, sem forte automação de testes, o aumento no volume de mudanças se transforma em instabilidade.

Onde a fila realmente travou

Os pull requests avançam em paralelo pela geração e pela revisão humana, e depois esperam em QA, integração e implantação. O agente acelera a geração (o bloco verde). A capacidade de tudo o resto não cresce no mesmo ritmo.

Se as mudanças chegam mais rápido do que o sistema consegue processar, crescem a fila, o trabalho não concluído e o tempo de entrega. A capacidade de revisão, QA e integração escala muito pior do que a velocidade de geração de código.

Observação 1: os MRs crescem mais rápido do que a capacidade de revisão. O agente não trata o tamanho do diff como um objetivo de engenharia em si. Pediram uma funcionalidade — receberam a funcionalidade inteira, com um refactor "de brinde" em módulos vizinhos. Em um projeto, uma tarefa simples de adicionar um campo à resposta de um serviço cresceu para várias centenas de linhas (o ticket pedia 20). A SmartBear recomenda no máximo 200 a 400 linhas por revisão, ritmo de até 500 linhas por hora, e sessões de cerca de uma hora — nessas condições, encontram-se de 70% a 90% dos defeitos.

Observação 2: a longa espera por revisão cria uma fila, não revisores lentos. O fluxo de mudanças que entra simplesmente supera a capacidade de revisão. O próprio documento do Google sobre práticas de code review estabelece um limite: a primeira resposta a um pedido de revisão deve chegar em, no máximo, um dia útil.

Enquanto o MR espera revisão, o autor não fica parado — abre o próximo, depois mais outro. Na Faros, em 2025, desenvolvedores com alto uso de IA tocaram 47% mais PRs por dia. Um exemplo real: um desenvolvedor com sete MRs abertos, nenhum fundido havia mais de uma semana.

Limitar a dois MRs abertos por pessoa por semana forçou as pessoas a ajudar os revisores — e a fila começou a diminuir mais rápido.

Observação 3: a revisão degenera em carimbo ou interrogatório. Sob a pressão do volume, surgem dois extremos: aprovar sem ler ("o agente escreveu, os testes estão verdes") ou exigir explicação para cada linha, por desconfiança do código gerado. O carimbo deixa passar erros porque não houve revisão de fato. O interrogatório também deixa passar erros, porque a atenção se gasta em detalhes menores, não na pergunta real: "estamos construindo a coisa certa?". A melhor divisão: a automação verifica formato, vulnerabilidades conhecidas e padrões típicos. A pessoa cuida da lógica e do contexto.

Observação 4: a IA aumenta a capacidade de verificação, mas não substitui a responsabilidade. A revisão automatizada já ajuda — a primeira revisão chega mais rápido, e a proporção de mudanças com falha é menor. Mas a confiança ainda é baixa: no DORA de 2025, apenas 24% expressaram alta confiança, enquanto 30% confiam pouco ou nada. Se o agente escreveu o código, revisou e a pessoa só apertou o botão de aprovar, não houve verificação independente de fato. A solução é a segmentação por risco: mudanças mecânicas vão totalmente para a automação, e as críticas (autorização, pagamentos, segurança) recebem revisão reforçada com dois revisores independentes.