Fluxo de Revisão de Código Multiagente: Dois Revisores, Um Escritor Final
Continuo encontrando a mesma limitação quando uso várias sessões de programação com AI. Na minha experiência, sessões paralelas encontram caminhos de código diferentes, mas suas discordâncias ficam presas em threads separadas. Eu me torno o barramento de mensagens, copiando uma revisão para outra sessão e decidindo qual modelo entendeu o arquivo.
O design melhor é um fluxo de revisão de código multiagente com três funções distintas. Duas sessões de AI inspecionam a mesma revisão do arquivo de forma independente. Elas trocam descobertas e questionam as evidências umas das outras. Uma terceira sessão recebe o registro da decisão, escreve um patch e executa as verificações.
Trate o arquivo como uma entrada compartilhada e imutável durante a revisão. Conceda acesso de escrita a uma única sessão quando a revisão chegar a um consenso.
Isso difere do meu loop híbrido de revisão de código com AI→ atual, no qual um modelo escreve e um segundo modelo revisa cada correção. Esse loop já dá ao revisor uma independência útil. O próximo experimento adia a escrita: as duas primeiras sessões revisam, e uma terceira sessão só começa a programar depois que a discordância entre elas produzir um registro de decisão.
Esse padrão já está próximo do que as ferramentas atuais de agentes oferecem. A documentação de subagentes do Codex da OpenAI recomenda agentes paralelos para exploração com muita leitura, testes, triagem e revisão, enquanto alerta que fluxos de trabalho paralelos com muita escrita criam conflitos e sobrecarga de coordenação. O elemento que falta é uma camada de discussão e síntese de primeira classe entre os revisores e o escritor.
Por que um fluxo de revisão de código multiagente precisa de um único escritor?
A análise paralela fornece diferentes hipóteses de falha sem criar vários patches concorrentes.
Um revisor pode rastrear o comportamento e as invariantes. O outro pode procurar problemas de segurança, condições de corrida, testes ausentes ou quebras de contratos de API. Eles começam do mesmo commit SHA e da mesma tarefa, mas recebem briefings de revisão diferentes. Essa separação reduz a chance de que ambas as sessões sigam a mesma primeira ideia.
A Anthropic descreve um padrão de produção relacionado em Building effective agents: várias chamadas de modelo podem revisar código sob perspectivas diferentes, enquanto um fluxo orquestrador-trabalhador delega o trabalho e sintetiza os resultados. A Anthropic também recomenda que as equipes adicionem complexidade agentiva apenas quando ela melhorar os resultados medidos. Três sessões custam mais tokens e tempo do que uma, portanto o fluxo precisa ter uma razão para existir.
A mutação concorrente raramente é essa razão. Se dois agentes editam a mesma cópia de trabalho, o sistema precisa resolver contexto obsoleto, hunks sobrepostos e suposições parcialmente aplicadas. O Git já oferece uma primitiva mais segura: linked worktrees permitem que sessões separadas usem estados isolados de `HEAD` e do índice, compartilhando o mesmo histórico do repositório.
Os revisores podem usar worktrees para experimentos, mas somente o integrador deve ser responsável pelo patch candidato.
O que cada sessão de AI deve controlar?
| Sessão | Acesso | Saída obrigatória | Não deve fazer |
|---|---|---|---|
| --- | --- | --- | --- |
| Revisor A | Snapshot somente leitura | Riscos de comportamento, invariantes quebradas, referências a linhas, testes propostos | Editar a branch final |
| Revisor B | Snapshot somente leitura | Segurança, concorrência, casos extremos, contraexemplos | Copiar a conclusão do Revisor A sem evidências |
| Integrador | Acesso exclusivo de escrita | Patch aceito, descobertas rejeitadas com justificativas, resultados dos testes, diff final | Reescrever além do escopo acordado |
O terceiro agente não é automaticamente mais inteligente. Sua vantagem vem da responsabilidade. Ele recebe evidências delimitadas, torna explícita a resolução dos conflitos e produz um diff auditável.
Eu também manteria os revisores sem acesso à primeira análise uns dos outros. Um estudo controlado sobre debate multiagente descobriu que a pressão da maioria pode suprimir a correção independente. A comunicação antecipada pode transformar dois revisores em uma única opinião repetida. As descobertas independentes devem vir primeiro; a discussão deve começar depois que ambos tiverem registrado suas evidências iniciais.
Como os revisores devem discutir um único arquivo?
O chat livre é útil para humanos, mas um fluxo de programação precisa de um registro compacto de descobertas. Cada afirmação deve conter evidências suficientes para que o integrador possa verificá-la sem reproduzir uma cadeia privada de pensamento.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
O segundo revisor pode aceitar a descoberta, refutá-la com um argumento baseado no código alcançável ou restringir seu escopo. O registro preserva ambas as posições. A concordância, por si só, não prova a correção, e um parágrafo confiante não deve prevalecer sobre um teste reproduzível.
Os protocolos de agentes estão avançando nessa direção. O protocolo Agent2Agent do Google modela a colaboração por meio de tarefas, mensagens, estado e artefatos. Um sistema de programação local não precisa do protocolo completo para aproveitar o contrato: use mensagens tipadas, IDs estáveis, status explícito e artefatos duráveis em vez de uma transcrição não estruturada.
Minha ponte de revisão por pares com AI→ já empacota um diff, perguntas de foco e um veredito estruturado para um segundo modelo. Um fluxo de três sessões precisa da próxima camada: dois pacotes de revisão que possam referenciar, contestar e resolver os mesmos IDs de descoberta antes que o escritor os receba.
O que o escritor deve receber antes de editar?
O integrador não deve receber dois históricos longos de chat. Ele precisa de um pequeno pacote de transferência:
O escritor então relê o arquivo atual e compara sua revisão com o pacote de transferência. Uma divergência interrompe a escrita. Essa única verificação impede que uma revisão válida do arquivo de ontem se transforme em um patch quebrado contra o código de hoje.
É também nesse ponto que as permissões devem se tornar determinísticas. Já defendi permissões determinísticas para agentes de AI→ porque um prompt como “edite somente este arquivo” é mais fraco do que uma política de ferramenta que torna todos os outros caminhos somente leitura. Nesse fluxo, o modelo de permissões deve impor a separação de funções: os revisores não podem escrever, e o integrador não pode ampliar o escopo sem uma nova decisão.
O debate melhora os patches de software?
As evidências apoiam essa direção, mas não provam que toda equipe deva usar exatamente dois revisores e um escritor.
Improving Factuality and Reasoning in Language Models through Multiagent Debate mostra que várias instâncias de modelo podem propor, criticar e refinar respostas ao longo de várias rodadas, melhorando os resultados nas tarefas de raciocínio e factualidade do artigo. Esses experimentos não testaram conflitos do Git nem pull requests de produção.
Um exemplo de programação mais próximo apareceu no preprint de 2025 SWE-Debate. Seus agentes debatem rastros concorrentes de localização de falhas, consolidam um plano de correção e passam esse plano a um agente separado de geração de patches. O artigo relata 207 tarefas resolvidas de 500 no SWE-bench Verified, ou 41,4%, em comparação com 38,8% dos baselines mais fortes listados. O benchmark e a arquitetura diferem do fluxo que estou propondo, mas a separação é reveladora: análise diversificada primeiro, uma única etapa de modificação depois.
O próximo passo honesto é uma pequena avaliação controlada em pull requests reais. Compare um único agente de programação com o fluxo de três sessões em 10 a 20 bugs. Meça descobertas válidas, falsos positivos, conflitos de merge, tempo até um patch aceitável e regressões detectadas após o primeiro rascunho. Mais mensagens entre agentes não são uma métrica de sucesso.
Como o escritor produz um único patch auditável?
O integrador deve seguir um loop restrito:
Essa última revisão deve inspecionar o patch, não reiniciar o debate de design. Cada revisor responde a duas perguntas: o escritor implementou a decisão aceita e o patch introduziu um novo risco?
O aplicativo atual do Codex da OpenAI já usa threads e worktrees separados para que os agentes possam executar em paralelo sem tocar no mesmo estado local do Git, e permite que os desenvolvedores inspecionem e comentem cada diff. O anúncio do aplicativo Codex mostra que a camada de isolamento existe. Um registro compartilhado de descobertas e uma função explícita de integrador transformariam tarefas paralelas em uma sala de revisão coordenada.
Quais falhas permanecem?
Um único escritor elimina disputas de edição, não os erros do modelo.
Dois revisores podem compartilhar o mesmo ponto cego, especialmente quando usam o mesmo modelo, prompt e contexto. O integrador pode escolher o argumento mais persuasivo em vez do correto. Comentários do repositório podem conter instruções não confiáveis. Uma suíte de testes aprovada pode não detectar o comportamento do qual os usuários dependem.
O fluxo precisa de proteções:
Minha conclusão anterior após 21,54 bilhões de tokens de atividade de agentes de código→ continua válida: o sistema ao redor do modelo decide se mais inteligência se transforma em trabalho útil ou em limpeza mais rápida.
Quando vale a pena usar um fluxo de três sessões?
Use-o quando um patch errado for caro ou quando o código tiver mais de uma interpretação plausível: autenticação, permissões, pagamentos, migrações, concorrência, APIs públicas e correções de incidentes. Ele também pode ajudar quando um engenheiro sênior normalmente pediria a dois especialistas que revisassem áreas de risco diferentes.
Evite-o para formatação, arquivos gerados, renomeações simples e alterações com um oráculo de teste óbvio. A equipe multiagente da Anthropic descobriu que a complexidade de coordenação cresce rapidamente, e seu sistema de pesquisa em produção depende de delegação clara e de um agente líder que sintetiza resultados especializados. A programação precisa da mesma disciplina, com ainda menos tolerância para escritas ambíguas.
Quero que os agentes de programação debatam as evidências antes que um deles ganhe o cursor. Duas sessões devem inspecionar o mesmo arquivo, discordar publicamente e deixar um único registro de decisão. Uma terceira deve escrever o patch candidato e comprová-lo contra o repositório.
Esse candidato ainda precisa de testes, revisão do diff e uma decisão humana de lançamento. Três sessões de AI podem melhorar o caminho até o patch; elas não transformam o patch em verdade.
FAQ
Dois agentes de AI podem editar o mesmo arquivo ao mesmo tempo?
Podem, mas as escritas compartilhadas criam contexto obsoleto e edições conflitantes. Permita que ambos analisem a mesma revisão em modo somente leitura ou isole os experimentos em worktrees separados; depois, conceda a um único integrador acesso exclusivo de escrita à branch final.
Os dois revisores devem usar o mesmo modelo?
Podem, mas prompts, funções ou famílias de modelos diferentes podem reduzir pontos cegos correlacionados. A diversidade não garante a correção, portanto o fluxo ainda exige evidências e testes.
O que acontece quando os revisores discordam?
Registre ambas as posições no registro de descobertas. O integrador deve reproduzir a afirmação, executar o teste proposto ou marcar o problema como não resolvido para um humano. Votação majoritária é um substituto fraco para evidências verificáveis.
A terceira sessão de AI substitui a revisão humana de código?
Não. A terceira sessão é responsável pela síntese e pela escrita do candidato. Um humano ainda decide se o patch se encaixa no sistema mais amplo, na intenção do produto e no risco do lançamento.
Esse fluxo pode lidar com alterações em vários arquivos?
Sim. Fixe cada arquivo revisado na mesma revisão do repositório, atribua responsabilidades claras e mantenha uma única branch de integração. Os revisores podem trabalhar em worktrees isolados, enquanto o integrador continua sendo a única sessão que monta o patch final.