Si tu equipo trabaja con agentes de código, casi seguro que programa más. La pregunta que te van a hacer en la próxima revisión del presupuesto es otra: ¿entrega más?
Este insight defiende una idea que incomoda a los dos bandos: si el equipo programa más y entrega lo mismo, la revisión no es el problema, es donde se nota. Llega a revisión trabajo que nadie definió antes, y la persona tiene que reconstruir qué se quería antes de poder aprobarlo. Revisar más deprisa, o dejar de revisar, solo mueve el atasco a producción.
Lo que encontró el estudio de 718 empresas
Fiona Chen, de la Universidad de Harvard, y James Stratton han estudiado 300 millones de eventos de trabajo en 718 empresas con un diseño de diferencias en diferencias escalonado: comparan la evolución de cada empresa antes y después de adoptar asistentes y agentes de código, aprovechando que cada una los adoptó en un momento distinto. Su resumen dice tres cosas:
- Las dos tecnologías, asistentes y agentes, aumentan la productividad al programar.
- Esa ganancia no se traslada del todo a la producción de software ni al empleo.
- En el caso de los agentes, la diferencia se explica por un atasco en la revisión de código: las revisiones tardan más, más cambios necesitan correcciones y cada revisión recibe más comentarios.
Dicho de otra forma: el código se escribe antes, pero espera más para entrar.
Riesgo Es un trabajo académico en su versión de agosto de 2026 y no consta que haya pasado revisión por pares. No hemos podido leer el texto completo: solo citamos lo que dice el resumen público en la web de la autora y no damos ningún porcentaje del estudio. El estudio no dice que la IA no sirva; dice dónde se pierde parte de lo que aporta.
No es la primera vez que se ve
Faros AI, una empresa que vende analítica de ingeniería, publicó en julio de 2025 un informe con telemetría de más de 10.000 desarrolladores en 1.255 equipos. En los equipos con mucha adopción de IA encontró esto:
Y, sobre todo, no observó ninguna correlación significativa entre la adopción de IA y mejoras a nivel de empresa. Son datos de un proveedor, con el sesgo de sus propios clientes, pero apuntan al mismo sitio que el estudio de Harvard con una metodología y unos datos distintos: el volumen sube mucho más que lo que sale por el otro lado.
Una corrección a lo que escribimos antes
En revisar código generado por IA sostuvimos que la revisión casi nunca es la restricción de caudal de un equipo, y que si se busca entregar antes hay que mirar el despliegue. Con agentes, el estudio de las 718 empresas dice otra cosa: la revisión sí es donde se atasca la ganancia. Lo decimos aquí para que no se lea un insight contra el otro.
Nuestra lectura, y esto ya no es del estudio, es que las dos ideas encajan si se mira qué recibe la revisión. Cuando un agente produce un cambio grande a partir de una petición vaga, quien revisa no tiene con qué compararlo. Tiene que adivinar qué se quería, leerlo entero y discutirlo en comentarios. Eso explica revisiones más largas, más correcciones y más comentarios. El atasco aparece en la revisión, pero se fabrica antes.
Una revisión rápida no es la que lee deprisa. Es la que compara el cambio con algo que se escribió antes del código.
Lo que llega a revisión y cómo cambiarlo
Las tres señales que describe el estudio tienen, cada una, una causa probable antes de la revisión. La tabla es nuestra, no del estudio:
| Lo que se ve en la revisión | Causa probable antes de la revisión | Qué cambiar |
|---|---|---|
| Las revisiones tardan más | Cambios grandes, que mezclan varias cosas | Lotes pequeños: un cambio, un propósito |
| Más cambios necesitan correcciones | Lo que tenía que cumplir el cambio no estaba escrito | Criterios de aceptación escritos antes del código |
| Más comentarios por revisión | La persona revisa también lo mecánico: estilo, pruebas que faltan, convenciones | Comprobación automática en cada cambio antes de la revisión humana |
Elaboración de onext a partir de las tres señales que describe el resumen de Chen y Stratton (2026)
La primera fila tiene apoyo independiente. En su modelo de capacidades para equipos con IA, DORA dice que trabajar en lotes pequeños amplifica la influencia positiva de la IA en el rendimiento del producto y reduce la fricción para los equipos de desarrollo.
La segunda es la base de Spec-Driven Development (SDD), el desarrollo guiado por especificaciones: lo que tiene que cumplirse se escribe antes, y así la revisión se convierte en una comparación. Lo explicamos en Spec-Driven Development con IA, y cómo esos criterios pasan a ser la puerta del merge.
La tercera deja a la persona lo que solo puede hacer una persona: juzgar la intención, el diseño y el riesgo. Donde el riesgo es alto, decide una persona. Son las mismas prácticas que protegen la estabilidad, como contamos en con IA tu equipo entrega más rápido, pero no más estable; aquí las miramos desde el asiento de quien revisa. Y aprobar sin poder explicar lo aprobado tiene un coste que llega después: la deuda de comprensión.
Qué decir cuando te pregunten por el presupuesto
Si el equipo mide líneas de código, commits o pull requests, la IA casi siempre gana, y por eso esas cifras no responden a la pregunta. Lo que responde es el trabajo resuelto que llega a producción, comparado con lo que el equipo entregaba antes de los agentes. Al lado, dos cifras que enseñan dónde se pierde la diferencia: cuánto tarda un cambio desde que pide revisión hasta que se fusiona y cuántos vuelven con correcciones.
Qué indicadores elegir está en KPIs de equipos de desarrollo con IA, y cómo plantear el gasto como una apuesta que se puede comprobar, en la tesis de valor que conviene pedirle al equipo. Si los cambios se acumulan esperando revisión, comprar más licencias no acelera la entrega por sí solo: añade cola.
Si solo puedes cambiar una cosa este trimestre, que sea esta: ningún cambio del agente llega a revisión sin unos criterios de aceptación escritos antes. Es, a nuestro juicio, lo que más reduce lo que hay que adivinar al revisar, y es el punto de partida de la red que conviene montar antes del agente.
Una segunda mirada
Si quieres ver con alguien de fuera dónde se queda hoy el trabajo de tu equipo entre el agente y producción, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo es el resto del camino está en AI-Accelerated Development.
Preguntas frecuentes
¿Los agentes de código aumentan la productividad de un equipo de desarrollo?
Al programar, sí. El estudio de Fiona Chen y James Stratton con datos de 718 empresas concluye que los asistentes y los agentes de código aumentan la productividad al programar. Lo que no encuentra es que esa ganancia llegue entera al software entregado ni al empleo. La pregunta útil no es si el equipo programa más, sino si entrega más.
¿Dónde se pierde la ganancia de los agentes de código?
Según el resumen del estudio, en el caso de los agentes la diferencia se explica por un atasco en la revisión de código: las revisiones tardan más, más cambios necesitan correcciones y cada revisión recibe más comentarios. El código se escribe antes, pero espera más para entrar.
¿Hay que revisar más deprisa o dejar de revisar el código del agente?
Ninguna de las dos. Revisar más deprisa lo mismo convierte la revisión en un trámite, y dejar de revisar mueve el problema a producción. Lo que proponemos es cambiar lo que llega a la revisión: cambios pequeños, con criterios de aceptación escritos antes del código y con lo mecánico ya comprobado por la integración continua.
¿Por qué el código generado por un agente es más difícil de revisar?
Porque muchas veces la persona que revisa no tiene contra qué compararlo. Si lo que tenía que hacer el cambio no está escrito en ningún sitio, el revisor primero tiene que reconstruir la intención y después juzgar el código. Es la lectura de onext del atasco que describe el estudio, no una conclusión del estudio.
¿Qué conviene medir para saber si la IA mejora la entrega?
Trabajo resuelto que llega a producción, no líneas de código ni pull requests. Y, junto a eso, cuánto tarda un cambio desde que pide revisión hasta que se fusiona y cuántos vuelven con correcciones. Si solo se miden las líneas o los pull requests, la IA casi siempre parece ganar.
¿Qué fiabilidad tiene el estudio de las 718 empresas?
Es un trabajo académico reciente de Fiona Chen, de la Universidad de Harvard, y James Stratton (versión de agosto de 2026) con 300 millones de eventos de trabajo y un diseño de diferencias en diferencias escalonado, pero no consta que haya pasado revisión por pares. En este insight solo citamos lo que dice su resumen público y no damos porcentajes que no hayamos podido leer en el original.
Fuentes
- Fiona Chen y James Stratton, «Artificial Intelligence in the Firm: Bottlenecks in Software Production», versión de agosto de 2026. Resumen en la web de Fiona Chen (Universidad de Harvard), consultado el 24 de octubre de 2026; el texto completo no se ha podido leer.
- Faros AI, «The AI Productivity Paradox Report 2025», 23 de julio de 2025 (más de 10.000 desarrolladores en 1.255 equipos).
- Kevin M. Storer y Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de septiembre de 2025.
- Las citas de fuentes en inglés están traducidas por onext. La lectura del atasco, la tabla y la forma de medir son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →