Una directora de ingeniería de plataformas abre un lunes por la mañana la factura mensual de su proveedor de IA. La partida de agentes de programación ha vuelto a crecer y le han pedido que la explique antes del miércoles. Construye el gráfico más evidente: gasto por ingeniero en un eje y trabajo integrado en el otro. Espera una línea ascendente. Lo que obtiene parece una nube de confeti. Dos ingenieros con la misma producción difieren en gasto por un factor que no logra explicar, y quien más utiliza el servicio no es la persona cuyo trabajo destacaría. Es una escena inventada, una forma de ver el problema antes de que lleguen las cifras.

Las cifras ya existen. El 10 de noviembre, un equipo de JetBrains, la Universidad Carnegie Mellon y la Universidad de California en Irvine publicó una prepublicación titulada The AI Era’s Lines of Code?, que pregunta qué mide realmente el gasto de un ingeniero en tokens. Sus autores son Shyam Agarwal, Olga Lvova, Agnia Sergeyuk, Anastasiia Serova, Timofey Bryksin, Thomas Zimmermann y Bogdan Vasilescu. Su respuesta, basada en los datos de una empresa, es que mide cuánto trabaja una persona a través de agentes y dice poco sobre lo que produce. El artículo no ha pasado por revisión por pares.

Una métrica adoptada antes de probarla

Las empresas empezaron a utilizar el gasto en tokens como cifra de gestión antes de que nadie lo hubiera estudiado, y los autores lo señalan. Citan una clasificación que construyó un empleado de Meta para que sus compañeros compitieran por ser quien más tokens utilizara en la empresa; Fortune informó en abril de que se retiró dos días después de que la prensa escribiera sobre ella. Citan a directivos de Nvidia y Meta que afirmaban que un buen ingeniero debería utilizar tokens por un valor equivalente a una gran parte de su salario, a Salesforce fijando objetivos mínimos de gasto mensual y a proveedores de analítica que dividen el coste de tokens entre las solicitudes de incorporación de cambios integradas y llaman a esa proporción retorno de la inversión.

Desde entonces han aumentado las dudas. El artículo informa de que Uber agotó su presupuesto de 2026 para herramientas de programación con IA en cuatro meses y de que su director de operaciones afirmó que la relación entre el gasto en tokens y las funciones entregadas «todavía no existe». Un crítico citado en el artículo calificó el gasto en tokens de «la métrica de líneas de código de la era de la IA: fácil de medir, fácil de manipular y desconectada de la productividad real». Desde entonces, Meta ha dicho a sus ingenieros que los recuentos de tokens no se utilizarán para evaluar su impacto, y Amazon cerró una clasificación de uso y calificó esa medida de «profundamente defectuosa», según el relato de los autores sobre las informaciones de prensa. La pregunta pendiente era si la crítica se sostenía al vincular los registros de uso con la producción real.

Qué muestra la telemetría

JetBrains, que crea herramientas de desarrollo de software y tenía unos 2600 empleados en aquel momento, opera una pasarela interna que registra cada llamada a un agente de programación. Los investigadores tomaron las cinco semanas completas del 29 de junio al 2 de agosto de 2026 y vincularon los tokens semanales de cada ingeniero con sus commits. El panel abarca 404 ingenieros; los registros contienen 3,1 millones de llamadas a agentes. Una encuesta anónima separada de la empresa recibió respuestas de 412 empleados.

Dentro de cada intervalo de commits semanales, la observación de ingeniero y semana situada en el percentil 90 de gasto utilizaba entre 39 y 240 veces los tokens de la situada en el percentil 10. Seguir a la misma persona de una semana a otra ofreció una relación más plana de lo que esperaban los autores. Una semana con el doble de commits habituales de un ingeniero costaba alrededor de un 20 % más de tokens. En el sentido inverso, una semana con el doble de tokens habituales iba acompañada de solo alrededor de un 10 % más de commits. Si la producción creciera en proporción al gasto, ambas cifras estarían cerca del 100 %, y los autores rechazan la proporcionalidad en todas las unidades temporales que probaron.

Gran parte de la variación depende de la persona. La identidad del ingeniero explicaba el 79 % de la variación en tokens semanales, y el tercio de usuarios de mayor consumo utilizó el 79 % de todos los tokens. Quienes más gastaban siguieron siendo las mismas personas durante las cinco semanas. Los commits, las líneas modificadas y otras dos medidas de actividad explicaban conjuntamente el 38 % de las diferencias entre ingenieros y el 13 % de las diferencias semanales de una misma persona. La función y el equipo, tomados por separado, predecían el gasto peor que utilizar simplemente la media.

El artículo pregunta después adónde va el excedente. Las semanas sin ningún commit representan solo el 4 % de los tokens, pero los autores estiman, a partir de las curvas de mejor ajuste, que hasta unas dos quintas partes del gasto no varían con los commits de la semana. Lo denominan un límite superior, porque incluye el coste fijo de utilizar un agente y el gasto que hay detrás de commits escritos a mano. También señalan que la mayoría de los tokens son contexto reenviado en cada turno y que un nuevo modelo de vanguardia llegó en la tercera semana y acaparó el 45 % de todo el gasto en dos semanas.

El trabajo que nunca se convierte en un commit

La encuesta explica parte de la brecha. De las 197 evaluaciones de los dos agentes de programación realizadas por participantes técnicos, 167 respondieron a las preguntas sobre la semana anterior. En el 91 % de ellas, los participantes dijeron que la herramienta les había ahorrado tiempo, con una mediana de diez horas. Utilizaban los agentes para programar en el 63 % de las evaluaciones y para al menos otra actividad en el 89 %: analizar datos, generar ideas, investigar un tema, planificar, aprender o escribir. Quienes utilizaban el agente solo para programar declararon una mediana de tres horas ahorradas; quienes indicaron dos o más usos ajenos a la programación declararon diez.

Parte del valor es trabajo que de otro modo no existiría. Al preguntar por el principal beneficio del agente, el 31 % de 74 respuestas sustantivas mencionó la velocidad en las tareas habituales y el 30 % el trabajo en código, dominios o tecnologías desconocidos; un participante escribió: «Puedo probar cosas que antes me daba miedo intentar». De 44 descripciones de trabajo realizado solo porque existía el agente, el 36 % implicaba una base de código, un lenguaje o un conjunto de tecnologías desconocidos. La encuesta también registra costes. El más común fue una salida incorrecta o de baja calidad, mencionada en el 49 % de las respuestas, y el 31 % de los usuarios técnicos de agentes declaró una mayor carga cognitiva. Los autores añaden que los testimonios pueden exagerar las mejoras y citan un ensayo aleatorizado de 2025 en el que desarrolladores experimentados de código abierto tardaron un 19 % más con herramientas de IA, aunque creían que eran más rápidos.

Qué implica para objetivos, presupuestos y límites

Los autores no concluyen que los agentes sean una mala inversión. Su conclusión se refiere a la vara de medir. Si la asociación dentro de cada ingeniero fuera causal, duplicar su gasto mediante un objetivo aumentaría los commits alrededor de un 10 %, con un intervalo del 2–25 %. Recomiendan no juzgar a los ingenieros por el gasto ni esperar que los objetivos eleven mucho la producción. Dividir el gasto entre la producción induce a error de otra manera, porque los tokens por commit disminuyen de forma mecánica al aumentar los commits, de modo que un ingeniero parece más eficiente en una semana de mucho trabajo.

Los límites de gasto reciben el análisis más incómodo. Un límite afecta sobre todo a los usuarios de mayor consumo, cuya proporción de gasto no vinculada a la producción es la menor de los tres grupos: un 36 %, frente al 51 % y el 52 % de los otros. Como consumen la mayoría de los tokens, también concentran la mayor parte del gasto no vinculado, por lo que un límite elimina tanto gasto que sirve a la producción como gasto que no, y el recuento de tokens no permite distinguirlos. Antes de imponer límites, los autores sugieren comprimir o gestionar el contexto, almacenar en caché el contexto repetido y dirigir las llamadas rutinarias a modelos más baratos, además de medir el coste facturado en lugar de los tokens, ya que recortar el contexto puede aumentar la factura cuando el agente vuelve a leer lo eliminado.

Importan dos limitaciones. JetBrains construye herramientas de programación con IA, por lo que parte del uso medido puede corresponder a pruebas de sus propios agentes, y sus ingenieros trabajan en bases de código consolidadas. El uso era voluntario y sin objetivos, por lo que las diferencias de gasto reflejan en parte elecciones personales. Los commits tampoco recogen el trabajo de revisión y diseño. Los autores subrayan que se trata de asociaciones de una empresa durante cinco semanas.

Un segundo estudio, de un grupo de autores parcialmente coincidente, muestra lo que ocurre al imponer un objetivo. Con datos de 802 desarrolladores y 196 212 solicitudes de incorporación de cambios, examina una empresa mediana cuyo director de tecnología fijó en junio de 2025 el objetivo de duplicar las solicitudes integradas por ingeniero mediante IA. La empresa no alcanzó el objetivo hasta el décimo mes, y el coste recayó en la revisión de código, donde la carga por revisor se duplicó.

Contar lo adecuado

Los autores de JetBrains proponen dos correcciones. Las pasarelas deberían registrar a qué incidencia o tarea sirvió cada sesión de agente, para vincular el gasto con los resultados y no solo con los commits. Además, el campo necesita medidas validadas del valor del trabajo asistido por agentes; los autores no conocen ninguna. Hasta entonces, afirman, el gasto sirve para contabilizar recursos y poco más. Para medir la adopción, sugieren comunicar el número semanal de usuarios junto a una medida que no crezca con el tamaño del contexto, como la proporción de ingenieros que utilizan agentes la mayoría de los días laborables.

De vuelta en la oficina inventada, la directora de ingeniería de plataformas no recorta el presupuesto de nadie el miércoles. Pide al equipo de la pasarela que añada un campo, la incidencia a la que pertenece cada sesión, y dice a su interlocutor de finanzas que el gráfico de confeti es el hallazgo. La factura seguirá llegando el primer día del mes. Lo que cuenta es con qué frecuencia recurren sus ingenieros al agente. Si ha merecido la pena el dinero es otra pregunta, y la factura no tiene una línea para responderla.

Referencias

  • Agarwal, S., Lvova, O., Sergeyuk, A., Serova, A., Bryksin, T., Zimmermann, T., & Vasilescu, B. (2026). The AI Era’s Lines of Code? A Case Study on What an Engineer’s Token Spend Measures. arxiv.org
  • Arar, A. B. (2026). Tokenmaxxing and the search for AI metrics that matter. LeadDev. leaddev.com
  • Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arxiv.org
  • Bharade, A. (2026). Uber’s COO says it’s getting harder to justify the money spent on AI tokenmaxxing. Business Insider, via Yahoo Finance. finance.yahoo.com
  • Cooter, M. (2026). Meta minimizes role of token maxing in employee evaluations. CIO. cio.com
  • He, H., Agarwal, S., Denisov-Blanch, Y., Azaletskiy, P., Koyejo, S., & Vasilescu, B. (2026). AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate. arxiv.org
  • Munis, J. (2026). A Meta employee created a dashboard so coworkers can compete to be the company’s No. 1 AI token user. Fortune. fortune.com
  • Palmer, A. (2026). Amazon’s anti-tokenmaxxing memo says engineers should be pickier about using AI. CNBC. cnbc.com