Revisão de Código Nunca Foi Sobre Defeitos. Por Isso Automatizá-la Custa Tão Caro

Alberto Bacchelli e Christian Bird sentaram ao lado de desenvolvedores da Microsoft, observaram revisões de código e contaram sobre o que os comentários realmente falavam. Comentários relacionados a defeitos eram apenas 14% dos comentários de revisão. O resultado foi publicado na ICSE em 2013 e vem sendo ignorado desde então, porque os outros 86% são difíceis de nomear e impossíveis de colocar em um painel.

Brian Houck, pesquisador da Microsoft escrevendo na newsletter Engineering Enablement da DX, resgata esse número no momento exato em que ele importa. Todo produto de revisão automatizada no mercado é vendido por detecção de defeitos. Detecção de defeitos era a menor parte do que os revisores faziam.

O que Havia nos Outros 86%

No mesmo estudo, mais da metade dos desenvolvedores disse usar as revisões para explorar soluções alternativas. Não para aprovar ou rejeitar uma implementação, mas para descobrir se existia outra. O restante do volume de comentários é o trabalho comum de uma organização se mantendo a par de si mesma: quem é dono deste subsistema agora, por que aquela abstração foi escolhida dois anos atrás, qual convenção este time de fato segue quando o guia de estilo silencia, se quem escreveu isso entendeu a restrição contra a qual estava escrevendo.

A formulação de Houck é a mais limpa que já vi: “O resultado visível da revisão de código é código melhor. O resultado invisível é uma organização de engenharia melhor.”

A assimetria entre esses dois resultados é o problema inteiro. O visível tem uma métrica de aproximação que uma ferramenta consegue escalar. O invisível não tem métrica alguma, então, quando degrada, nada fica vermelho. Um time pode perder o modelo compartilhado do próprio sistema ao longo de dezoito meses, e o único sintoma será um onboarding mais lento e estimativas piores, coisas que ninguém vai atribuir à automação da revisão.

Já argumentamos que entendimento perdido é um custo real e invisível. O número de 14% dá um denominador a esse argumento.

A Meta Mediu a Amplificação

A pressão por automatizar tem origem aritmética, e a Meta publicou a aritmética.

No último ano, segundo um artigo da Meta (arXiv 2605.30208) citado por Houck, as linhas de código significativas por diff aterrissado por humano aumentaram 106%. Diffs por desenvolvedor por mês subiram 51%. Mais de 80% desse crescimento veio de IA agêntica. Ou seja, os mesmos revisores agora olham cerca de duas vezes mais código substantivo por mudança, em uma vez e meia mais mudanças.

A fila reagiu como filas reagem. Houck relata que o percentual de diffs revisados em até 24 horas está caindo e que, em alguns grupos grandes, os revisores encaram milhares de revisões pendentes. A análise da própria DX encontrou crescimento de 64% no tamanho mediano dos pull requests.

Os revisores já eram a restrição antes disso tudo. Um estudo da Microsoft com 911 desenvolvedores apurou que apenas 26% deles diziam sempre escrever uma descrição detalhada do código submetido à revisão, e que os três principais desafios eram feedback em tempo hábil, tamanho da revisão e entender a motivação de uma mudança. Outro estudo da Microsoft apurou que os desenvolvedores idealmente querem gastar cerca de 7% do tempo revisando código. A IA agêntica não inventou o gargalo. Ela dobrou a carga sobre um processo que já operava além da capacidade declarada, tocado por pessoas que queriam lhe dar um quatorze avos da semana.

O RADAR Muda o Verbo

A resposta da Meta merece leitura cuidadosa, porque não é o produto que a maioria dos fornecedores vende.

RADAR significa Risk Aware Diff Auto Review. Os resultados relatados são fortes: mais de 535 mil diffs revisados, mais de 331 mil aterrissados, uma taxa de revert de aproximadamente um terço da observada em diffs sem RADAR, uma taxa de incidentes em produção cinquenta vezes menor e um tempo mediano até o fechamento 3,3x mais rápido, redução de cerca de 70%.

O mecanismo por trás desses números é elegibilidade, e não qualidade de revisão. O trabalho do RADAR é decidir quais diffs têm risco baixo o bastante para aprovação automática, o que significa que a atenção humana liberada se concentra nos diffs que nunca foram elegíveis. A taxa de revert é um terço da linha de base em parte porque a população tratada pelo RADAR foi selecionada por ser segura. Isso é uma virtude do desenho, e é também a razão pela qual o número não pode ser retirado do contexto e usado como afirmação geral sobre IA revisando código.

Duas ressalvas cabem aqui. Primeiro, Houck cita pesquisa da própria instituição enquanto publica na newsletter da DX, e a DX vende medição de produtividade de desenvolvimento, então o enquadramento que chega junto com esses números não é desinteressado. Segundo, um comentário na publicação circula um percentual que não aparece no corpo publicado, provavelmente vindo de uma versão editada antes. Número que só existe em comentário não deveria viajar.

A Degradação Chega Uma Decisão Razoável por Vez

O modo de falha aqui é procedimental, e Houck o descreve com precisão: a degradação chega “por meio de uma série de decisões individualmente razoáveis: essa mudança é de baixo risco, essa revisão pode ser automatizada, essa aprovação pode ser pulada”.

Ninguém decide parar de entender o sistema. Cada passo é defensável isoladamente e o efeito acumulado é invisível porque aquilo que se perde nunca foi medido. É o que separa esse caso da troca usual entre qualidade e velocidade, em que ao menos um dos lados aparece em algum painel.

Um desenvolvedor anônimo na pesquisa “AI Where It Matters”, da Microsoft, localizou a fronteira em uma frase: “Não consigo delegar totalmente a revisão final de código para a IA. Minha aprovação coloca meu nome nela.” Responsabilidade não se delega. Qualquer que seja a conclusão da ferramenta, um nome vai no merge, e esse nome pertence a alguém de quem se espera a capacidade de explicar a mudança seis meses depois.

Já escrevemos que remover a revisão renomeia a governança em vez de eliminá-la. O número de 14% acrescenta uma segunda perda a essa conta: a compreensão que a organização tem do sistema que ela mesma opera.

Faça Isto Agora: Estratifique Antes de Automatizar

A resposta de desenho disponível na evidência é estratificação de risco com elegibilidade conservadora. Em termos concretos, nas próximas duas semanas:

Escreva sua regra de elegibilidade antes de comprar qualquer coisa. Quais classes de mudança podem receber aprovação automática? Configuração em ambiente fora de produção, atualização de dependência dentro de um major fixado, código gerado por gerador determinístico, adição apenas de testes. Se a sua regra for “o revisor de IA disse que está bom”, você não tem regra de elegibilidade. Tem o padrão de um fornecedor.

Torne o conjunto inelegível explícito e maior do que parece confortável. Caminhos de autenticação, caminhos de dinheiro, exclusão de dados, migrações de schema, qualquer coisa que toque um sistema cuja última pessoa que o entendia já saiu. Os números de incidente do RADAR vêm do conservadorismo do corte, não da esperteza do modelo.

Instrumente o resultado invisível. Escolha dois sinais de compreensão organizacional e acompanhe mensalmente: tempo para um engenheiro novo aterrissar uma mudança em determinado subsistema, e a contagem de subsistemas que têm exatamente uma pessoa capaz de explicá-los. Se os dois piorarem por dois trimestres enquanto a cobertura da automação de revisão sobe, os 86% são o que você trocou.

Mantenha um humano no merge de tudo que for inelegível, e faça do nome do revisor o nome responsável. Não como cerimônia. Como o mecanismo que mantém ao menos uma pessoa obrigada a entender a mudança.

Automatizar detecção de defeitos compra os 14%. Decidir qual código um humano ainda precisa ler é o que protege o resto.

---

Fontes

• DX / Engineering Enablement. “What are code reviews even for?.” Agosto de 2026.

A Victorino ajuda organizações de engenharia a desenhar regras de elegibilidade de revisão que mantêm a entrega acelerada por IA dentro de uma fronteira governada de responsabilidade: contato@victorino.com.br | www.victorino.com.br