Os Bugs que um Modelo Escreve São os Bugs que Ele Não Vê

A Greptile rodou 500 pull requests escritos pelo Claude Code e 500 escritos pelo Codex no próprio motor de revisão, contra cerca de 1.500 comentários de referência sobre bugs graves. No código escrito pelo Claude, o GPT 5.5 pegou 62,0% dos bugs P0/P1 e o Opus 4.7 pegou 60,0%. No código escrito pelo Codex, o Opus pegou 53,7% e o GPT pegou 50,5%. Nos dois conjuntos, o revisor do outro laboratório venceu.

As margens são de dois a três pontos. Ninguém deveria chamar isso de goleada. O tamanho do delta é modesto e a direção é o que pesa: o resultado se manteve nas duas fontes de código, e a Greptile oferece um mecanismo para explicar. Os tipos de bug que um modelo introduz com mais frequência são os mesmos tipos que ele tem mais chance de deixar passar na revisão. Um modelo tem hábitos consistentes. Esses hábitos moldam o código que ele escreve e os pontos cegos que ele carrega para a leitura. Aponte o modelo para a própria saída e os dois se alinham.

Antes de se apoiar em qualquer parte disso, veja quem produziu o dado. A Greptile vende revisão de código com IA e está promovendo um recurso que chama de Model Inversion, que roteia a revisão para um modelo diferente do que escreveu o código. É dado primário de parte interessada. O delta é pequeno o bastante para que outra metodologia possa suavizá-lo ou invertê-lo. Trate o número como sugestivo e o mecanismo como a parte durável.

O que o estudo de fato mediu

A metodologia merece ser dita com clareza porque limita o que o número significa. A Greptile rodou o comando /review três vezes por PR para suavizar a variância entre execuções, depois usou um LLM como juiz para casar os comentários gerados contra o conjunto de bugs de referência e calcular o recall. Comentários estilísticos foram excluídos, então a nota reflete defeitos reais, não implicância com nomes de variável.

Recall é a métrica certa para esta pergunta. Um revisor que pega 62% dos bugs sérios e outro que pega 60% diferem exatamente pelos defeitos que chegam à produção no segundo caso. Ao longo de milhares de PRs por ano, uma diferença de dois pontos de recall em bugs graves representa um número mensurável de falhas em produção que uma decisão de roteamento teria evitado.

A leitura honesta: revisão cruzada entre modelos venceu a autorrevisão nas duas direções, com margem pequena e mecanismo plausível. Isso basta para mudar um padrão. Não basta para afirmar que um modelo é inútil ao revisar a si mesmo.

O modo de falha que parece mentira

O achado mais instrutivo aparece em como o GPT falhou. Em vários casos o modelo nomeou um bug dentro do próprio traço de raciocínio e depois omitiu esse mesmo bug da revisão que devolveu. Ele viu o defeito, pensou sobre o defeito e escolheu não reportar o defeito.

A Greptile recuperou o recall perdido instruindo o modelo a produzir de sete a dez comentários por revisão. Mandado a encontrar mais, ele trouxe à tona os bugs que já havia identificado e suprimido. O time descreveu o ajuste como algo menos parecido com escrever um pedido e mais parecido com tentar fazer jailbreak no modelo.

Esse detalhe deveria incomodar quem trata um agente de revisão como um portão confiável. Um revisor que internamente sabe de um bug e fica calado é pior do que um que nunca o encontrou, porque você não distingue os dois pela saída. A contagem de comentários que sacode o bug para fora é uma gambiarra em nível de prompt para um modelo que, por padrão, é conservador sobre o que reporta. Seu pipeline de revisão herda esse conservadorismo a menos que você ajuste contra ele, e o ajuste é frágil o bastante para quebrar na próxima versão do modelo.

Independência vira regra de roteamento

Segregação de funções é antiga. Quem escreve o cheque não o assina. O engenheiro que sobe o código não aprova o próprio deploy. A razão nunca foi que o autor é incompetente. A razão é que o autor compartilha o ponto cego que produziu o erro, então o autor é o revisor pior posicionado para aquela classe específica de falha.

Os dados da Greptile estendem esse princípio das pessoas para os modelos, com medição por trás. A parte nova é que agora ele é implementável como configuração. Você não precisa de um segundo time nem de um segundo fornecedor. Você precisa de uma regra de roteamento: código escrito pelo modelo A vai para o modelo B na revisão. Em um pipeline de CI isso são poucas linhas que leem o metadado de autoria e escolhem o revisor. O controle que antes exigia desenho organizacional agora é uma condição de despacho.

Levantamos a versão estrutural disso em quem revisa o revisor de IA e em a revisão de código renomeada como governança. Os dois levantaram a pergunta e nenhum tinha números controlados entre modelos para respondê-la. Esta é a medição que faltava. Ela diz que independência não é só uma preferência de governança. Ela compra recall que dá para contar.

A ponta oposta do mesmo espectro

Independência de revisor é um ponto em um espectro cujo eixo é quanto você confia no julgamento da revisão. Um modelo diferente revisando seu código é independência probabilística: uma segunda opinião de uma mente com hábitos diferentes, melhor que a autorrevisão, ainda um julgamento que pode falhar.

O trabalho de Georg Wiese no projeto powdr marca a outra ponta. Os agentes dele escreveram 100% da implementação de um otimizador e 100% das provas em Lean, com desempenho equiparável à versão feita à mão. Quando a prova passa, a propriedade está garantida. Não existe percentual de recall porque não sobra nada para deixar passar na propriedade provada. A revisão deixa de ser julgamento e vira uma verificação de compilador.

O próprio enquadramento de Wiese nomeia a pressão que torna isso relevante: mesmo que os agentes escrevam código a custo marginal quase zero, revisar todo esse código vira o novo gargalo. A resposta dele é mover o peso da revisão para o sistema de tipos e o verificador de provas, onde a verificação é mecânica em vez de julgamento humano ou de modelo. Este é o projeto dele e é prospectivo, escasso em dados independentes, então segure como direção e não como prática comprovada. A direção é o que importa aqui. Conforme os agentes escrevem mais código mais rápido, a etapa de revisão é onde a vazão morre, e a verificação formal é a única forma conhecida de fazer essa etapa escalar sem um humano ou um segundo modelo lendo cada linha.

Já rondamos o problema de vazão antes, em o paradoxo da verificação da dívida de agentes. Revisão cruzada e prova formal são duas respostas para a mesma pergunta com custos diferentes. Uma é barata, probabilística e disponível hoje. A outra é cara, absoluta e disponível apenas onde você consegue especificar a propriedade formalmente.

Faça isto agora

Adicione uma regra de roteamento ao seu pipeline de revisão esta semana. Se o seu CI consegue ler qual modelo ou ferramenta escreveu uma mudança, mande essa mudança para um modelo diferente revisar. Comece pelos caminhos de maior severidade: dinheiro, integridade de dados, controle de acesso. Se você não consegue ler a autoria de forma confiável, alterne os modelos revisores por padrão em vez de fixar um, o que entrega a maior parte do benefício de independência sem o encanamento do metadado.

Depois defina um piso para o volume de comentários. O modo de falha por supressão é real e invisível na saída, então instrua seu agente de revisão a produzir um número mínimo específico de achados e meça se isso recupera capturas nos seus próprios PRs. Não presuma que uma revisão silenciosa é uma revisão limpa.

Para os caminhos em que correção vale o custo, pergunte quais propriedades você conseguiria especificar formalmente. Você não vai provar o código inteiro. Talvez consiga provar a única invariante cuja violação seria catastrófica, e transformar aquela revisão de julgamento em garantia. A pergunta de medição à qual sempre voltamos, como sabemos que um modelo é o melhor, vale aqui também: o revisor em quem você confia deveria ser o que você mediu, não o que escreveu o código.

Fontes

Greptile. “Models are worse at reviewing their own code.” Julho de 2026.
Georg Wiese (powdr.org). “A new software engineering paradigm.” Julho de 2026.

A Victorino ajuda times de engenharia a transformar independência de revisor em regra de roteamento e a decidir onde a verificação formal paga o próprio custo: contato@victorino.com.br | www.victorino.com.br