A Faros AI já mediu a revisão de código na era da IA duas vezes. No conjunto de dados de 2025, o tempo de revisão de PR nas equipes com alta adoção de IA estava 91% maior. No conjunto de 2026, o tempo mediano em revisão de PR subiu 441,5%, o tempo médio em revisão subiu 199,6%, e o tempo mediano até a primeira revisão subiu 156,6%. A Faros faz questão de dizer que os dois estudos são recortes independentes do mercado e não um painel longitudinal, então o par mostra consistência de direção e não uma tendência ano a ano. A direção é o que importa aqui.
Duas ressalvas antes que alguém construa um plano sobre esses números. A Faros compara trimestres de baixa adoção de IA com trimestres de alta adoção dentro da mesma empresa, o que é um desenho correlacional e não causal. A Faros também vende ferramentas de inteligência de engenharia e concorre com o nosso próprio produto, o Releezy. As amostras são diferentes: o relatório de 2026 usa dois anos de telemetria, 22 mil desenvolvedores e mais de 4 mil equipes, enquanto o de 2025 cobre mais de 10 mil desenvolvedores em 1.255 equipes.
A pergunta que interessa é o que um líder faz com uma fila de revisão que cresceu assim. As respostas disponíveis são respostas de processo. Colocar mais revisores. Apertar o checklist. Botar um revisor de IA na frente do revisor humano. Nenhuma delas mexe na quantidade que realmente define a capacidade de revisão.
A Autoria Escalou. O Julgamento Não.
A Faros descreveu o lado da vazão em 2025 sem rodeios: “Developers on teams with high AI adoption complete 21% more tasks and merge 98% more pull requests.” Em tradução livre, equipes com alta adoção de IA concluem 21% mais tarefas e fazem merge de 98% mais pull requests. Naquele recorte de 2025, equipes com alta adoção fizeram merge de aproximadamente o dobro de pull requests das equipes com baixa adoção. O recorte de 2026 é onde fica interessante: a taxa de merge de PR por desenvolvedor subiu apenas 16,2%. A Faros descarta o cansaço das ferramentas como explicação e aponta a restrição, escrevendo que “the code quality is creating a review bottleneck that is throttling throughput”, ou seja, a qualidade do código está criando um gargalo de revisão que estrangula a vazão, e que as organizações “are generating more code than the system can review and merge”, geram mais código do que o sistema consegue revisar e mergear. A capacidade de julgá-los não acompanhou, e o meu argumento para isso é que julgar uma mudança é um ato de reconstrução.
Um revisor aprova uma mudança reconstruindo mentalmente parte suficiente do sistema para prever o que aquela mudança vai fazer em produção. Essa reconstrução tem custo, e o custo é pago por mudança, por quem carrega a responsabilidade. Escrever código ficou mais barato. Reconstruir o sistema na cabeça continua custando o mesmo.
A Quantidade Que Define o Orçamento
O contexto que uma revisão exige vem da mudança, e o revisor apenas paga a conta. A pegada de contexto de uma mudança é determinada pela forma como o sistema foi dividido.
Uma mudança contida dentro de um módulo com fronteira clara pode ser julgada contra o contrato daquele módulo. O revisor lê o diff, lê o contrato, e sabe qual é o raio de impacto porque a fronteira o define. Uma mudança que cruza quatro fronteiras obriga o revisor a segurar quatro contratos mais as interações entre eles, e é nas interações que moram os defeitos. Se uma mudança toca seis módulos em vez de um, nenhuma senioridade de revisor torna o sexto módulo gratuito.
É por isso que espero que intervenções de processo rendam menos do que o esperado nesse problema. Um checklist diz ao revisor o que procurar dentro de um contexto que ele ainda precisa montar sozinho. Um segundo revisor duplica a reconstrução. Um primeiro passe de IA muda quem monta o contexto, e já volto ao motivo pelo qual isso ajuda menos do que parece.
A arquitetura é a única variável do sistema que altera a quantidade em si. Já argumentamos que fronteiras são o que torna agentes confiáveis. As mesmas fronteiras decidem se a saída de um agente é revisável.
Como a Sobrecarga Aparece na Telemetria
A Faros relata em 2026 que o número diário de contextos de PR por desenvolvedor subiu 67,4%, contra +46% no conjunto anterior. Tarefas tocadas por dia subiram 17,7%. Reinícios de trabalho subiram 13,8%. E 26% mais tarefas em andamento ficam sete dias ou mais sem PR e sem atividade.
Eu leio esses números como pessoas alternando entre mais linhas de trabalho abertas do que conseguem segurar. A Faros mede as contagens, não o limite, então a interpretação é minha.
O churn de código, medido como linhas deletadas contra linhas adicionadas por trimestre em código já mergeado, subiu 861%. A Faros descreve isso como 9,6 vezes a taxa anterior. Churn em código mergeado significa que o trabalho passou pela revisão e foi arrancado depois. Incidentes por PR subiram 242,7%.
A Faros nomeia um outro mecanismo, uma camada acima da arquitetura: “the code arriving for review is often not review-ready. Reviewers are not just assessing more code, they appear to be working harder to bring that code up to a standard it should have met before the PR was opened.” O código que chega para revisão frequentemente não está pronto para ser revisado, e os revisores estão trabalhando para elevá-lo a um padrão que ele deveria ter antes da abertura do PR.
A Métrica da Capitulação
PRs mergeados sem nenhuma revisão subiram 31,3%. A Faros chama isso de “the most urgent finding in this section”, o achado mais urgente daquela seção.
Isso é um sinal de capacidade. Quando o custo de reconstruir o contexto de uma mudança passa do que o revisor tem para gastar, a revisão não piora de forma gradual e mensurável. Ela deixa de acontecer. Ninguém anuncia a decisão. Ela só aparece onde alguém já conta merges sem revisão.
Já escrevemos sobre o que acontece quando uma equipe tenta substituir essa revisão perdida por camadas de política: na maior parte dos casos, é governança renomeada. E o problema mais fundo por trás do número de churn é que o sinal da revisão se descolou do resultado em produção, que é o paradoxo de verificação do código escrito por agentes.
Revisores de IA Estão Presos ao Mesmo Limite
O argumento a favor da revisão por IA assume que uma máquina tem paciência praticamente ilimitada para contexto. Ela tem uma janela de contexto, e o argumento é que um sistema acoplado enche essa janela com código que a mudança nem tocou.
A Faros descreve exatamente por que essa saída é cara de julgar: “It is often superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase… The structural and logical failures, when they exist, are beneath the surface. Catching them requires the reviewer to read carefully, reason about intent, and reconstruct the problem the code was meant to solve.” O código é superficialmente convincente, idiomático e consistente com o estilo ao redor, enquanto as falhas estruturais e lógicas ficam abaixo da superfície e exigem que o revisor reconstrua o problema que o código deveria resolver.
A CodeRabbit, que vende revisão de código com IA e portanto tem interesse direto nesse achado, relatou em dezembro de 2025 a análise de 470 pull requests de código aberto no GitHub, sendo 320 com coautoria de IA e 150 escritos apenas por humanos. As mudanças com coautoria de IA carregaram 10,83 problemas por PR contra 6,45 nas humanas, aproximadamente 1,7 vezes mais pela minha conta. A CodeRabbit relata que “Logic and correctness issues were 75% more common in AI PRs”, problemas de lógica e correção foram 75% mais comuns nos PRs com IA.
Lógica e correção são justamente a classe de defeito que exige que o revisor segure o sistema ao redor. Estilo e nomenclatura são locais. Correção é relacional, e relações cruzam fronteiras. O canal The Serious CTO fez esse argumento em abril de 2026 com o enquadramento mais afiado que vi: se os serviços estão fortemente acoplados, os agentes enchem suas janelas de contexto com código não relacionado, e os revisores acabam avaliando mudanças que tocam tudo ao mesmo tempo. A modificabilidade é a propriedade que importa, e mudança localizada com fronteiras fortes é o que mantém pequeno o contexto revisável.
Trocar um revisor humano por um agente transfere a reconstrução para um sistema com janela de contexto limitada e sem responsabilidade sobre o resultado. Se a arquitetura força um contexto grande, minha expectativa é que o revisor de IA falhe como o humano falha, e de forma mais silenciosa.
Faça Isso Agora
Instrumente um número e trate-o como métrica de arquitetura: quantos módulos com fronteira clara a mudança média mergeada toca. O histórico do seu repositório tem a matéria-prima: mapeie as fronteiras dos seus módulos uma vez, depois conte quantas uma mudança mergeada cruza. Calcule por PR e plote a tendência dos últimos quatro trimestres. Depois estabeleça um teto.
Quando uma mudança ultrapassa o teto, a resposta correta é recusar o formato daquela mudança ou corrigir a fronteira que a forçou. Quando a média sobe trimestre após trimestre, você tem um defeito de arquitetura, e toda intervenção de processo que financiar contra ele vai render menos do que o esperado.
Isso é falsificável, e essa é a intenção. Se a sua equipe limitar o número de módulos que uma mudança pode tocar, sustentar o limite por dois trimestres, e o tempo de revisão e os defeitos escapados não caírem, a tese aqui está errada para o seu código. Se você acrescentar revisores e checklists e as duas métricas continuarem subindo, é isso que este argumento prevê. A Faros mediu a fila, não o que acontece quando se tenta resolvê-la com mais gente. Já argumentamos que otimizar apenas a etapa de codificação cria filas mais adiante, e que a revisão sempre fez mais do que detectar defeitos, que é um argumento separado e que vale a leitura. Nenhum dos dois muda a aritmética acima.
Cada fronteira que você corrige reduz o contexto que a próxima revisão vai exigir.
Fontes
- Faros AI. “AI Engineering Report 2026: The Acceleration Whiplash.” Março de 2026.
- Faros AI. “The AI Productivity Paradox Research Report.” 2025.
- CodeRabbit. “State of AI vs Human Code Generation Report.” Dezembro de 2025.
- The Serious CTO. “AI Killed Code Review (Here’s the Proof).” Abril de 2026.
A Victorino ajuda times de engenharia a encontrar as fronteiras que tornam suas mudanças revisáveis de novo: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa