IA escreve, IA revisa: independência precisa ser demonstrada

Agentes já ocupam os dois lados do pull request. Um produz a mudança; outro comenta, classifica ou recomenda. O fluxo pode reduzir latência e ampliar cobertura. Ele também pode fabricar uma aparência de revisão quando autoria, crítica, verificação e autoridade continuam presas ao mesmo circuito.

Este Evidence Brief parte do paper AI-to-AI Code Reviews of GitHub Pull Requests para definir um contrato técnico de segregação de autoridade. Não afirma que revisão IA-para-IA é ruim, nem que produto diferente prova independência.

O que foi observado

Os autores usaram eventos públicos do GitHub entre 01/01/2024 e 15/04/2026 e assinaturas atribuíveis a agentes. Entre 2.830.284 PRs identificados como agent-authored, 248.641 receberam pelo menos uma revisão atribuída a IA — 8,8% da população atribuível.

• 45.269 receberam revisão cross-product;
• 208.145 receberam revisão same-product;
• 4.773 apareceram nas duas categorias;
• cross-product representou aproximadamente 1,6% dos 2,83 milhões de PRs atribuídos a agentes.

O pacote de replicação publica scripts, coortes filtradas, registro de assinaturas, tabelas e figuras. Isso melhora reprodutibilidade, mas continua sendo material dos mesmos autores, não uma replicação independente.

Closed-loop não é no-human-loop

No paper, closed-loop significa apenas que IA aparece nos dois lados observados do PR. O dataset não permite determinar se uma pessoa também revisou, testou ou aprovou. A ausência de evento humano no recorte não prova ausência de julgamento humano.

As contagens também são limites inferiores: assinaturas ausentes ou removidas causam subatribuição. Repositórios privados, GitHub Enterprise, outras plataformas e agentes não reconhecidos ficam fora.

Quatro coisas que o estudo não mediu

1. qualidade ou correção do código;
2. qualidade, severidade ou groundedness dos comentários;
3. efeito causal de same-product versus cross-product;
4. presença ou ausência de revisão humana.

Diferenças de volume e latência podem refletir tamanho do PR, linguagem, repositório, integração, configuração e composição dos revisores. Mais comentários são atividade; não são evidência automática de defeitos encontrados ou risco reduzido.

Produto diferente não é autoridade independente

Independência exige separar ao menos cinco planos:

Trocar a marca do revisor pode diversificar contexto, mas produtos diferentes podem compartilhar modelo, dependências, incentivos ou permissões. O mesmo produto também pode chamar verificadores realmente distintos. A unidade de independência é a autoridade e o mecanismo, não o logo.

Papéis distintos ajudam a criar contraponto, desde que o sistema preserve quem executa, quem verifica e quem aceita. [R1-C3]

Gate de pull request para fluxos com agentes

1. Identidade e provenance do diff

Registre agente/produto quando atribuível, executor humano, spec, commit-base, arquivos alterados, dependências, ferramentas e limitações. Provenance incompleta deve continuar unknown, nunca virar “humano” por exclusão.

2. Review como sinal, não autoridade

O comentário do agente entra como finding com regra explícita de severidade, deduplicação, resolução e falso positivo. Aprovação de merge continua vinculada a uma autoridade autorizada.

3. Ownership por risco

Use CODEOWNERS ou mecanismo equivalente para identidade, autorização, pagamentos, migrações, infraestrutura e dados. Um owner precisa revisar a propriedade sob sua responsabilidade, não apenas confirmar que o bot comentou.

4. Verificadores protegidos

Exija checks de lint, tipos, testes, segurança, dependências, testes negativos, contrato, migração, rollback e evals conforme o risco. Um agente pode acionar e interpretar checks; não deve poder reescrever silenciosamente a política que decide o merge.

Mudanças pequenas e isoladas aumentam revisabilidade, mas workspace separado não é sandbox nem garantia de segurança. [R1-C2]

5. Último push sob nova aprovação

A proteção de branches do GitHub pode invalidar aprovação depois de novo commit ou exigir aprovação do último push por outra pessoa. Sem isso, uma mudança posterior pode entrar apoiada em uma revisão de diff antigo.

6. Merge e bypass explícitos

Restrinja quem pode fazer push, merge, dispensar review ou alterar checks. Exceção precisa de motivo, autoridade, validade e trilha — especialmente quando quem gerou a mudança também controla o bypass.

7. Source e build ligados ao release

SLSA 1.2 define provenance como informação verificável sobre de onde veio um artefato e onde, quando e como foi produzido. Preserve commit, inputs, builder, digest e receipt de promoção para provar que o que foi revisado é o que opera.

Permissões e gates precisam existir fora do modelo e ser testados no sistema de entrega. [HARNESS31-C2]

Matriz de autoridade proporcional ao risco

A tabela é análise profissional do autor, não resultado do paper. O objetivo é calibrar autoridade, não impor uma topologia universal.

Evidence Packet do merge

Um merge governável deve permitir reconstruir:

• qual decisão e spec iniciaram a mudança;
• quem ou qual agente produziu e revisou;
• qual diff exato foi avaliado;
• quais findings foram aceitos, corrigidos ou dispensados;
• quais checks rodaram, em qual commit e com qual resultado;
• quem aprovou o risco residual;
• qual artefato por digest foi promovido;
• qual smoke test, monitoramento e rollback sustentam a operação.

Se a resposta existe apenas no resumo do agente, a organização tem uma narrativa — não uma evidência.

O que este brief prova — e o que não prova

O estudo prova que eventos atribuídos a agentes nos dois lados do PR já são numerosos em projetos públicos e que as combinações exibem padrões distintos. Não prova que same-product é complacente, que cross-product é independente, que bots substituíram humanos ou que o código resultante tem mais ou menos qualidade.

Os controles deste brief derivam do paper, da documentação oficial e da experiência profissional do autor. São uma proposta de governança técnica, não um achado causal dos pesquisadores.

Fontes diretas

• Paper — AI-to-AI Code Reviews of GitHub Pull Requests
• Pacote de replicação
• CodAGE — dataset-base
• GitHub — pull request reviews
• GitHub — protected branches
• GitHub — CODEOWNERS
• NIST SP 800-218 — Secure Software Development Framework
• SLSA 1.2 — provenance

Conclusão

IA pode escrever e revisar no mesmo fluxo. O que ela não pode fazer sozinha é criar legitimidade para a própria aprovação.

Independência precisa aparecer em autoridades separadas, propriedades verificadas, checks protegidos, provenance e uma pessoa accountable pelo merge e pela operação.