Llevo meses trabajando con agentes de programación a diario, y hay una sensación que me cuesta explicar: escribo mucho más código que antes, pero no tengo claro que el equipo saque muchas más cosas a producción. Por eso me ha interesado tanto un estudio de Fiona Chen y James Stratton, de la Universidad de Harvard, que Ars Technica resume con un titular muy claro: los agentes de IA generan más código, pero no más software.
El estudio, Artificial Intelligence in the Firm: Bottlenecks in Software Production, no se basa en encuestas ni en experimentos de laboratorio, sino en lo que ha pasado de verdad en empresas que desarrollan software. Y su conclusión es que la productividad que ganan los agentes al escribir código se pierde más adelante, en la revisión.
De dónde salen los datos
Los datos vienen de Jellyfish, una plataforma que usan las empresas para analizar la actividad de sus equipos de ingeniería. Junta información de GitHub, Jira, Google Calendar, los sistemas de recursos humanos y el uso de herramientas de IA como GitHub Copilot, Cursor y Claude Code.
En total, unos 300 millones de eventos de trabajo (commits, pull requests, issues…) de más de 700.000 personas en 718 empresas, desde enero de 2021 hasta marzo de 2026. El estudio compara cada empresa antes y después de adoptar asistentes (los que autocompletan código que escribe una persona) o agentes (los que escriben y envían código por su cuenta), aprovechando que cada una los adoptó en un momento distinto.
Más código…
En la parte de escribir código, los agentes funcionan. Los asistentes apenas mueven la aguja, pero los agentes sí:
| Métrica | Asistentes de IA | Agentes de IA |
|---|---|---|
| Líneas de código | +12% | +30% |
| Commits | +9% | +20% |
| Pull requests | +5% | +23% |
En los asistentes, sólo el aumento de commits es estadísticamente significativo. En los agentes lo son las tres.
…pero no más software
El problema aparece al medir lo que realmente llega a producción. Chen y Stratton usan dos medidas: las issues de Jira resueltas, que se cierran cuando el código se despliega, y las épicas completadas, que representan funcionalidades o proyectos enteros.
Con agentes, ninguna de las dos cambia de forma significativa. Los datos descartan que la producción de software haya subido más de un 12%, muy lejos del 30% de líneas de código. Y no es que las tareas se hayan vuelto más grandes o más complejas: lo comprobaron con un modelo que estima cuánto se tarda en resolver cada issue, y tampoco cambia.
Tampoco hay efecto en el empleo. En el empleo total de las empresas, medido con LinkedIn, el efecto es prácticamente cero: descartan una caída de más del 2,9%. Ni más software ni menos gente.
El cuello de botella está en la revisión
Lo más interesante del estudio es que explica dónde se pierde la ganancia. Escribir código es sólo una parte del trabajo: según sus datos, los ingenieros dedican entre un 30 y un 40% de su tiempo a escribir código. El resto se va en planificar, revisar, probar y desplegar. Si aceleras sólo una de esas fases, el atasco se va a la siguiente.
Y la siguiente es la revisión. Tras adoptar agentes:
| Métrica de revisión | Cambio |
|---|---|
| Tiempo medio para revisar un pull request | +49% |
| Pull requests a los que se piden cambios | casi el doble |
| Comentarios por pull request | +35% |
| Personas haciendo revisiones | +14% |
No sólo hay más código que revisar, sino que cada pull request necesita más trabajo de revisión. El modelo que propone el estudio distingue justo esos dos efectos: la IA aumenta la cantidad de código y a la vez cambia su calidad, con más fallos que hay que encontrar antes de aceptarlo.
Y las herramientas de revisión con IA, de momento, no lo resuelven. En marzo de 2026, el 80% de las empresas ya usaba alguna, pero la IA sólo escribía el 23% de los comentarios de revisión. El grueso del trabajo lo siguen haciendo personas.
flowchart LR
A["Planificar"] --> B["Escribir código · agentes +30%"]
B --> C["Revisar · +49% de tiempo"]
C -->|"se piden cambios"| B
C --> D["Desplegar · sin cambios"]Las limitaciones
Conviene leerlo con cuidado. Los datos acaban en marzo de 2026, y los agentes han mejorado mucho desde entonces. Además, el estudio mide cuándo adopta los agentes la empresa, no cuánto los usa cada persona, así que mezcla equipos que los usan a fondo con otros que apenas los han probado. Y las empresas son clientes de Jellyfish que han aceptado ceder sus datos, que no tienen por qué representar a todas.
Aun así, el resultado coincide con un estudio anterior sobre repositorios de código abierto, que también encontró muchas más líneas de código y commits con Copilot, pero mucho menos efecto en pull requests y versiones publicadas.
Dos lecturas más del mismo debate
Estos días se han publicado dos textos que encajan muy bien con el estudio.
Nate Meyvis se pregunta en Where is all the new, good software? dónde está todo ese software nuevo y bueno que debería estar saliendo, y propone varias respuestas. La que más me convence: muchos procesos de las empresas, como conseguir que ingenieros sénior y producto aprueben un plan, no se han acelerado con IA. Otra muy interesante: buena parte del software nuevo es privado (herramientas internas, paneles hechos por cada uno, scripts de un solo uso), y no lo vemos.
Rich Hickey, el creador de Clojure, va más lejos en ‘AI’ is Not a Tool. Para él, una herramienta es algo que manejas, con control y respuesta continuos, como un martillo. Los LLM no son eso: “son automatización”, algo a lo que le pides el trabajo y lo hace por su cuenta. No estoy del todo de acuerdo con él, pero su argumento explica bastante bien el estudio: si el agente escribe el código sin que tú lo hayas manejado, el momento en que vuelves a tener el control es la revisión. Y ahí no hay atajo.
Lo que me llevo
Me quedo con dos ideas que el propio estudio señala en su conclusión.
La primera: medir líneas de código o commits no sirve para saber si la IA está funcionando. Hay que mirar el proceso entero, desde que se planifica una funcionalidad hasta que llega a producción. Si sólo miras la fase que acelera la IA, siempre parecerá un éxito.
La segunda: acelerar una fase mueve el cuello de botella a otra. Es la vieja teoría de las restricciones aplicada al software. Si los agentes escriben más rápido de lo que el equipo puede revisar, lo que toca es cambiar cómo se trabaja: pull requests más pequeños, mejores tests automáticos, decidir qué código necesita una revisión a fondo y cuál no, y que quien lanza el agente revise su propio trabajo antes de pasárselo a otro.
Yo sigo usando agentes a diario y no pienso dejar de hacerlo. Pero este estudio pone números a algo que intuía: escribir el código era la parte fácil de automatizar, y entender y validar lo que se ha escrito sigue siendo trabajo de personas.
Fuente: Artificial Intelligence in the Firm: Bottlenecks in Software Production, Fiona Chen y James Stratton (Harvard), vía Ars Technica.
