A revisão de código sempre foi mais do que procurar erros de sintaxe. Ela distribui conhecimento, questiona decisões, protege áreas sensíveis e cria uma autoridade explícita antes do merge. Quando agentes passam a escrever e também a revisar pull requests, essa função não desaparece — mas o sinal de ‘revisado’ deixa de dizer sozinho quem julgou, o que foi verificado e quem aceitou o risco.
O que o estudo encontrou
O paper de Selvanayagam e Ghaleb [1] analisou eventos públicos do GitHub entre 1º de janeiro de 2024 e 15 de abril de 2026. Por assinaturas em corpos de PRs e contas controladas por fornecedores, os autores identificaram 2.830.284 pull requests atribuídos a agentes. Desses, 248.641 — 8,8% da população atribuível — receberam ao menos uma revisão também atribuída a IA.
- 45.269 PRs receberam revisão cross-product, quando autoria e revisão foram atribuídas a produtos diferentes.
- 208.145 receberam revisão same-product, quando o produto atribuído era o mesmo nos dois lados.
- 4.773 apareceram nos dois grupos; por isso, as duas contagens não devem ser somadas como populações exclusivas.
- A revisão cross-product correspondeu a aproximadamente 1,6% dos 2,83 milhões de PRs atribuídos a agentes — não a 1,6% apenas do grupo revisado por IA.
Closed-loop não significa ‘sem humanos’
O próprio paper [1] limita o termo: closed-loop descreve IA nos dois lados observáveis do PR. O conjunto de dados não permite saber se uma pessoa também revisou, testou, discutiu ou aprovou aquela mudança. Dizer que 248 mil PRs foram entregues sem intervenção humana seria transformar ausência de observação em evidência de ausência.
Também não é um retrato de todo o desenvolvimento de software. A amostra exclui repositórios privados, GitHub Enterprise, outras plataformas e agentes sem assinatura reconhecida. As contagens são limites inferiores dentro de uma população atribuível, não censo universal.
Mais comentários não significam revisão melhor
O estudo encontrou diferenças de categorias, volume e latência entre combinações de autor e revisor. Os efeitos sobre volume foram pequenos ou desprezíveis, concentrados na cauda, e podem refletir tamanho da mudança, linguagem, repositório, configuração ou composição dos revisores. Os autores não mediram correção, severidade, qualidade do código ou efeito causal.
Produto diferente não é sinônimo de independência
Separar ferramenta de autoria e revisão pode aumentar diversidade de implementação e contexto, mas não prova independência. Produtos diferentes podem compartilhar modelo, dados, configuração, incentivos ou a mesma autoridade de merge. E o mesmo produto pode executar verificadores distintos. Independência real depende de propósito, contexto, permissões, mecanismo e autoridade — não apenas da marca exibida no comentário.
Sete camadas para não confundir revisão com aceite
- Proveniência: registrar quem ou qual agente propôs a mudança, modelo ou produto quando disponível, contexto, commit e ferramentas usadas.
- Escopo: manter diffs pequenos, requisitos explícitos e áreas sensíveis sob ownership conhecido.
- Revisão: usar agentes como sinal adicional, preservando CODEOWNERS e aprovação exigida para código crítico.
- Verificação: exigir lint, tipos, testes, segurança, testes negativos, migração, rollback e evals conforme o risco.
- Autoridade: proteger a branch, impedir bypass indevido e exigir aprovação do último conjunto de mudanças por outra autoridade.
- Promoção: vincular o artefato ao código e ao build por provenance, digest e receipt de deploy.
- Operação: monitorar comportamento, incidentes, regressões e condição de retirada depois do merge.
A documentação do GitHub [4][5] permite exigir reviews, CODEOWNERS, checks e aprovação posterior ao último push. O NIST SSDF [6] trata segurança como parte do ciclo de desenvolvimento, enquanto SLSA 1.2 [7] organiza provenance verificável de source e build. Esses mecanismos não garantem software correto; tornam explícito o que foi exigido, executado e autorizado.
Perguntas para diretoria, CTO e engenharia
- Sabemos quais mudanças foram produzidas ou revisadas por agentes — e para que usamos essa informação?
- Qual propriedade cada bot verifica e qual decisão seu resultado pode bloquear ou liberar?
- Áreas de identidade, autorização, dados, pagamentos e infraestrutura exigem revisão especializada?
- Quem pode fazer merge, dispensar review, alterar checks ou promover um artefato?
- Uma alteração posterior invalida aprovações anteriores e obriga nova verificação?
- Conseguimos reconstruir spec, diff, resultados, exceções, aprovação e deploy de uma release?
- Quem responde quando todos os checks passam, mas o comportamento em produção causa dano?
O valor do profissional migra de digitar para julgar sistemas
Quanto mais agentes ocupam o fluxo, mais valiosos se tornam arquitetura, decomposição, threat modeling, desenho de testes, observabilidade e julgamento de trade-offs. O profissional experiente não compete com o bot por volume de comentários. Ele define quais comentários importam, identifica o que não foi testado e assume a responsabilidade que uma ferramenta não pode assumir.