Por que mais agentes revisando código não melhora o resultado
2 de novembro de 2026
O número de agentes não é o que mais importa na revisão de código com IA. O que importa é o formato da conversa entre eles: num estudo com 105 problemas de programação, um arranjo de três agentes acertou 87% e um de cinco, 82%. E concordância entre dois agentes só vira evidência quando alguém discordou com prova.
Para revisar o trabalho de um agente de IA, você já chegou a pensar que quanto mais revisores você colocar, melhor vai sair o resultado? Veja este estudo.
Os pesquisadores pegaram 105 problemas de programação e foram testando o número de revisores em cima deles. Sem revisão nenhuma, o agente principal acerta 77%. Depois colocaram um revisor: 77% de novo, nada mudou. Com dois revisores independentes, a taxa de acerto caiu para 75%. Quase o mesmo que não revisar. Então testaram um arranjo de cinco agentes (o que escreve, três revisores e um chefe que junta tudo) e o acerto subiu para 82%. Por fim, chegaram a 87% com um arranjo mais enxuto, de três agentes no total. Três batendo cinco.
O que esse estudo diz é que o número de agentes não é o que mais importa. O que importa é o formato da conversa entre eles. O arranjo enxuto de três agentes funcionou assim: o primeiro escreve, o segundo propõe a revisão e o terceiro revisa a proposta de revisão. Fica tudo congelado enquanto os dois revisores discutem. Só quando eles chegam a um entendimento é que o agente principal recebe a ordem de editar.
Isso valeu para escrever código. Depois, eles pegaram só a dupla revisor e crítico e testaram em outra tarefa: revisar pull requests do GitHub. O resultado: aquele arranjo ficou em último lugar. Foram atrás do motivo e acharam duas falhas. Na primeira, o revisor levanta um bug real e umas três suspeitas frouxas; o crítico concorda com tudo e ainda inventa mais uma. Na segunda, ao contrário: o crítico acha um bug de verdade e o revisor rebate com um argumento confiante que não cita uma linha de código sequer. O crítico cede e o bug some da revisão. É o "falso consenso". O perigo é que ele parece uma validação independente: dois agentes concordaram, então parece confirmado. Só que o que fez os dois concordarem foi a exigência de consenso: havia uma certa "pressão para convergirem". Ninguém era obrigado a provar na hora de discordar, só a chegar a um acordo. E concordar é o caminho mais curto para o acordo. O conserto não foi colocar mais agentes. Foi mudar o texto do prompt. Antes, o crítico tinha dois botões: concordo e discordo. Depois passou a ter três: "concordo"; "discordo e aqui está a prova"; ou "discordo, mas não tenho prova". No terceiro caso, quem apontou o bug é que tem de ir ao código provar ou derrubar o próprio apontamento.
O que resume tudo é o seguinte. Não coloque dois revisores em paralelo achando que dobrou a revisão. Coloque um revisor e um crítico que pega a revisão e vai ao código conferir se ela se sustenta. Obrigue quem apontou o bug a provar com a linha do código quando o outro discorda. Senão, os dois viram amiguinhos e concordam com qualquer coisa, inclusive em enterrar um bug real. E ligue isso só onde errar sai caro, porque custa quase cinco vezes mais tokens.
Se o estudo coubesse numa frase só, seria esta: concordância entre dois agentes não é evidência. Só vira evidência quando alguém discordou e a prova teve de aparecer no código.
Fontes
Verificada em 2 de novembro de 2026.
- O estudo. Qiu e Gill, Adversarial Review: Structured Disagreement for Grounded Agentic Code Review, 16 de agosto de 2026.Artigo (arXiv)