Revisión humana de PRs de agentes: qué mirar antes de aceptar

Cómo revisar un pull request hecho por un agente de IA: qué comprobar, qué cambios exigen firma humana, qué riesgos hay y cómo no aprobar por inercia.

info Definición Rápida
La revisión humana de PRs de agentes es la lectura que hace una persona de un pull request generado por una IA antes de integrarlo. Comprueba si el cambio hace lo que pide el ticket, si es seguro y si encaja en el proyecto. Quien lo integra responde por cada línea, aunque no la haya escrito.

Esta página trata del juicio humano sobre un PR ya abierto. Cómo se crean las ramas y se leen los diffs está en ramas y pull requests, y cómo mostrar un cambio antes de aplicarlo, en previsualizar cambios. Aquí vamos a lo que cambia cuando el autor es un agente.

¿Qué cambia al revisar código de un agente?

El PR de un agente suele llegar ordenado: formato coherente, nombres razonables, pruebas en verde. Eso invita a revisar por encima. La guía de revisión de Google es un buen punto de partida porque no distingue autores: pide mirar el diseño, la funcionalidad, la complejidad, las pruebas, los nombres, los comentarios, el estilo, la coherencia y la documentación, y leer todas las líneas asignadas sin dar por buena ninguna parte sin leerla (Google, What to look for in a code review).

Tres de esas preguntas pesan más con un agente:

  • Complejidad. Google pide vigilar el exceso de ingeniería: código más genérico de lo necesario o que añade funciones que el sistema no necesita hoy. Un agente puede añadir una capa extra con la misma facilidad que una línea.
  • Pruebas. La pregunta de Google sirve tal cual: ¿fallarían estas pruebas si el código se rompiera? Si el mismo agente escribió el cambio y sus pruebas, conviene comprobarlo.
  • Funcionalidad. Que el código compile y se vea bien no responde a si hace lo que el ticket pedía ni a qué pasa con los casos límite.

¿Qué revisar en cada PR?

Una guía de estándares de revisión para código generado por IA propone diez comprobaciones (Metacto, Establishing code review standards for AI-generated code). Agrupadas, quedan así:

  1. Fidelidad al requisito. Compara el diff con los criterios de aceptación del ticket, no con lo que el agente dice que hizo.
  2. Solo APIs reales. Cada módulo, función, método de SDK, opción de línea de comandos y clave de configuración debe existir en la versión que usa el repositorio. Es la cara práctica de las alucinaciones.
  3. Origen de las dependencias. Un estudio presentado en USENIX Security 2025 generó 576.000 muestras de código con 16 modelos y encontró que al menos el 5,2 % de los paquetes recomendados por los modelos comerciales y el 21,7 % de los recomendados por los modelos abiertos no existían (Spracklen et al., We Have a Package for You!). Los modelos han cambiado desde entonces, pero el riesgo se mantiene: alguien puede registrar un paquete con un nombre inventado y esperar a que un agente lo instale. Antes de aceptar una dependencia nueva, comprueba que existe, quién la mantiene y desde cuándo.
  4. Sin secretos en el código. Revisa también pruebas, registros y datos de ejemplo. Qué hacer con una clave expuesta está en variables de entorno y secretos.
  5. Validación de entradas y permisos. Que las rutas protegidas comprueben quién llama, no solo la pantalla.
  6. Manejo de errores. Entradas vacías, permisos denegados, red caída.
  7. Pruebas de los caminos de fallo, no solo del caso feliz.
  8. Nada debilitado. Un PR que salta pruebas, baja el umbral de cobertura o relaja un linter no está listo, aunque todo salga en verde.
  9. Encaje en la arquitectura. Convenciones de nombres, flujo de datos y límites de módulos del proyecto.

Hay una pregunta que ninguna lista sustituye: ¿lo entendería si lo hubiera escrito un compañero? Si no, pide una explicación antes de aprobar. Si no programas, leer código sin saber programar da las preguntas mínimas.

¿Quién puede aprobar un PR de un agente?

Depende de la plataforma, pero GitHub da un ejemplo claro con su Copilot coding agent. Según su documentación, el PR que crea Copilot necesita la misma revisión minuciosa que cualquier otro. Si el repositorio exige aprobaciones, la de quien le asignó la tarea no cuenta para el mínimo: otra persona debe aprobar antes de integrar. Además, los flujos de trabajo de GitHub Actions no se ejecutan por defecto sobre los cambios de Copilot hasta que una persona pulsa “Approve and run workflows”, y la documentación pide estar especialmente atento a cualquier cambio en .github/workflows/ (GitHub Docs, Reviewing a pull request created by Copilot). Un administrador puede desactivar esa aprobación, así que no des por hecho que está activa.

La lección general: conviene que quien pide el cambio no sea la única persona que lo aprueba. En otras plataformas, confirma qué reglas existen en vez de suponerlas.

¿Qué exige firma humana?

La guía de Metacto clasifica los cambios por riesgo. En los de riesgo alto (autenticación, autorización, criptografía, pagos, datos personales, migraciones de base de datos, APIs públicas, infraestructura y permisos de agentes en producción) propone que la IA solo redacte, y que una persona reescriba o verifique a fondo, con aprobación senior, revisión de seguridad y un plan de migración o un modelo de amenazas. Para interfaz interna, documentación o pruebas sin nuevas fronteras de confianza, basta la aprobación habitual con comprobaciones automáticas. Es la propuesta de una consultora, no un estándar, pero la lógica es sencilla: cuanto más caro el error, menos se delega la decisión. Es el mismo principio de humano en el circuito.

La misma guía recomienda que quien abre el PR declare cuánto hizo la IA: si redactó el código, las pruebas, las dependencias o la configuración, y qué verificó personalmente.

¿Puede revisar otra IA?

Puede servir como primera pasada. Pero la guía de Metacto es explícita: las herramientas de revisión con IA no son una autoridad de aprobación y no deben decidir si un requisito se cumple, porque un comentario generado no tiene responsabilidad ni contexto de negocio. Añadimos una consecuencia razonable, aunque no medida: un revisor automático que comparte supuestos con el agente que escribió el código tenderá a confirmar sus errores en vez de verlos.

Ejemplo

Ejemplo ilustrativo: un agente abre un PR para añadir validación de correo al formulario de registro. El diff es pequeño y las pruebas pasan. La revisora abre el ticket y ve que pedía validar el correo en el formulario, pero el agente también modificó la función que envía el correo de bienvenida. Recorre la lista: la función de validación que usa existe, no hay secretos, pero la prueba nueva solo cubre un correo válido. Pide dos cosas: revertir el cambio fuera de alcance y añadir un caso con un correo mal formado. El PR vuelve corregido y se aprueba en la segunda ronda.

Para el lado de quien reparte el trabajo, lee colas de trabajo para agentes; para aislar cada tarea, git worktrees para agentes. El artículo del blog sobre un flujo de tickets con dos agentes cuenta un caso donde un agente planifica y revisa el trabajo de otro.

Errores comunes

  • Aprobar porque las pruebas pasan, sin mirar qué comprueban.
  • Revisar solo el estilo: lo caro está en la lógica y en lo que debía cambiar y no cambió.
  • Aceptar un PR gigante. Pide dividirlo en uno por tarea.
  • No verificar que las APIs y los paquetes existen.
  • Pulsar “Approve and run workflows” sin mirar qué cambió en .github/workflows/.
  • Pensar que “lo hizo la IA” reparte la responsabilidad. Quien integra, responde.

Fuentes

Preguntas frecuentes

¿Cómo se revisa un pull request hecho por un agente de IA?
Con la misma exigencia que el de una persona: compara el diff con los criterios del ticket, comprueba que las funciones y paquetes que usa existen, busca secretos, confirma que las pruebas fallarían si el código se rompiera y que el cambio encaja en la arquitectura.
¿Por qué el código de IA necesita revisión aunque las pruebas pasen?
Porque pasar las pruebas no demuestra que el cambio sea lo que se pidió. Una guía de revisión de código con IA advierte contra aceptar un parche solo porque las pruebas pasaron, y señala como mala señal las pruebas generadas que verifican detalles internos en vez de comportamiento.
¿Qué cambios de IA requieren aprobación humana explícita?
Los que tocan autenticación, autorización, criptografía, pagos, datos personales, migraciones de base de datos, APIs públicas e infraestructura. Una guía de la industria propone que en esos casos la IA solo redacte y una persona reescriba o verifique a fondo, con revisión de seguridad.
¿Puede otra IA revisar el PR en lugar de una persona?
Puede hacer una primera pasada, pero no debería ser la autoridad que aprueba. La guía citada sostiene que las herramientas de revisión con IA no deciden si un requisito se cumple: la decisión de integrar es de personas responsables.
¿Puede quien pidió el cambio a un agente aprobar su propio PR?
Depende de la plataforma. En el Copilot coding agent de GitHub, si el repositorio exige aprobaciones, la de quien le asignó la tarea no cuenta para el mínimo: otra persona debe aprobar antes de integrar.