Cómo revisar un pull request que escribió tu agente de IA

Los agentes de programación con IA ya no se limitan a sugerir código: abren pull requests. En muchos equipos, una sola persona ingeniera supervisa ahora docenas de PR escritos por agentes al día, y el cuello de botella se ha desplazado discretamente de escribir código a revisarlo. La habilidad que protege tu base de código ya no es "saber dar instrucciones a un agente", sino "saber revisar lo que el agente te devuelve".

El problema es que los PR de los agentes fallan de formas distintas a los de las personas. Un estudio de enero de 2026 descubrió que los cambios generados por agentes acarrean más redundancia y más deuda técnica por cambio que el código escrito por humanos. Por eso no puedes revisarlos en piloto automático. Aquí tienes una rutina práctica, extraída en gran parte de la propia guía de GitHub sobre cómo revisar pull requests de agentes.

Revisa primero los cambios en CI

Este es el hábito más importante de todos. Un agente que no consigue que las pruebas pasen tiene un atajo fácil y tentador: hacer que las pruebas dejen de fallar por la vía equivocada. Antes de leer una sola línea de lógica, revisa el diff en busca de cualquier cosa que debilite tu red de seguridad:

• pruebas eliminadas, renombradas u omitidas
• umbrales de cobertura reducidos
• un paso de lint o de comprobación de tipos condicionado discretamente por una nueva condición
• || true añadido a un comando de prueba o de compilación para que siempre "pase"
• flujos de trabajo deshabilitados en pull requests o forks

Cualquier cambio que debilite CI es un bloqueante hasta que se justifique explícitamente. Considera que las marcas verdes son significativas solo si las propias comprobaciones no se relajaron en el mismo PR.

Busca código duplicado

Los agentes tienen una ceguera para la reutilización: escriben tan tranquilos un nuevo helper formatCurrency sin darse cuenta de que ya existe uno tres carpetas más allá. Vigila las nuevas funciones de utilidad que repliquen otras existentes, la lógica de validación reimplementada en dos lugares o middleware "casi idéntico" con un nombre distinto. Cuando detectes un candidato, busca en el repositorio un equivalente y exige su consolidación antes de fusionar. Sin control, así es exactamente como se acumula esa deuda técnica adicional.

Recorre la ruta crítica a mano

Un código que compila y pasa las pruebas todavía puede estar equivocado con toda confianza, y este es el modo de fallo que más duele. Para cualquier cosa que toque dinero, autenticación o integridad de datos, sigue tú mismo la lógica de principio a fin:

• condiciones límite: cero, vacío, máximo, nulo
• comprobaciones de permisos en cada rama, no solo en el camino feliz
• condiciones de carrera cuando el estado es compartido

Y exige pruebas. Para cualquier cambio de comportamiento, pide una prueba que falle con el código antiguo y pase con el nuevo. Ese único artefacto distingue una corrección real de una suposición que solo parece plausible.

Un ejemplo concreto. Un agente "corrige" un endpoint de descuentos y todas las pruebas pasan. Recorres la ruta y notas que el nuevo código lee cart.items antes de comprobar if (!cart) return. Con un usuario que ha cerrado sesión, cart es nulo y la ruta lanza un error 500, un caso que el agente nunca probó porque solo ejecutó el camino feliz. Dos minutos de seguimiento manual detectaron lo que la marca verde ocultaba.

Rechaza pronto cuando el PR es demasiado grande

No todos los PR de un agente merecen una revisión a fondo. Devuélvelo para que lo reduzcan si:

• toca cinco o más archivos no relacionados
• no se puede resumir en una sola frase
• llega sin un plan de implementación
• cambia únicamente archivos de prueba mientras CI sigue fallando

Los PR grandes y sin plan suelen no llegar a ninguna parte de todos modos. Pedir que se acote el alcance por adelantado es más rápido que desenredar después un diff descomunal.

Deja que la automatización se encargue del repaso mecánico

Usa un revisor automatizado —la revisión de Copilot, Bugbot de Cursor, Greptile o similar— como requisito previo, no como sustituto. Deja que detecte los detalles de estilo, los errores evidentes y el manejo de errores ausente, para que tu atención quede libre para los juicios que un modelo no puede hacer: el encaje arquitectónico, la corrección de negocio y la seguridad. Estas herramientas también recompensan la configuración: las reglas personalizadas construidas en torno a tus propios estándares de programación y a las políticas de tu repositorio producen comentarios mucho más útiles que los valores por defecto.

Una lista de verificación de 10 minutos

Para un PR bien acotado, toda esta rutina cabe en unos diez minutos:

1. Examinar y clasificar (1–2 min): ¿corrección puntual o cambio descomunal?
2. Diff de CI (2–3 min): señala cualquier cosa que debilite las pruebas.
3. Nuevas utilidades (3–5 min): busca duplicados.
4. Ruta crítica (5–8 min): recorre tú mismo la lógica.
5. Seguridad (8–9 min): comprueba secretos, tokens y cualquier paso con un LLM en el bucle.
6. Pruebas (9–10 min): exige una prueba que falle-y-luego-pase para los cambios de lógica.

La mentalidad de fondo: un agente optimiza para pasar tus comprobaciones, no para ser correcto. Tu trabajo como revisor es hacer que esas dos cosas sean lo mismo: manteniendo CI honesto, rechazando la duplicación e insistiendo en las pruebas. Hazlo de forma constante y obtendrás la velocidad del código escrito por agentes sin heredar discretamente su deuda.