IA escribe, IA revisa: independencia precisa ser demostrada

Agentes ya ocupan los dos lados del pull request. Uno produce el cambio; otro comenta, clasifica o recomienda. El flujo puede reducir la latencia y ampliar la cobertura. También puede fabricar una apariencia de revisión cuando autoría, crítica, verificación y autoridad continúan presas al mismo circuito.

Este Evidence Brief parte del paper AI-to-AI Code Reviews of GitHub Pull Requests para definir un contrato técnico de segregación de autoridad. No afirma que una revisión IA-para-IA es mala, ni que un producto diferente prueba independencia.

Qué se ha observado

Los autores usaron eventos públicos de GitHub entre 01/01/2024 y 15/04/2026 y firmas atribuibles a agentes. Entre 2.830.284 PRs identificados como agent-authored, 248.641 recibieron al menos una revisión atribuible de la IA - 8,8% de la población atribuible.

• 45.269 recibieron revisión cross-product;
• 208.145 recibieron revisión same-product;
• 4.773 aparecieron en las dos categorías;
• cross-product representó aproximadamente el 1,6% de los 2,83 millones de PR asignados a agentes.

O paquete de replicación publica scripts, cohortes filtrados, registro de firmas, tablas y figuras. Esto mejora reproductibilidad, pero sigue siendo material de los mismos autores, no una replicación independiente.

Closed-loop no es en humanos-loop

En el paper, closed-loop significa sólo que IA aparece en los dos lados observados del PR. La fechaet no permite determinar si una persona también revisó, probó o aprobó. La ausencia de evento humano en el recorte no prueba ausencia de juicio humano.

Los recuentos también son límites inferiores: firmas ausentes o eliminadas causan subatribución. Repositorios privados, GitHub Enterprise, otras plataformas y agentes no reconocidos quedan fuera.

Cuatro cosas que el estudio no medió

1. calidad o corrección del código;
2. calidad, severidad o groundedness de los comentarios;
3. efecto causal de same-product versus cross-product;
4. presencia o ausencia de revisión humana.

Diferencias de volumen y latencia pueden reflejar tamaño del PR, lenguaje, repositorio, integración, configuración y composición de los revisores. Más comentarios son actividad; no son evidencia automática de defectos encontrados o riesgo reducido.

Producto diferente no es autoridad independiente

Independencia exige separar al menos cinco planes:

Cambiar la marca del revisor puede diversificar contexto, pero productos diferentes pueden compartir modelo, dependencias, incentivos o permisos. El mismo producto también puede llamar verificadores realmente distintos. La unidad de independencia es la autoridad y mecanismo, no el logo.

Los Papeles distintos ayudan a crear contrapunto, siempre que el sistema preserve quién ejecuta, quién verifica y quién acepta. [R1-C3]

Gate de pull request para flujos con agentes

1. Identidad y provenance de diff

Registre el agente/producto cuando sea atribuible, el ejecutor humano, la spec, el commit-base, los archivos modificados, las dependencias, las herramientas y las limitaciones. La provenance incompleta debe continuar unknown, nunca volverse “humano” por exclusión.

2. Review como señal, no autoridad

El comentario del agente entra como finding con regla explícita de severidad, deduplicación, resolución y falso positivo. La aprobación de merge sigue vinculada a una autoridad autorizada.

3. Ownership por riesgo

Use CODEOWNERS o mecanismo equivalente para identidad, autorización, pagos, migraciones, infraestructura y datos. Un owner necesita revisar la propiedad bajo su responsabilidad, no sólo confirmar que el bot comentó.

4. Verificadores protegidos

Exija checks de lint, tipos, pruebas, seguridad, dependencias, pruebas negativas, contrato, migración, rollback y evals conforme al riesgo. Un agente puede accionar e interpretar checks; no debe poder reescribir silenciosamente la política que decide el merge.

Los cambios pequeños y aislados aumentan la revisión, pero workspace separado no es sandbox ni garantía de seguridad. [R1-C2]

5. Último push bajo nueva aprobación

A protección de branches de GitHub Puede invalidar la aprobación después de volver a commit o exigir la aprobación del último push por otra persona. Sin eso, un cambio posterior puede entrar apoyado en una revisión de diff antiguo.

6. Merge y bypass explícitos

Restrinja quién puede hacer push, merge, dispensar review o cambiar checks. Excepción necesita razón, autoridad, validez y ruta, especialmente cuando quien generó el cambio también controla el bypass.

7. Source y build conectados al release

SLSA 1.2 define provenance como información verificable sobre de donde vino un artefacto y donde, cuando y como fue producido. Preserve commit, inputs, builder, digest y receipt de promoción para demostrar que lo que fue revisado es lo que opera.

Permisos y gates necesitan existir fuera del modelo y ser probados en el sistema de entrega. [HARNESS31-C2]

Matriz de autoridad proporcional al riesgo

La tabla es análisis profesional del autor, no resultado del paper. El objetivo es calibrar autoridad, no imponer una topología universal.

Evidence Packet merge

Un merge governable debe permitir reconstruir:

• cual decisión y spec iniciaron el cambio;
• quien o cual agente produjo y revisó;
• cual diff exacto fue evaluado;
• que se aceptaron findings, corregidos o dispensados;
• cuales checks rodaron, en cual commit y con cual resultado;
• quien aprobó el riesgo residual;
• cual artefacto por digest fue promovido;
• El test, monitoreo y rollback sostienen la operación.

Si la respuesta sólo existe en el resumen del agente, la organización tiene una narrativa, no una evidencia.

Lo que demuestra este brief, y lo que no prueba

El estudio prueba que eventos atribuidos a agentes en los dos lados del PR ya son numerosos en proyectos públicos y que las combinaciones exhiben estándares distintos. No prueba que same-product es complaciente, que cross-product es independiente, que bots reemplazaron humanos o que el código resultante tiene más o menos calidad.

Los controles de este brief derivan del paper, de la documentación oficial y de la experiencia profesional del autor. Son una propuesta de gobernanza técnica, no un hallazgo causal de los investigadores.

Fuentes directas

• Paper — AI-to-AI Code Reviews of GitHub Pull Requests
• Paquete de replicación
• CodAGE — fechaset-base
• GitHub — pull request reviews
• GitHub — protected branches
• GitHub — CODEOWNERS
• NIST SP 800-218 — Secure Software Development Framework
• SLSA 1.2 — provenance

Conclusión

IA puede escribir y revisar en el mismo flujo. Lo que no puede hacer sola es crear legitimidad para la propia aprobación.

La independencia debe aparecer en autoridades separadas, propiedades verificadas, checks protegidos, provenance y una persona accountable por el merge y la operación.