Por qué rechazan el pull request de tu agente

Un equipo de investigadores reunió 33,000 pull requests escritos por agentes de IA y se hizo una pregunta simple: ¿cuáles se mergean y cuáles mueren? El número de titular es que cerca del 29% de los PRs de agentes no logran mergearse. Pero el hallazgo útil es el patrón que está detrás — porque no es el que la mayoría de la gente supone.

El reflejo es pensar que los PRs fallidos contenían mal código. A veces. Pero el estudio encontró que las fallas se agrupan alrededor de algo completamente distinto: los PRs rechazados tienden a involucrar cambios de código más grandes, tocar más archivos y fallar el CI del proyecto, y en trabajos relacionados, hasta el código funcionalmente correcto también se rechaza — por ser demasiado grande, juntar ediciones sin relación y explicarse mal. En otras palabras, el agente muchas veces resolvió el problema y aún así lo rechazaron, porque el PR era una mala forma de pedir el cambio.

Escribir el código nunca fue la parte difícil de mergearlo

Aquí está el replanteo. Un merge no es un evento de código; es uno social. Un mantenedor humano tiene que leer el cambio, entenderlo, confiar en él y hacerse responsable de él. Todo lo que hace eso fácil — un diff pequeño y enfocado; un solo cambio coherente; tests que pasan; una descripción que explique qué y por qué — es lo que logra que un PR sea aceptado. Un agente que produce código correcto pero un PR desparramado, sin explicar y que falla el CI ha hecho la mitad fácil y se ha saltado la mitad que de verdad decide el resultado.

Y esto no es una regla específica de la IA. Los mantenedores también rechazan PRs grandes, que se salen de alcance y sin explicar provenientes de humanos. La investigación solo muestra que los agentes lo hacen más, más rápido y a escala, porque un agente optimiza para «producir una solución que funcione», no para «producir un cambio que un humano ocupado vaya a aceptar». Esos son objetivos distintos, y el segundo es el que le importa al botón de merge.

Las señales que encontró el estudio

Algunos de los patrones son lo bastante específicos como para actuar sobre ellos:

• El tamaño mata. La señal más clara de un PR condenado es que es grande y toca muchos archivos. A los agentes les encanta refactorizar cosas adyacentes mientras están ahí; los revisores lo odian.
• El CI es una puerta, no una sugerencia. Los PRs fallidos fallan el build con más frecuencia. Un agente que abre un PR sin correr los tests primero le manda al revisor una señal que dice «no revisé».
• El tipo de tarea predice el éxito. Los cambios de documentación, CI y configuración de build son los que mejor se mergean; el trabajo de rendimiento y los arreglos de bugs son los que peor se mergean. La tasa de merge sigue qué tan verificable y contenido es el cambio — exactamente lo que les falta a los arreglos complejos.
• La explicación es parte del trabajo. Los PRs con descripciones vagas o mal alineadas tienen menos probabilidad de ser aceptados y toman más tiempo — esto es la spec siendo el artefacto apareciendo al momento de la revisión. Si el revisor no puede ver rápido qué cambió y por qué, no puede confiar en él de forma barata, así que no lo hace.

Hay también un hallazgo más silencioso que vale la pena considerar: la mayoría de los PRs de agentes reciben muy poca revisión humana real, y la que reciben son cada vez más otros agentes. A medida que los PRs de agentes inundan por millones, la atención de revisión humana es el recurso escaso — y un PR que es caro de revisar pierde frente a uno que es barato, sin importar de quién sea el mejor código.

Qué hacer con esto

Si estás apuntando agentes de código a repositorios reales, las lecciones son concretas:

• Limita al agente a PRs pequeños y de un solo propósito. Un cambio, mínimos archivos, sin refactors oportunistas. Esta es la misma lógica de que la confiabilidad se acumula a nivel de flujo de trabajo: un cambio pequeño es uno que un humano puede de verdad verificar.
• Haz que pase el CI antes de abrir el PR, no después. Correr los tests es parte de producir el cambio, no un paso aparte que hace alguien más.
• Haz que escriba la descripción que el revisor necesita. Qué cambió, por qué, qué revisar. Trata la explicación como un entregable, porque al momento de la revisión lo es.
• Apúntalo a lo que se mergea, supervísalo en lo que no. Déjalo correr más suelto en docs, configuración y arreglos pequeños y contenidos; mantén mano firme en el trabajo de rendimiento y los arreglos de bugs enredados, donde la corrección es difícil de ver y la confianza difícil de ganar.

La conclusión

El estudio es un espejo útil. Seguimos midiendo a los agentes de código por si pueden escribir código que funcione, y cada vez más pueden. Pero «funciona» nunca fue lo que se mergea — «pequeño, probado, explicado y fácil de confiar» sí lo es. El 29% que falla no falla en su mayoría por corrección; falla por colaboración, que es una habilidad que el modelo no estaba optimizando y que tú tienes que aportar.

Así que cuando rechacen el PR de tu agente, no preguntes solo «¿estaba bien el código?». Haz la pregunta que el revisor en realidad se estaba haciendo: ¿era este un cambio que un humano ocupado pudiera entender rápido, verificar y del que pudiera hacerse responsable? Haz que el agente produzca eso, y la tasa de merge se cuida sola. Sáltatelo, y seguirás entregando código correcto que nadie acepta — lo cual, en un equipo, es lo mismo que no entregar nada.