Durante la última semana, varios medios tecnológicos han recogido un documento de trabajo de dos economistas de Harvard, Fiona Chen y James Stratton, titulado Artificial Intelligence in the Firm: Bottlenecks in Software Production. Conviene empezar por las salvedades: es un trabajo de fin de doctorado en su versión del 4 de agosto, no ha pasado revisión por pares, y sus datos proceden de Jellyfish, una empresa que vende analítica de ingeniería a equipos de software y que revisó el manuscrito solo para comprobar que no revelaba información reservada. Con eso sobre la mesa, el conjunto de datos es inusualmente grande: unos 300 millones de eventos de trabajo, entre actividad de código en GitHub, incidencias de Jira y entradas de calendario, de 718 empresas entre enero de 2021 y marzo de 2026, con datos de uso de GitHub Copilot, Cursor y Claude Code. Comparando empresas según el momento en que adoptaron las herramientas, los autores hallan que los agentes de programación elevan las líneas de código por trabajador un 30 %, las confirmaciones de cambios un 20 % y las solicitudes de integración un 23 %. Los asistentes anteriores, los que solo sugieren código mientras se escribe, movieron esas mismas medidas un 12 %, un 9 % y un 5 %, y solo el efecto sobre las confirmaciones resultó estadísticamente significativo.
Luego viene la parte que importa a quien firma un presupuesto. Medido en trabajo terminado, es decir, incidencias de Jira resueltas una vez desplegado el código y proyectos completados, el efecto de los agentes es pequeño, positivo y estadísticamente indistinguible de cero; las estimaciones descartan cualquier aumento de producción superior al 12 %, muy por debajo del 30 % de más código. El empleo tampoco se mueve: los autores descartan una caída de la plantilla total superior al 2,9 %. La producción que falta está esperando en la cola de revisión. Tras adoptar agentes, el tiempo medio de revisión de una solicitud de integración sube un 49 %, la proporción de solicitudes devueltas con cambios casi se duplica, los comentarios por solicitud suben un 35 % y la proporción de trabajadores dedicados a revisar código crece un 14 %. El atasco persiste después de que las empresas adopten herramientas de revisión de código con IA, porque los revisores humanos conservan el papel central. Una encuesta a 100 ingenieros que los autores hicieron para validar sus estimaciones de tiempo explica por qué: los ingenieros dedican solo entre el 30 % y el 40 % de su jornada a escribir código, y el resto se va en planificar, revisar, probar y desplegar, pasos que el agente no hace por ellos.
Por qué esto no va solo de software
El mecanismo que describe el trabajo es general. Todo proceso de producción tiene un paso que la IA acelera y un paso siguiente que comprueba el resultado: el socio que firma el escrito, el contable que cierra las cuentas, el directivo que aprueba la propuesta, el supervisor que lee la respuesta antes de que salga al cliente. Si el primer paso produce un 30 % más y el segundo conserva la misma capacidad, el volumen extra espera en una cola, y cuando los borradores son además de otra calidad, como sugiere que las devoluciones casi se dupliquen, el segundo paso se vuelve también más lento por pieza. El trabajo muestra además lo que hicieron las empresas: mover personas hacia la revisión. Esa es la inversión que convierte más borradores en más trabajo terminado, y rara vez aparece en el cálculo que justifica las licencias.
Qué hacer antes de comprar más IA
- Mida trabajo terminado, no actividad. Las líneas de código, los borradores, las páginas y los mensajes producidos miden esfuerzo. Cuente lo que sale por la puerta: funciones desplegadas, asuntos cerrados, facturas emitidas, incidencias resueltas. Si esa cifra no se ha movido desde que llegó la IA, la ganancia sigue dentro de la empresa.
- Dimensione el paso de revisión antes que el de redacción. Antes de añadir licencias, pregunte quién va a comprobar la producción extra y cuántas horas a la semana tiene. Si la respuesta sincera es nadie, las licencias compran una cola más larga. Haga de la revisión trabajo planificado, con responsables con nombre y tiempo en la agenda; las empresas del estudio acabaron moviendo personas hacia la revisión de todos modos.
- Haga que el agente entregue piezas pequeñas y comprobables. Un revisor tarda menos en diez cambios pequeños que en uno grande, y devuelve menos. Pida al agente que trabaje en tareas acotadas, que pase él mismo las pruebas o la lista de comprobación antes de entregar, y que diga qué ha verificado y qué no.
- Gradúe la revisión por riesgo, no por costumbre. No toda producción necesita el mismo escrutinio. Los cambios de bajo riesgo que superan las comprobaciones automáticas pueden pasar con una aprobación; todo lo que toque pagos, accesos, datos personales o un entregable para un cliente conserva dos pares de ojos. Mida el retrabajo junto a la velocidad, para que un carril más rápido no se convierta en uno con más fugas.
En nuestro propio equipo, la producción de la que informamos es el trabajo terminado y aceptado por la persona que supervisa cada agente, y lo primero que dimensionamos con un cliente es quién va a revisar lo que el agente produce, porque esa persona, y no la licencia, marca el ritmo.
Fuentes
- Artificial Intelligence in the Firm: Bottlenecks in Software Production — Fiona Chen y James Stratton, Universidad de Harvard (documento de trabajo, versión del 4 de agosto de 2026)
- AI coding agents write 30% more code and resolve zero additional issues, Harvard study finds — Forkast (11 de octubre de 2026)
- Harvard study: AI coding agents lift code 30%, shipped output flat — AI Weekly (12 de octubre de 2026)