✨︎ Resumen (TL;DR):
- Fiona Chen y James Stratton, de Harvard, analizaron 718 empresas y relacionaron la adopción de agentes de programación con IA con mayor actividad de desarrollo.
- Las estimaciones por trabajador y mes muestran 30% más líneas de código, 20% más commits y 23% más pull requests.
- Las tareas terminadas en Jira no aumentaron de forma estadísticamente significativa, mientras el ciclo hasta integrar código se alargó 49%.
Un análisis de 718 empresas realizado por Fiona Chen y James Stratton, de Harvard, vinculó la adopción de agentes de programación con IA con más actividad de desarrollo, pero no con un aumento estadísticamente significativo de las tareas terminadas en Jira. El documento de trabajo, fechado el 4 de agosto de 2026, compara compañías según el momento en que adoptaron las herramientas y usa registros de Jellyfish hasta marzo de 2026. También reporta revisiones más largas antes de integrar cambios.
Un agente de programación con IA es una herramienta de inteligencia artificial que participa en tareas de desarrollo de software; en este análisis, su adopción se observa mediante líneas de código, commits y pull requests.
Más actividad, sin un avance claro en Jira
Las estimaciones por trabajador y por mes vinculadas a la adopción de estas herramientas registraron 30% más líneas de código, 20% más commits y 23% más pull requests. Un commit representa un cambio guardado; un pull request plantea la integración de cambios para que otras personas los revisen y decidan si se incorporan.
El dato de Jira apunta en otra dirección. El análisis no encontró un aumento estadísticamente significativo en las tareas terminadas. Por eso, el volumen de código y de solicitudes de integración describe actividad dentro del proceso, pero no basta para afirmar que un equipo entregó más trabajo concluido.
La diferencia importa porque completar una tarea individual, integrar un cambio y entregar una función son resultados distintos. Una medición de productividad tiene que especificar cuál de esos resultados cuenta, además del entorno y las herramientas usadas.
Integrar el código tomó más tiempo
El intervalo entre presentar un pull request e integrar el cambio se alargó 49%. El aumento equivale a 3.45 días adicionales sobre una base de 7.03 días.
Ese periodo cubre todo el tiempo entre la apertura de la solicitud y la incorporación del cambio. No mide únicamente las horas que una persona pasó leyendo código. El autor puede estar corrigiendo una observación, o la solicitud puede esperar una decisión antes de integrarse.
La documentación de GitHub describe la revisión como un proceso en el que las personas comentan cambios, sugieren mejoras y aprueban la propuesta o piden correcciones. Un comentario general, una aprobación y una solicitud de cambios son decisiones diferentes. Los administradores también pueden exigir aprobaciones para proteger ramas específicas del proyecto.
Un equipo puede solicitar la revisión a personas o equipos concretos. Cada solicitud abre un trabajo de evaluación que requiere coordinación. Si una propuesta se presenta por la mañana y espera aprobación hasta el día siguiente, esa espera forma parte del ciclo aunque nadie la revise durante la noche.
Por eso, el aumento de 3.45 días señala un ciclo más largo para integrar cambios, pero no identifica por sí solo dónde se acumuló el tiempo. Para localizar el atasco habría que separar la espera, las correcciones del autor y el trabajo de revisión.
La adopción también complica la medición
METR aportó otra advertencia en una actualización del 24 de febrero de 2026. Su nuevo experimento asignaba al azar las tareas propuestas a dos condiciones: una permitía usar IA y la otra no.
El diseño tenía problemas de selección. Algunos desarrolladores preferían no participar si debían hacer una parte del trabajo sin IA. Otros excluían tareas en las que esperaban obtener grandes beneficios con estas herramientas. Esa conducta podía dejar fuera precisamente a quienes anticipaban mayores beneficios.
METR también encontró dificultades para contabilizar el tiempo cuando los participantes usaban varios agentes a la vez o realizaban otro trabajo mientras esperaban. La organización consideró probable una mejora frente a comienzos de 2025, pero calificó sus datos como evidencia muy débil para estimar qué tan grande era ese efecto.
El indicador útil está entre el código y la entrega
Las dos investigaciones apuntan a una misma precaución: no existe una sola cifra que resuma por sí misma la productividad de un equipo de desarrollo. Las líneas de código permiten observar actividad. El tiempo que una solicitud permanece abierta muestra dónde se acumula trabajo. Ninguna de esas medidas confirma por sí sola que una función llegó a entregarse.
Para comprobar el avance útil, el equipo tendría que seguir una solicitud desde su apertura hasta la entrega. Esa lectura conecta la tarea terminada, la integración del cambio y la función entregada, en lugar de tratarlas como si fueran el mismo resultado.
