Un estudio de Harvard sobre 718 empresas midió un 30% más de código tras adoptar agentes de IA, sin aumento del trabajo terminado. Qué hacer cuando el cuello de botella se corre a la revisión.
Un working paper reciente de Harvard puso un número a algo que muchos equipos de ingeniería ya intuían. Los economistas Fiona Chen y James Stratton cruzaron datos de la plataforma de analítica Jellyfish con actividad de GitHub en 718 empresas de software: unos 300 millones de eventos de trabajo, más de 700.000 personas, entre enero de 2021 y marzo de 2026. El resultado: tras adoptar agentes de IA, las líneas de código por persona subieron alrededor de un 30%, los commits un 20% y los pull requests un 23%. La cantidad de issues y epics terminados no mostró un aumento estadísticamente significativo.
Si los equipos produjeran más código y más pull requests, sería esperable que resolvieran más problemas. El hecho de que eso no esté pasando obliga a preguntarse dónde se está perdiendo ese volumen extra de trabajo.
Vale aclarar qué se midió: el estudio cuenta como trabajo terminado los issues de Jira resueltos, y un issue se considera completo cuando su código está desplegado en producción. Es decir, no se está midiendo actividad sino entrega.
La respuesta más consistente es simple: la capacidad de un equipo para revisar código con criterio no creció al mismo ritmo que la generación de código asistida por IA. Más líneas y más pull requests no significan automáticamente más valor entregado si cada uno de esos cambios igual necesita ser leído, entendido y validado por una persona.
El estudio lo midió en detalle, y los números del otro lado del embudo son tan elocuentes como los de la generación: el tiempo promedio de revisión de un pull request creció un 49%, los comentarios por PR subieron un 53%, y la proporción de pull requests que requieren cambios se duplicó. La proporción de personas dedicadas a revisar creció apenas un 14%. El trabajo extra no desapareció: se acumuló en la cola de revisión.
Hay una razón de fondo por la que revisar código generado por un agente cuesta más que revisar el de un colega. Cuando revisás a un compañero, podés asumir que entendió el problema, que probó los casos borde obvios y que lo que escribió refleja alguna intención. Con el código de un agente hay que verificar todo eso desde cero: si resuelve el problema planteado, si introdujo una falla de seguridad sutil, si duplica lógica que ya existe en otra parte, y si respeta las convenciones del equipo lo suficiente como para no volverse una carga de mantenimiento en seis meses.
La reacción natural es buscar una herramienta de revisión asistida por IA. El estudio se anticipa a esa salida con el dato más incómodo de todos: para marzo de 2026, el 80% de las empresas analizadas ya tenía herramientas de revisión con IA en funcionamiento, y aun así solo el 23% de los comentarios de revisión eran generados por IA.
Dicho de otro modo: las empresas ya compraron la solución y el cuello de botella sigue ahí. La capacidad de revisión con criterio no se adquiere con una licencia; se construye con prácticas, con tiempo asignado y con gente que conoce el sistema.
Para equipos de ingeniería que ya adoptaron agentes de IA en su día a día, algunas recomendaciones concretas: medir resultados de negocio y calidad, no volumen de código generado; incorporar análisis estático específico sobre el código producido por IA; y establecer reglas de revisión diferenciadas para pull requests originados por agentes, con más foco en entender el porqué de cada cambio que en aprobar rápido.
A eso se suma una decisión de asignación que el estudio deja servida: si la restricción real es la capacidad de revisar, sumar más licencias de generación no mejora la entrega. Lo que la mejora es destinar tiempo de perfiles senior a revisar, y tratar esa capacidad como parte del proyecto de adopción y no como un costo que se absorbe solo.
La conclusión no es dejar de usar IA para generar código, sino entender que el cuello de botella se movió: ya no está en escribir, está en revisar con criterio. Los equipos que inviertan en fortalecer esa capacidad van a sacarle más partido real a la IA que los que solo midan cuánto código se produce.
Conviene leer el hallazgo con precisión: que no haya un aumento estadísticamente significativo no equivale a que no haya ninguna ganancia. Lo que los datos descartan son mejoras grandes, del orden del 20% o 30% que sí se ven en la actividad de código. El margen que queda es mucho más chico que el que promete la herramienta, y ese es el punto.
En Sagant acompañamos a equipos de ingeniería en este tipo de adopción madura de IA, con foco en procesos de revisión sólidos y no solo en velocidad de generación.
