Un documento de trabajo de Harvard ofrece una comprobación útil de una afirmación habitual sobre productividad: escribir más código con IA debería significar entregar más software. En 718 empresas que usan la plataforma de análisis de ingeniería Jellyfish, Fiona Chen y James Stratton estiman que la adopción de agentes de programación fue seguida por un 30 % más de líneas de código, un 20 % más de commits y un 23 % más de pull requests por trabajador activo. Sus medidas de issues de Jira y épicas completados no mostraron un aumento estadísticamente significativo. La versión actual del documento está fechada el 4 de agosto de 2026; sus datos de eventos laborales llegan hasta marzo de 2026.

La discrepancia importa a los responsables de ingeniería porque una pull request entra en una cola de revisión, pruebas y posibles cambios. En el mismo estudio, el tiempo transcurrido entre el envío y la fusión de una pull request aumentó, según la estimación, un 49 % tras adoptar agentes. Las solicitudes de cambios se hicieron más comunes y aumentaron los comentarios por pull request. Estos resultados apuntan a más trabajo de revisión, aunque no demuestran que todos los cambios escritos por agentes sean deficientes ni miden una tasa de defectos.

El gran cambio

  • Qué cambió:En este estudio a nivel de empresa, la adopción de agentes de programación coincidió con mucha más actividad de programación y revisiones de pull requests más exigentes, sin un aumento estadísticamente significativo de los issues resueltos ni de las épicas.
  • Por qué importa:Las líneas de código, los commits y las pull requests miden el trabajo que entra en el proceso de producción. El trabajo resuelto es una medida posterior. Un equipo que evalúe a los agentes solo por el volumen de código podría pasar por alto la carga que llega a revisión.
  • Qué observar:Si las empresas pueden ampliar su capacidad de revisión y si datos posteriores muestran aumentos del trabajo completado. Este documento de trabajo sigue la adopción temprana hasta marzo de 2026 y no permite determinar los efectos a más largo plazo.

Asistentes y agentes produjeron estimaciones distintas

Los autores distinguen entre asistentes, que responden con sugerencias de código mientras trabaja un desarrollador, y agentes, que pueden recibir una tarea de nivel superior y avanzar por varios pasos antes de que un desarrollador apruebe el resultado. Miden la adopción de asistentes mediante la activación de licencias empresariales de GitHub Copilot y Cursor. Para los agentes, combinan datos de uso de Claude Code con señales como cuentas de bots y firmas de herramientas en commits o pull requests. Algunas formas de uso individual o herramientas no integradas podrían quedar fuera de esas medidas. La estimación de agentes es la asociación adicional en torno a su adopción frente al período anterior de adopción de asistentes; no es una estimación para cada persona que usa un agente.

Los resultados de los asistentes fueron menores: un aumento estimado del 12 % en líneas, del 9 % en commits y del 5 % en pull requests. Solo el resultado de commits fue estadísticamente significativo en las estimaciones principales del documento. La adopción de agentes mostró aumentos significativos en las tres medidas de actividad de programación. Un commit registra una actualización del código; una pull request envía un cambio para revisión. Ninguno demuestra que una función haya llegado a los usuarios. El documento usa los issues de Jira resueltos y las épicas más grandes como medidas de producción en etapas posteriores, según el flujo de trabajo registrado en el que los equipos marcan el trabajo como completado tras la revisión, las pruebas y el despliegue. El estado de Jira sigue siendo un indicador indirecto de la entrega, no una medición independiente de lo que recibieron los usuarios.

Para los agentes, el aumento estimado de issues resueltos fue de 0,12 por trabajador y mes, frente a una base de 3,67, con un error estándar de 0,17. El resultado no se distingue estadísticamente de cero. La finalización de épicas tampoco mostró un cambio significativo. Los autores indican que su intervalo de confianza descarta un aumento de issues completados superior al 12 % de la media de referencia durante el período estudiado. Es una conclusión más acotada que afirmar que los agentes no producen software útil: siguen siendo posibles ganancias modestas y el recuento de issues no capta todos los cambios de valor o calidad. Los autores comprobaron si cambiaba el tamaño de los issues mediante medidas previstas de duración de tareas y no hallaron pruebas de ese cambio en su muestra.

Más trabajo llegó a quienes revisan

Las medidas de revisión ofrecen un mecanismo plausible para la brecha de producción. Tras adoptar agentes, el documento estima 3,45 días adicionales entre el envío y la fusión de una pull request, frente a una base de 7,03 días: un aumento del 49 %. Es tiempo de calendario en el proceso de revisión, no una medición con cronómetro de los minutos de revisión activa de una persona. La proporción de pull requests que recibieron una solicitud formal de cambios subió unos 12 puntos porcentuales desde una base del 13 %, mientras que los comentarios por solicitud aumentaron 0,58 desde una base de 1,66, es decir, un 35 %. La proporción de trabajadores que revisó al menos una pull request en un mes subió unos cuatro puntos porcentuales desde una base del 29 %, un aumento relativo del 14 %. Las estimaciones comparables de los asistentes no mostraron aumentos significativos en duración de revisión, solicitudes de cambios ni comentarios.

El documento no puede determinar solo con estos metadatos por qué un revisor pidió cambios. Más envíos pueden saturar una cola de revisión de capacidad fija; un cambio en la calidad del código o en los estándares de revisión también podría aumentar el escrutinio. Los autores no hallaron un aumento significativo del tamaño medio de las pull requests, lo que debilita una explicación sencilla para los comentarios adicionales. No inspeccionaron el contenido del código ni contaron directamente los defectos del trabajo generado por agentes. Su modelo de producción en dos etapas explica cómo escribir código más rápido y cambiar la revisión requerida por borrador podrían limitar conjuntamente la producción completada. El modelo interpreta las observaciones; no es una prueba independiente que aísle ninguno de esos mecanismos.

Las herramientas de revisión con IA también se habían extendido por la muestra: casi el 80 % de las empresas había usado una en marzo de 2026. Sin embargo, el documento atribuye a la IA el 23,3 % de los comentarios de revisión y encuentra al menos un comentario de IA en el 10,8 % de las pull requests. Por tanto, adoptar una herramienta de revisión no significa que la revisión se haya automatizado en estas empresas.

Qué puede establecer el diseño

Los investigadores analizan unos 300 millones de eventos laborales entre enero de 2021 y marzo de 2026 en 718 empresas clientes de Jellyfish que dieron su consentimiento, con 725.938 trabajadores. Comparan los resultados antes y después de que las empresas adoptaran asistentes o agentes con los de empresas que adoptaron más tarde o aún no lo habían hecho, mediante un diseño escalonado de diferencias en diferencias. Los controles por empresa y mes natural abordan algunas diferencias estables y tendencias temporales compartidas. La inferencia sigue dependiendo de cuán comparables habrían sido las trayectorias de esas empresas sin adopción. Las empresas más grandes adoptaron antes, y cambios no observados podrían haber afectado tanto a la adopción como al trabajo de ingeniería. El estudio es observacional; sus estimaciones no deben interpretarse como una prueba aleatorizada ni como un pronóstico para todos los equipos de software.

El resultado sobre empleo requiere la misma cautela. Usando el empleo total vinculado a LinkedIn y los trabajadores activos de Jellyfish para medir el empleo en ingeniería, los autores no pudieron atribuir un cambio significativo a la adopción de agentes durante el período observado. Eso no muestra qué ocurrirá con la contratación tras un ajuste más prolongado ni en el mercado laboral en general.

Cobertura anterior de BIG CHANGE examinó un caso de ingeniería distinto sobre programación con IA y entrega fiable. Este estudio amplía la perspectiva a varias empresas y distingue entre actividad de programación, revisión y trabajo resuelto. La lección práctica es seguir esas etapas en conjunto al evaluar agentes: un primer borrador más rápido cambia el volumen de trabajo pendiente en las fases posteriores, y este documento aún no muestra un aumento equivalente de issues o proyectos completados.

Fuentes y lecturas adicionales