Dos tercios de los pull requests con AI nunca se mergean

Los pull requests escritos con AI se mergean en un 32,7% de los casos. Los escritos por personas, en torno al 84,5%. La diferencia sale del análisis de LinearB sobre 8,1 millones de pull requests en 4.800 equipos de 42 países, publicado el 4 de mayo de 2026, y es un número más útil que casi todo lo que se discute sobre productividad: con la evidencia disponible, dos de cada tres cambios que escribe un agente nunca llegan a entrar.

La lectura popular de eso es "la revisión es el nuevo cuello de botella". El mismo conjunto de datos dice que esa lectura está equivocada, de una manera concreta y bastante más incómoda.

Nadie revisa más lento el código con AI: tarda más en empezar

LinearB midió que los pull requests generados con AI esperan más de 16 horas en promedio hasta que alguien los toma, contra unos 200 minutos del trabajo sin asistencia: más de cinco veces más. Pero una vez que la revisión arranca, los de AI pasan más rápido: unos 194 minutos, contra 252 del trabajo manual.

Leé los dos números juntos. La demora no es capacidad de revisión, porque revisar en sí resulta más corto. La demora está antes, en lo que hace que alguien elija otro pull request primero. Y después la pasada sobre ese código es un 23% más breve que sobre el código que escribió un colega.

Nuestra lectura es que esto es un problema de confianza disfrazado de problema de capacidad. Alguien que posterga un cambio dieciséis horas y después lo recorre más rápido que de costumbre no lo está revisando con más cuidado por estar en juego más cosas. Esa combinación es la preocupante, y no aparece en ningún tablero que cuente pull requests.

Lo que se lanzó este mes apunta justo ahí

El 4 de agosto de 2026 GitHub publicó una guía que arranca con un pull request de 1.721 líneas y la reacción de quien tenía que revisarlo: "esta descripción no ayuda mucho, lo reviso después". Su solución no es un agente mejor. Es partir esa salida en cuatro pull requests apilados —modelo de datos, endpoint de API, integración con el chat, componentes de UI— cada uno asignado a alguien con la experiencia que corresponde. GitHub nombra sin vueltas la falla que ataca: el pull request grande "se vuelve difícil de revisar, así que simplemente se queda ahí".

Cinco días antes, la app de Copilot había lanzado sesiones apiladas con la misma premisa, para que una corrida de agente llegue como una cadena ordenada y no como un paredón. Y el 23 de julio Linear agregó atribución de autoría en documentos: "los indicadores de nombre te permiten ver si un texto lo escribió un colega o lo agregó un loop", con las ediciones del agente resaltadas aparte.

Tres funcionalidades en dos semanas, de dos empresas, y ninguna hace que un agente sea más capaz. Las tres atacan las dieciéis horas, no la revisión. Es una apuesta razonable si la demora en tomar el trabajo es de verdad un problema de legibilidad: quien puede ver la forma de un cambio empieza antes.

La lectura que volvería benigno todo esto

Hay una alternativa honesta, y los datos no la resuelven. Un 32,7% de merge puede significar que los agentes producen peor código. Puede significar igual de bien que los agentes abarataron tanto abrir un pull request que ahora los equipos tiran borradores que antes ni siquiera habrían escrito. Son dos historias con implicancias opuestas y el mismo número.

Lo que LinearB midió es correlación entre asistencia de AI y tasa de merge, no causa. Quien te diga que la brecha prueba que la AI escribe mal se está pasando de la evidencia, y quien te diga que prueba experimentación sana, también.

Qué hacer con esto

Partí la métrica. Medí la tasa de merge de los cambios asistidos por agentes aparte del resto, y separá el tiempo hasta que alguien lo toma del tiempo de revisión. Si el primero sube mientras el segundo baja, tenés el patrón de arriba, y ninguna cantidad extra de producción se va a convertir en software entregado.

Lo que conviene observar en los próximos seis meses es si estas herramientas empiezan a recomendar qué no revisar. Apilar todavía asume que cada línea termina pasando por ojos humanos, y los 194 minutos sugieren que ese supuesto ya está fallando en silencio. El primer proveedor que lance una respuesta defendible sobre qué diffs pueden saltearse la revisión va a estar afirmando algo sobre responsabilidad legal, no sobre herramientas. Si estás armando ese proceso, es el tipo de decisión que trabajamos en nuestros servicios.

Fuentes

• 8 million pull requests reveal where engineering productivity breaks down — LinearB, 4 de mayo de 2026.
• Turn one giant AI-generated pull request to a reviewable stack — Julia Muiruri, GitHub, 4 de agosto de 2026.
• Stacked sessions and pull requests in the GitHub Copilot app — GitHub, 30 de julio de 2026.
• Text attribution and agent-assisted editing — changelog de Linear, 23 de julio de 2026.