Los agentes ya abren el 40 % de las pull requests de GitHub. Harvard ha medido dónde se atascan: en la revisión de código, un 56 % más lenta

La mitad de las pull requests de GitHub empiezan hoy con un agente. Los ingenieros que tienen que aprobarlas siguen siendo los mismos.

Esta semana me han llegado dos documentos a la mesa. El 28 de octubre GitHub publicó su Octoverse 2026: en septiembre, más del 40 % de las pull requests de la plataforma nacieron como primer borrador de un agente, unos 110 millones, frente al 17 % de marzo. El 1 de noviembre, Fiona Chen y James Stratton, doctorandos de Harvard, publicaron la versión actual de Artificial Intelligence in the Firm: Bottlenecks in Software Production, construida con datos de Jellyfish de 655 empresas, 720.542 trabajadores y 445 millones de eventos de trabajo entre enero de 2021 y agosto de 2026. De todo el paper, el dato que quiero que te quedes es uno: cuando una empresa adopta agentes de programación, el tiempo entre enviar una pull request a revisión y aprobarla sube un 56,1 %.

No escribo esto desde la silla del analista. Casi todas las semanas reviso código escrito por un agente, sea para nuestra propia plataforma o dentro de una app que un fundador hizo con Claude Code o con Lovable y ahora necesita en producción. El paper describe mi agenda. Escribir código se ha abaratado. Decidir que ese código es correcto, no.

Los agentes añaden un 44 % más de código y, como mucho, un 31 % más de software

El paper separa dos cosas que casi todos los cuadros de mando mezclan. La producción intermedia es código: líneas añadidas, commits, pull requests abiertas. La producción final es software: incidencias y epics de Jira resueltos, que en estas empresas significa que el trabajo llegó a producción.

En lo primero, los agentes cumplen. Adoptar asistentes subió las líneas de código un 38,6 %, los commits un 25,5 % y las pull requests un 25,2 %. Adoptar agentes, encima de eso, añadió otro 44,0 % en líneas, un 36,0 % en commits y un 35,7 % en pull requests. En la empresa mediana, las líneas por trabajador y mes pasaron de 3.679 a 6.482.

En lo segundo, poco de ese caudal llega al final. Los asistentes movieron las incidencias resueltas un 2,0 % y los epics un 1,7 %, cifras que no se distinguen de cero. Los agentes movieron las incidencias un 13,7 % y los epics un 18,0 %, y la estimación de incidencias apenas roza la significación estadística. Lo útil es el intervalo de confianza: incluso con agentes, los datos descartan un aumento del software entregado superior al 30,7 %, muy por debajo del 44 % de código adicional. Los autores comprobaron si las incidencias se habían hecho más grandes, estimando con modelos la duración de cada tarea a partir del texto de Jira, y esa explicación no cierra la brecha.

El empleo tampoco se movió. Doce meses después de adoptar agentes, la estimación es de un −2,6 %, y el intervalo descarta caídas por debajo del −15,6 %. Las empresas no están despidiendo ingenieros para embolsarse la ganancia. La están absorbiendo en algún sitio. El paper dice dónde.

La cola delante del revisor ha crecido un 60 %, y la revisión en sí dura un 58 % más

El 56,1 % son dos números. El código espera un 59,9 % más en la cola antes de que alguien lo coja. Una vez cogido, pasa un 58,5 % más de tiempo en revisión activa. El primero es capacidad: la misma gente, más diffs. El segundo es calidad: la proporción de cambios que reciben al menos un comentario sube un 13,1 %, y el número de comentarios por cambio sube un 38,6 %. Los revisores no están firmando más código a ciegas. Encuentran más cosas que decir sobre él.

Uno de los 21 ingenieros entrevistados por los autores lo resume en una frase que podría haber grabado en nuestra propia reunión diaria: la gente podía hacer muchísimos commits muy deprisa, pero solo un ingeniero sénior tenía permiso para aprobar cambios porque era quien conocía el código, y podía revisar el suyo una vez a la semana. Tras varias caídas provocadas por commits generados con IA, la empresa añadió una norma que exigía aprobación sénior para el código generado con IA, y la cola volvió a alargarse.

Ese es el mecanismo, paso a paso. Los agentes aumentan el volumen de código que entra en revisión. Ese código entra con más defectos por unidad. La capacidad de revisión no crece con el volumen, porque revisar no es una habilidad genérica aplicada a texto genérico. En el conjunto de datos, el 82,8 % de las revisiones las hace alguien que ya conoce ese código, frente al 17,2 % que saldría si los revisores se asignaran al azar, y el código escrito por un sénior lo revisa otro sénior el 75,7 % de las veces. El revisor es la persona que tiene el modelo del sistema en la cabeza, y no hay una API para añadir más personas así.

Los revisores de IA no han vaciado la cola: el 79 % de las empresas ya los usa

La solución evidente es poner también un agente a revisar. Casi todas lo hicieron: el 79,1 % de la muestra había adoptado herramientas de revisión de código con IA al final del periodo. El cuello de botella sigue ahí. Cuando Chen y Stratton ajustan su modelo de producción a las estimaciones, recuperan una ganancia de productividad al programar del 73,7 % y un cambio en la productividad al revisar del −7,0 %. Las empresas respondieron moviendo gente: el tiempo de programación bajó un 22,7 % y el de revisión subió un 43,4 %.

Lo leo como la prueba más sólida hasta ahora de la frase que repito desde hace dos años: el modelo es la mercancía; el andamiaje que lo rodea es el foso. Una herramienta que señala estilo y comprobaciones de nulos quita la parte barata de la revisión. La parte cara, «¿este cambio hace lo que pedía la incidencia, y qué más ha tocado?», es el andamiaje: tests que fijan el comportamiento, evals que fijan los criterios de aceptación, una arquitectura lo bastante pequeña para que una persona la tenga entera en la cabeza. Las evals son la única suite de regresión que tiene un sistema de IA, y un revisor sin ellas lee 400 líneas sin ningún oráculo.

El contraargumento merece su propio párrafo, porque el informe de GitHub apunta en la dirección contraria. El Octoverse dice que las pull requests iniciadas por agentes se fusionan más: el 90 % en dos semanas en septiembre, frente a cerca del 86 % de las que no tienen participación detectada de agentes, y desde el 83 % de febrero. Las dos cosas pueden ser ciertas a la vez. GitHub mide si una PR acaba fusionándose; Harvard mide cuánto tarda la aprobación y cuánto trabajo cuesta. El código que se fusiona tras un 56 % más de revisión sigue contando como «fusionado» en una ventana de dos semanas. Y las dos cifras llevan su aviso: GitHub vende Copilot, así que su investigación es investigación de proveedor, y el paper de Harvard es un working paper con datos de un único proveedor de analítica, sin revisión por pares todavía. Juntas, las dos apuntan al mismo sitio. El código entra. Entra más despacio, y a la ingeniera sénior le cuesta más horas de su semana dejarlo entrar.

Esta película ya la hemos visto: la fábrica no se aceleró cuando se aceleró el motor

Los autores se remontan a la década de 1880, y hacen bien. Los motores eléctricos llegaron a las fábricas en esos años; la producción industrial no se transformó hasta cuatro décadas después, cuando las plantas se reconstruyeron alrededor del motor en vez del eje de vapor. La frase de Solow de 1987, que se veía la era del ordenador en todas partes menos en las estadísticas de productividad, tiene la misma forma.

El software ya ha vivido una ronda de esto. La investigación DORA detrás de Accelerate encontró que la frecuencia de despliegue y el lead time mejoraban con prácticas, lotes pequeños, trunk-based development, integración continua, y no con herramientas solas. Escribí sobre por qué esas cuatro métricas importan más que la velocidad; los agentes son el compilador más rápido que hemos comprado jamás, y el lead time está sentado en la columna de revisión. La propia simulación del paper pone cifras a lo que hay en juego. Si la productividad de la revisión se queda donde está, la producción de estas empresas sube un 57,8 % hasta 2031 y luego se estanca cuando la revisión toca techo. Si la revisión sigue el ritmo de la programación, la producción sube un 341,4 %. Toda la diferencia entre esos dos futuros está en el paso que nadie presupuesta.

Qué haría este trimestre si fuera tu CTO

1. Partir el tiempo hasta la aprobación en sus dos mitades y colgar las dos en la pared. La espera en cola y la revisión activa se mueven por motivos distintos, y el paper muestra que suben las dos. Si el problema es la cola, te faltan revisores. Si es la revisión activa, te faltan tests. Arregla la que has medido.
2. Que las PR de agente se ganen la revisión. Ningún cambio escrito por un agente entra en la cola sin el plan que siguió, los tests que añadió y un diff que se pueda leer de una sentada. Los benchmarks 2026 de LinearB sobre 8,1 millones de pull requests, también investigación de proveedor, sitúan las PR asistidas por IA en unas dos veces y media el tamaño de las humanas, esperando más de dieciséis horas a que alguien las coja frente a unas tres. El tamaño es la variable que controlas hoy.
3. Poner las evals delante del revisor, no detrás. Cada criterio de aceptación de la incidencia se convierte en una eval que el agente tiene que pasar antes de que un humano abra el diff. Así el revisor gasta su 58 % en diseño y radio de impacto, no en comprobar si la función devuelve la forma correcta.
4. Rotar un revisor de guardia y proteger la franja. El ingeniero que tiene el sistema en la cabeza es la restricción. Trata sus horas de revisión como una guardia: programadas, visibles, sin que el trabajo de funcionalidad las interrumpa.
5. Mantener la base de código lo bastante pequeña para que una persona la abarque. El 82,8 % de familiaridad es el hallazgo silencioso. Cada módulo que un sénior no sabe explicar es un módulo que espera una semana al que sí sabe. Cuando llevamos una app hecha con IA a producción, lo primero que entregamos es un mapa de lo que nadie entiende, porque ahí es donde se formará la cola.

Seis números para llevarse

• Más del 40 % de las pull requests de GitHub empezaron con un agente en septiembre de 2026, unos 110 millones, frente al 17 % de marzo. (GitHub, Octoverse 2026, 28 de octubre.)
• Adoptar agentes de programación subió las líneas de código un 44,0 %, los commits un 36,0 % y las pull requests un 35,7 % en 655 empresas. (Chen y Stratton, Harvard, versión del 1 de noviembre.)
• El software entregado subió como mucho un 30,7 %; la estimación de incidencias resueltas es del 13,7 %, al borde de la significación.
• El tiempo entre enviar a revisión y aprobar subió un 56,1 %: la espera en cola un 59,9 %, la revisión activa un 58,5 %.
• Los comentarios por cambio subieron un 38,6 %, y el 79,1 % de las empresas ya usaba herramientas de revisión con IA.
• El 82,8 % de las revisiones las hace alguien que ya conoce el código. El revisor no escala por API.

Los agentes han movido el coste del software de escribirlo a decidir que es correcto. Las empresas que ganen los próximos cinco años serán las que doten, equipen y midan esa decisión con la misma seriedad con que dotaron la escritura. Si tienes un repositorio donde un agente ha escrito casi todo y una sola persona puede aprobarlo, esa es la conversación que tenemos cada semana. Trae la cola.