En 30 días, los empleados de Meta consumieron aproximadamente 60 billones de tokens de IA a través de una clasificación interna que los ordenaba según su consumo; una factura que, según las estimaciones, superó los 100 millones de dólares para producir un trabajo que, en gran medida, fue meramente simbólico. Noventa días después, la clasificación había desaparecido y la empresa estaba racionando estrictamente el uso de la IA.
Ese proceso se denomina «tokenmaxxing»: es cuando la maximización del uso de tokens de IA se convierte en una puntuación de rendimiento y en un indicador de productividad. Desde entonces, las empresas han aprendido la lección y algunas han reaccionado de forma excesiva con un fenómeno apodado «tokenminning»: utilizar el menor número posible de tokens de IA para reducir los costes informáticos. Ambos enfoques fracasan porque consideran el recuento de tokens como un indicador fiable del crecimiento impulsado por la IA.
En este artículo analizaremos cuánto cuesta realmente el «tokenmaxxing», cómo lo manipulaban los ingenieros y la configuración de medición que resiste a quienes se les da bien manipular los números.
En resumen: El «tokenmaxxing», es decir, cuando el uso de tokens de IA se toma como un indicador de productividad, fracasa como práctica de gestión porque el consumo de tokens es un indicador de costes. Sin embargo, se estaba tratando como una métrica de rendimiento. La alternativa fiable al «tokenmaxxing» es una regla de emparejamiento: cada indicador de uso que publique un equipo debe ir acompañado de un resultado real que no pueda inflar.
Para ello, los responsables empresariales y de IA deben agregar los datos a nivel de equipo, mantenerlos al margen de las evaluaciones de rendimiento y utilizar las anomalías en el gasto para iniciar investigaciones. Las empresas que siguieron este patrón mantuvieron una señal válida. Las que clasificaron a los individuos la perdieron en menos de un trimestre.
¿Qué es el «tokenmaxxing»?
El «tokenmaxxing» es la práctica de maximizar el consumo de tokens de IA y considerar que un mayor uso es indicativo de una mayor productividad o de una mayor adopción de la IA. Los tokens son las unidades que un modelo de IA procesa como entrada y genera como salida.
El uso de tokens se convirtió en una métrica de rendimiento atractiva porque es visible, cuantificable y ya se realiza el seguimiento de ella en muchas plataformas de IA. Eso hace que sea más fácil de cuantificar que resultados como el tiempo ahorrado, la mejora en la toma de decisiones o los ingresos generados. Pero los tokens miden la actividad computacional, no el trabajo útil. Las indicaciones repetitivas, los bucles fallidos de los agentes y los resultados sin sentido hacen que el número aumente sin producir nada.
Los agentes de IA agravan esta situación. Un agente lee el contexto, recurre a herramientas de IA, revisa su propio trabajo y asigna tareas a otros agentes. Cada paso consume tokens. Aunque una mayor actividad puede traducirse en un trabajo más útil, también puede implicar flujos de trabajo ineficientes y un aumento de los costes.
En pocas palabras, el principal defecto del «tokenmaxxing» es que los equipos maximizan el número visible, mientras que la productividad, la calidad y el retorno de la inversión se mantienen iguales.
Lee también: El «flywheel» de aceleración de la IA: cómo el trabajo unificado potencia la transformación
¿Por qué se hizo popular el «tokenmaxxing»?
El «tokenmaxxing» se hizo popular porque los directivos necesitaban un número que demostrara que se estaba produciendo la adopción de la IA en las empresas. Y el uso de tokens era la única métrica que aparecía en la consola de facturación.
El director ejecutivo de Nvidia, Jensen Huang, marcó la pauta a principios de 2026 en el podcast «All-In» con un experimento mental sobre la factura de tokens de un ingeniero con un sueldo elevado.
«Si ese ingeniero que gana 500 000 dólares no consumiera tokens por un valor mínimo de 250 000 dólares, me alarmaría profundamente», afirmó. ¿Y si la respuesta fuera de 5 000 dólares? Se pondría como loco.
«Si ese ingeniero que cobra 500 000 dólares no consumiera tokens por valor de al menos 250 000 dólares, me alarmaría profundamente», afirmó. ¿Y si la respuesta fuera de 5 000 dólares? Se pondría como loco.
El uso de la IA se había convertido en un indicador claro de quién estaba a la altura. Esto ocurría en un momento en el que, en todas las reuniones de planificación, surgían preguntas sobre qué roles absorbería la IA. Los ingenieros que gastaban tokens daban la impresión de estar adaptándose al nuevo paradigma, mientras que los que no lo hacían corrían el riesgo de parecer un problema.
He aquí la ironía: la primera tabla de clasificación de tokens nunca se concibió como una competición. Shopify la creó para comprender por qué sus principales consumidores gastaban tanto, no para clasificarlos unos frente a otros. El vicepresidente y director de ingeniería, Farhan Thawar, describió más tarde cómo evolucionó la herramienta.
La empresa lo rebautizó como «panel de control de uso», añadió interruptores de seguridad y alertas de gasto, y utilizó los datos para detectar agentes fuera de control y incidencias en la infraestructura. Farhan escribió:
El «tokenmaxxing» es un tema controvertido. Más no significa mejor. Creamos la primera tabla de clasificación de tokens de IA. Después, evolucionamos nuestro enfoque. Se convirtió en un panel de control de uso. Los mismos datos, pero con un enfoque diferente. Añadimos cortacircuitos y picos de gasto. Detuvimos a agentes fuera de control. Encontramos incidencias en nuestra propia infraestructura. La señal real: no quién gastó más, sino aquellos cuyos tokens generaron mayor impacto. Esos son los ingenieros con los que quiero hablar.
El «tokenmaxxing» es un tema controvertido. Más no significa mejor. Creamos la primera tabla de clasificación de tokens de IA. Luego, evolucionamos nuestro enfoque. Se convirtió en un panel de control de uso. Los mismos datos, pero con un enfoque diferente. Añadimos cortacircuitos y picos de gasto. Detuvimos a agentes fuera de control. Encontramos incidencias en nuestra propia infraestructura. La señal real: no es quién gastó más, sino aquellos cuyos tokens generaron mayor impacto. Esos son los ingenieros con los que quiero hablar.
La mayoría de las empresas que copiaron la tabla de clasificación de Shopify la utilizaron para clasificar a los empleados en lugar de analizar el gasto en IA. La tabla siguiente muestra cómo se desarrolló la situación en cada una de ellas.
| Empresa | El mecanismo | ¿Qué pasó después? |
|---|---|---|
| Shopify | La primera clasificación de tokens conocida, utilizada para identificar a los grandes gastadores | Se ha rebautizado como «panel de uso» y se han añadido interruptores de seguridad para controlar a los agentes fuera de control. |
| Meta | «Claudeonomics», una clasificación elaborada por los propios empleados que recoge a los 250 mejores de entre más de 85 000 empleados, con títulos como «Token Legend». | 60. 2 billones de tokens en 30 días; la plataforma fue retirada a los pocos días de que aparecieran las noticias en la prensa. |
| Amazon | Kirorank, una clasificación no oficial que puntúa a los desarrolladores según su actividad en Kiro IA, con insignias de PhoneTool como premios. | Los empleados proporcionaban a los agentes tareas triviales e inventadas, y la tabla de clasificación se eliminó. |
| Uber | No hay clasificación; el código Claude se ha puesto a disposición de unos 5.000 ingenieros | El presupuesto anual para IA se agotó en cuatro meses, tras lo cual se estableció un límite mensual de 1.500 dólares por herramienta |
| Walmart | Code Puppy, un agente de IA interno con tokens inicialmente ilimitados | Se fijó una asignación de tokens por empleado después de que las solicitudes duplicadas dispararan los costes |
La tendencia que se observa en esta tabla es constante. Las organizaciones que utilizaron los datos de los tokens para investigar los gastos elevados mantuvieron una señal válida. Otras que los utilizaron para clasificar a las personas perdieron esa señal en el plazo de un trimestre.
¿Cómo inflaron los ingenieros su uso de tokens?
Los ingenieros inflaron su uso de tokens generando actividades de IA costosas que nunca planearon lanzar. The Pragmatic Engineer informó sobre este comportamiento en Meta, Microsoft y Salesforce, y identificó cuatro tácticas comunes. Ninguna de ellas implicaba mala intención. La gente simplemente veía un número visible, se preocupaba por los despidos y asumía que un uso intensivo de la IA les protegería:
- Plantear preguntas innecesarias al agente: Los ingenieros preguntaron a la IA sobre código que ya estaba documentado. El modelo leyó los documentos y devolvió respuestas repetitivas y erróneas, al tiempo que consumía un gran número de tokens.
- Creación de prototipos desechables: Crearon funciones que nunca quisieron utilizar, recibieron unas cuantas indicaciones adicionales y, a continuación, eliminaron la rama.
- Utilizar el agente para todo: Le asignaban a la IA tareas que podían realizar más rápido a mano, con el único fin de aumentar su uso.
- Ejecución de agentes en paralelo: Configuraron varios agentes para que revisaran y debatieran el trabajo de los demás, lo que generó largos registros, pero ningún software funcional.
Muchos ingenieros comprobaban cuánto gastaban sus compañeros. A continuación, consumían lo justo para situarse ligeramente por encima de la media. Más que estar en el primer puesto, lo que no querían era que se les señalara por no utilizar lo suficiente la IA.
En Amazon, los empleados asignaban tareas triviales e inventadas a los agentes de IA para aumentar sus puntuaciones en el Kirorank. Esto incrementó los costes de la nube sin generar ningún resultado empresarial. Cuando Amazon retiró la tabla de clasificación, el vicepresidente sénior Dave Treadwell explicó al personal que se había creado con buenas intenciones. A continuación, pidió sin rodeos: «Por favor, no utilicéis la IA solo por el mero hecho de usarla».
Como parte de este cambio, Amazon ahora realiza el seguimiento de si el código generado por IA funciona y aporta valor. El consumo de tokens no es su principal prioridad.
¿Cuánto les costó el «tokenmaxxing» a las empresas?
Es plausible que el «tokenmaxxing» le haya costado a Meta más de 100 millones de dólares en un solo mes y haya agotado el presupuesto anual de IA de Uber en cuatro. La estimación de Meta se basa en una simple operación aritmética. Según los precios de la API de Claude Opus (en el momento en que se publicó la noticia), 60,2 billones de tokens costarían aproximadamente 900 millones de dólares. Una empresa del tamaño de Meta negocia importantes descuentos, pero, aun así, la factura podría alcanzar las nueve cifras.
Uber ofrece la imagen más clara del coste, ya que nunca mantuvo una tabla de clasificación. La empresa proporcionó a unos 5.000 ingenieros herramientas de programación «agentic» sin un modelo de gasto. En un mes, la proporción de ingenieros clasificados como usuarios «agentic» pasó del 32 % al 84 %. El presupuesto anual completo se agotó en cuatro meses .
El director técnico, Praveen Neppalli Naga, admitió que la empresa había «vuelto a empezar desde cero» en cuanto a sus hipótesis. El intervalo de las facturas mensuales era de 500 a 2 000 dólares por ingeniero, y la solución fue contundente: un límite mensual de 1 500 dólares por herramienta de programación y por ingeniero.
Cuando los ingenieros que realizan un trabajo similar gastan cantidades tan diferentes, esa variación pone de manifiesto que nadie había definido qué se consideraba un buen uso. Así que cada ingeniero se inventó su propia definición. El director de operaciones de Uber, Andrew Macdonald, reconoció este punto y declaró a Fortune que era «muy difícil trazar una línea divisoria» entre el código asistido por IA y las funciones útiles que realmente se lanzaban al mercado.
El Informe sobre el impacto de la IA de LeadDev reveló que solo el 19 % de los responsables de ingeniería dan una valoración positiva al «tokenmaxxing». El 57 % de ellos afirma que no logra medir el valor real.
He aquí por qué el dinero se mueve tan rápido: un agente que planifica un cambio en el código lee el repositorio, invoca herramientas, ejecuta pruebas y vuelve a intentarlo hasta que lo consigue. Un solo bucle puede consumir decenas de miles de tokens, y las lecturas de la caché de comandos hacen que esa cifra aumente aún más.
Los equipos financieros presupuestaban la IA como si se tratara de una licencia de usuario. Pero, en realidad, se comporta como la computación en la nube. La misma discrepancia contable surge cuando los equipos montan una pila de IA con varios proveedores sin asignar a nadie la propiedad de la factura. Se trata del mismo tipo de fallo que la proliferación descontrolada de herramientas, pero un nivel por encima.
¿Qué es el «tokenminning»?
El «tokenminning» es la práctica de minimizar el consumo de tokens de IA y considerar el bajo uso como la meta. Tal y como comentamos en la introducción, se trata de una corrección excesiva que, además, tiene resultados igualmente deficientes. El nombre es la abreviatura de «token minimizing» (minimización de tokens) y surgió como corrección al «tokenmaxxing». El New York Times informó de este cambio en varias empresas.
Meta comunicó a sus empleados que limitaría el uso de la IA tras un «aumento exponencial» de los costes. Uber limitó el gasto mensual, Walmart estableció límites de uso de las herramientas de IA, y tanto Amazon como Meta retiraron sus clasificaciones. En cuestión de semanas, las mismas empresas que habían elogiado a sus mayores usuarios de IA estaban enseñando a todo el mundo a racionarla.
Esta corrección repite el error que se pretendía solucionar. La ley de Goodhart lo explica a la perfección: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Así pues, si se establece el uso de tokens de IA como meta, la gente encontrará formas de optimizar esa métrica, incluso a costa de socavar la intención original. La ley de Goodhart advierte contra el «tokenmaxxing» y el «tokenminning».
Si recompensas a un equipo por quemar tokens, quemará tokens que no necesita. Si recompensas a un equipo por ahorrar tokens, se saltará la ejecución de IA que habría detectado un error. O dividirá una sesión exhaustiva en tres sesiones más baratas, cada una de las cuales ofrecerá una respuesta menos profunda. Ambos equipos alcanzan sus objetivos de uso de tokens, mientras que la calidad del trabajo real empeora.
El control de costes en sí mismo no es el error. Al igual que en el ejemplo de Uber, el límite mensual de 1.500 dólares es una decisión presupuestaria tomada después de que la empresa agotara el presupuesto de un año en cuatro meses. Pero realizar un ajuste solo resuelve un problema financiero. No responde a la pregunta de si los tokens sirvieron para adquirir algo útil.
La solución pasa por diferenciar entre dos tipos de números: las señales que se observan y los resultados a los que se aspira. El uso de tokens, la tasa de adopción y la proporción de código escrito por IA son señales que muestran lo que está ocurriendo dentro del sistema. Son útiles a la hora de investigar un problema, pero no constituyen buenas metas. Y es que cada una de ellas puede variar considerablemente sin que el cliente note ninguna diferencia.
Una organización debería centrarse, en cambio, en los resultados. Siguen la misma lógica que cualquier conjunto bien diseñado de KPI de desarrollo de software: relacionar una señal temprana con el resultado que se supone que debe predecir. El panel de conversión de Shopify es la plantilla: los mismos datos, pero sin que la posición de nadie en una tabla de clasificación esté vinculada a ellos.
Neil Dhar, vicepresidente sénior de IBM Consulting, describió cómo se extiende la confusión en un artículo sobre los costes de la IA.
#Tokenmaxxing ha acaparado los titulares últimamente. Se trata de la apuesta de las organizaciones por utilizar tanta IA como sea posible, lo más rápido posible, convirtiendo ese uso en un indicador de valor. Ahora ha llegado la hora de pagar la factura. A medida que los costes de la IA superan los beneficios, el instinto es recortar. Pero recortar el gasto por sí solo no resolverá el problema subyacente del retorno de la inversión.
#Tokenmaxxing ha acaparado los titulares últimamente. Se trata del impulso de las organizaciones por utilizar tanta IA como sea posible, lo más rápido posible, convirtiendo ese uso en un indicador de valor. Ahora ha llegado la hora de pagar la factura. A medida que los costes de la IA superan los beneficios, el instinto es recortar. Pero recortar el gasto por sí solo no resolverá el problema subyacente del retorno de la inversión.
Según IBM, la solución consiste en tratar el uso como una señal y asociarlo a un resultado que no se pueda falsificar.
¿Un mayor uso de tokens implica una mayor productividad?
No, un uso elevado de tokens no significa una alta productividad. Los mayores conjuntos de datos disponibles muestran que ambos factores evolucionan de forma independiente. Una investigación de la plataforma de inteligencia para desarrolladores DX reveló que la adopción de la IA se encuentra cerca de la saturación, mientras que las ganancias de productividad medidas se mantuvieron estables.
Laura Tacho, directora técnica de DX, compartió los números. Entre los desarrolladores, el 92,6 % utiliza ahora un asistente de programación basado en IA al menos una vez al mes, y aproximadamente el 75 % lo utiliza semanalmente. La IA escribe el 26,9 % del código de producción. Sin embargo, el ahorro de tiempo declarado por los propios usuarios se ha mantenido en unas cuatro horas a la semana durante más de un año. Y la ganancia inicial de productividad del 10 % nunca aumentó.
El uso siguió aumentando mientras que los resultados se mantuvieron estancados. Cualquier métrica de seguimiento del uso ha estado elaborando informes sobre un éxito que nunca se produjo.
El informe DORA de Google Cloud explica por qué las mismas herramientas producen resultados tan diferentes. El informe reveló que la adopción de la IA mejoró la velocidad de entrega, pero perjudicó la estabilidad de la misma. El informe describe la IA como un amplificador: magnifica los puntos fuertes de las organizaciones bien gestionadas y las debilidades de aquellas que tienen dificultades.
Los propios datos de DX muestran cómo funciona este amplificador. En un grupo de 67 000 desarrolladores, algunas organizaciones vieron cómo se duplicaban las incidencias relacionadas con los clientes, mientras que otras las redujeron a la mitad, utilizando las mismas herramientas durante el mismo periodo. Tacho atribuye la responsabilidad a lo que indican los datos:
En realidad, se trata de un problema de gestión. El bombo publicitario daba a entender que el mero hecho de probar la IA reportaría beneficios automáticamente. Pero, hasta ahora, la mayoría de las herramientas se han utilizado para tareas de programación individuales. Para ver un impacto real, necesitamos utilizar la IA a nivel organizativo, no solo para tareas aisladas.
En realidad, se trata de un problema de gestión. El bombo publicitario daba a entender que el mero hecho de probar la IA reportaría beneficios automáticamente. Pero, hasta ahora, la mayoría de las herramientas se han utilizado para tareas de programación individuales. Para ver un impacto real, tenemos que utilizar la IA a nivel organizativo, no solo para tareas aisladas.
Hay un segundo problema subyacente al primero: las personas evalúan erróneamente la aceleración que les proporciona la IA. El laboratorio de investigación sin ánimo de lucro METR llevó a cabo un ensayo controlado aleatorio. Dieciséis desarrolladores experimentados de código abierto completaron 246 problemas reales en repositorios que habían mantenido durante una media de cinco años. Antes de empezar, los desarrolladores predijeron que la IA les haría un 24 % más rápidos. Al terminar, estimaron que les había hecho un 20 % más rápidos. El cronómetro indicó que fueron un 19 % más lentos.
Hay un segundo problema subyacente al primero: las personas evalúan erróneamente la mejora en la velocidad que les aporta la IA. El laboratorio de investigación sin ánimo de lucro METR llevó a cabo un ensayo controlado aleatorio. Dieciséis desarrolladores experimentados de código abierto completaron 246 problemas reales en repositorios que habían mantenido durante una media de cinco años. Antes de empezar, los desarrolladores predijeron que la IA les haría un 24 % más rápidos. Al terminar, estimaron que les había hecho un 20 % más rápidos. El cronómetro indicó que habían sido un 19 % más lentos.
En una actualización posterior, el laboratorio explicó que su siguiente experimento se topó con efectos de selección que no pudo corregir. También señaló que ahora es probable que los desarrolladores sean realmente más rápidos con la IA, gracias en gran medida a las herramientas agentivas. Lo que queda claro: la productividad autodeclarada no sustituye a la productividad medida, y la diferencia entre ambas puede ir en cualquier dirección.
¿Qué deberías medir en lugar del uso de tokens?
En lugar del uso de tokens, mide los resultados a nivel de equipo y, posteriormente, a nivel de organización. Considera el uso de tokens como un indicador de costes que no se utiliza para clasificar a nadie. Lo que importa son los resultados obtenidos.
Una regla práctica a seguir: asocia cada señal que publiques a un resultado que no pueda inflar. Un equipo puede quemar tokens sin lanzar nada al mercado. Sin embargo, no puede falsificar una disminución de la tasa de fallos.
| Métrica | Tipo | Cómo utilizarlo |
|---|---|---|
| Tokens consumidos por equipo | Señal | Esté atento a los picos de coste y a los bucles descontrolados de los agentes; nunca clasifique a las personas en función de ello. |
| Tasa de adopción de herramientas de IA | Señal | Comprueba que el lanzamiento haya llegado al público y, a continuación, deja de prestarle atención. |
| Porcentaje de código creado por IA | Señal | Contexto para la planificación de la capacidad de revisión de código de código |
| Modificar la tasa de fallos | Resultado | Compáralo con cualquier aumento de velocidad que se afirme; los problemas aparecen aquí primero. |
| Solicitudes de validación combinadas por equipo | Resultado | Solo a nivel de equipo, siempre equilibrado con una métrica de calidad |
| Índice de experiencia del desarrollador | Resultado | Detecta los problemas culturales antes de que la gente empiece a marcharse |
| Porcentaje de tiempo dedicado a nuevas capacidades | Resultado | Relaciona el esfuerzo de ingeniería con el valor de la empresa |
Esta estructura se basa en marcos de medición en los que ya confían los responsables de ingeniería. DORA abarca la velocidad de entrega y la estabilidad, y su conclusión de que la IA potencia ambas es la razón por la que esta combinación es importante.
El DX Core 4 mide cuatro dimensiones: velocidad, eficacia, calidad e impacto empresarial. Abi Noda y Laura Tacho lo desarrollaron junto con Nicole Forsgren y Margaret-Anne Storey, las investigadoras responsables de DORA, SPACE y DevEx. Las cuatro dimensiones se contraponen entre sí de forma intencionada.
Un equipo que mejora un aspecto a costa de otro pone de manifiesto inmediatamente esa disyuntiva. Ninguno de los dos marcos incluye una métrica de tokens, y ninguno de los dos la ha añadido.
Hay tres reglas que hacen que esta combinación funcione en la práctica:
- Agrupa siempre los datos a nivel de equipo. Cuando una señal se asocia a un nombre concreto, se convierte en un objetivo, y la era de las clasificaciones vuelve en un abrir y cerrar de ojos. Los equipos pueden absorber las diferencias en el uso que hacen los miembros de la IA. Los individuos se ocuparán de gestionar los números por su cuenta.
- Nunca muestres un indicador sin su resultado correspondiente en la misma vista. Un panel que solo muestra el gasto en tokens invita a realizar optimizaciones. El gasto en tokens junto a la tasa de fracaso de los cambios plantea una pregunta más pertinente: ¿está funcionando el gasto?
- Mantén las señales totalmente al margen de las evaluaciones de rendimiento . Cuando un número de uso influye en la remuneración o en una promoción, entra en juego la Ley de Goodhart, independientemente de la dirección en la que apunte el incentivo. Utiliza los datos de uso para investigar, no para juzgar el mérito individual.
¿Cómo se establece una política de uso de la IA que los empleados no puedan manipular?
Para establecer una política de uso de la IA que los empleados no puedan manipular, elimina todos los números visibles del historial de cada persona y toma cinco decisiones:
1. Decide para qué sirve ese número antes de recopilarlo
Cada métrica de la política necesita un objetivo por escrito antes de que se publique el primer panel. La tabla de clasificación de Shopify funcionó en su primera etapa. La dirección la utilizó para entablar conversaciones con los usuarios que más gastaban sobre lo que estaban creando. El número sirvió para iniciar una investigación. En cuanto ese mismo número cierra una, sacando conclusiones sobre una persona en lugar de preguntar algo sobre el trabajo, se convierte en una puntuación. Y las puntuaciones se gestionan.
Anota tres aspectos por cada métrica:
- El desencadenante: ¿Qué cambio en el gasto en tokens da indicación de tomar medidas (un repunte de tres veces respecto a la semana anterior o que un equipo duplique su nivel de referencia)?
- La acción: quién pregunta qué y a quién («el director ejecutivo pregunta al equipo qué están desarrollando», no «el informe se envía al vicepresidente»)
- La inacción: Para qué nunca se utilizará ese número, expresado con la misma claridad
La línea de «no intervención» es la que más trabajo genera, porque los empleados ponen a prueba la política comparándola con ella. Si la respuesta sincera a «¿qué pasa cuando el gasto se dispara?» tiene que ver con la posición de alguien, has creado una tabla de clasificación con pasos adicionales.
2. Establece el presupuesto a nivel de equipo
Un presupuesto común para el equipo sustituye al límite individual, y la diferencia es de comportamiento, no contable. La variación mensual de entre 500 y 2.000 dólares de Uber entre ingenieros que realizan un trabajo similar muestra lo que ocurre cuando no existe un punto de referencia común. Cada uno inventa su propia definición de lo que es razonable. Los presupuestos comunes funcionan igual que cualquier otro esfuerzo por reunir el gasto disperso en IA en un único lugar controlable.
El «envelope» te ofrece tres cosas que un límite por persona no puede ofrecerte:
- Elasticidad: Una migración realmente costosa puede consumir más este mes, mientras que un sprint rutinario consume menos
- Seguridad psicológica: Nadie interpreta su propio elemento presupuestario como una evaluación de rendimiento, porque no hay ningún elemento con su nombre.
- Autocontrol: el propio equipo detecta los gastos excesivos, ya que el presupuesto tiene un uso compartido y su visibilidad es alta para todos sus miembros.
Calcula el primer límite a partir de los datos observados. Toma la media de los últimos tres meses del equipo y añade un margen para un proyecto costoso. Un límite fijado a ojo se supera en la segunda semana, lo que deja claro a todo el mundo que la política es meramente decorativa.
3. Haz visible la ruta más costosa
Muestra a los ingenieros el coste de cada ejecución en lugar de limitar lo que pueden gastar. Las ejecuciones de Agentic que se repiten en bucle tras fallos en las pruebas son las que agotan los presupuestos, lo que hace que el límite máximo adquiera especial relevancia. Otra opción es mostrar el coste por ejecución al ingeniero que ha sido el desencadenante, sin realizar la elaboración de informes sobre él.
Un ingeniero que ve cómo un bucle de reintentos quema 40 dólares arreglará el bucle. Por otro lado, un ingeniero que teme a la elaboración de informes dejará de utilizar el agente por completo, incluso en aquellas ocasiones en las que la costosa ejecución fue la decisión correcta.
Los cortacircuitos de Shopify funcionan así: el sistema detecta la anomalía y la persona más cercana al trabajo decide qué hacer. La visibilidad cambia el comportamiento más rápido que un límite máximo, y mantiene disponible la ejecución costosa pero correcta cuando el trabajo justifica el gasto.
4. Separar la meta de adopción de la IA de la evaluación del rendimiento
Deja la separación por escrito, porque las garantías verbales no sobreviven a un ciclo de despidos. El ingeniero de Microsoft que describió a «The Pragmatic Engineer» cómo inflaron sus propias métricas de uso no buscaba ningún premio. Simplemente quería evitar que le pusieran un rótulo en un año marcado por despidos relacionados con la IA.
Si la gente cree que los datos de uso llegan a una reunión de calibración, gestionará esos datos, diga lo que diga cualquiera en voz alta.
El texto de la política necesita exactamente dos líneas:
- Si los datos de uso pueden aparecer en las conversaciones sobre rendimiento (un sí o un no, no «depende del contexto»)
- Adónde van a parar los datos, para que nadie llene el silencio con una suposición aún peor
A continuación, ten en cuenta ambos aspectos. El primer ingeniero que vea aparecer los datos de uso en una revisión se lo contará a todo el mundo, demostrando así que la métrica es redundante.
5. Revisa el emparejamiento cada trimestre
Cada trimestre, pregúntate si cada diagnóstico sigue explicando el resultado al que está asociado. La fijación de precios de los modelos, el comportamiento del almacenamiento en caché y la arquitectura de los agentes cambian más rápido que un ciclo de planificación anual.
La forma en que los equipos aplican la IA a la planificación y la elaboración de informes no deja de cambiar. Un recuento de tokens que significaba una cosa en enero tiene un significado diferente en junio, tras dos bajadas de precio y una actualización de los agentes.
La revisión ofrece resultados sinceros para cada métrica: o bien sigue prediciendo el resultado esperado, o bien necesita recalibrarse en función de los nuevos precios, o bien ha dejado de explicar nada y se retira sin más. Los equipos son los que más se resisten a retirarla. Sin embargo, es un paso importante, ya que una métrica que ha perdido su significado es precisamente el tipo de número sobre el que se construyó la era de las clasificaciones.
Errores comunes que cometen los equipos al medir la adopción de la IA
Los cuatro errores más comunes son considerar la adopción como la meta final, confiar en los ahorros de tiempo declarados por los propios usuarios, publicar clasificaciones individuales y medir la velocidad sin tener en cuenta la estabilidad. Puedes detectar cada uno de ellos antes de que te salga caro.
1. Considerar la adopción como la meta
El panel de control de implementación marca un 90 %, los responsables declaran que la iniciativa de IA está completada y nadie se pregunta qué ha cambiado en las fases posteriores. Los datos de DX pusieron de manifiesto esta trampa a gran escala: un 92,6 % de adopción con una productividad estancada en el 10 %. La adopción solo confirma que las herramientas llegaron a las personas. No dice nada sobre qué han cambiado esas herramientas.
La solución: Retira el gráfico de adopción una vez finalizado el lanzamiento y sustitúyelo por un par de señales y resultados.
2. Confiar en los ahorros de tiempo declarados por los propios usuarios
Una encuesta indica que el equipo ahorra cinco horas a la semana, pero la duración del ciclo no ha variado en dos trimestres. La prueba de METR muestra por qué estos dos números no coinciden: los desarrolladores que trabajaban de forma apreciablemente más lenta con la IA seguían estimando una aceleración del 20 % después. Lo que la gente cree y lo que registra el cronómetro son dos mediciones diferentes.
La solución: Mantén la encuesta sobre la experiencia de los desarrolladores, donde la percepción es importante. Utiliza datos del sistema para cualquier afirmación relacionada con el tiempo.
3. Publicar una clasificación individual solo por diversión
Alguien lo crea en una wiki interna en una tarde, le pone títulos divertidos y el equipo lo disfruta de verdad durante unas tres semanas. Después, el incentivo toma el control. Tanto la «Claudeonomics» de Meta como el «Kirorank» de Amazon comenzaron como una diversión de base. Ambas empresas los retiraron en cuanto el juego superó el entusiasmo inicial.
La solución: Agrupa los datos a nivel de equipo o no los publiques.
4. Medir la velocidad sin medir la estabilidad
El rendimiento aumenta, todo el mundo lo celebra y el volumen de incidencias se dispara en el panel de control de otro equipo. El informe DORA identificó precisamente esta dicotomía: la velocidad mejora, mientras que la estabilidad empeora. Mantener ambos números en paneles separados hace que el problema pase desapercibido.
La solución: Coloca la tasa de fallos en los cambios en la misma pantalla que cualquier métrica de velocidad, no en un informe de fiabilidad independiente que nadie consulta.
Cómo hacer el seguimiento del impacto de la IA en ClickUp
Para hacer un seguimiento del impacto de la IA en ClickUp, mide los resultados junto al trabajo en sí: las tareas, los sprints y los entregables que se suponía que la IA debía agilizar. La mayoría de los paneles de control de tokens se encuentran en la consola del proveedor, lejos del trabajo al que hacen referencia. Trasladar las métricas de resultados al entorno de trabajo cierra esa brecha.
La relación entre señal y resultado que se ha mencionado anteriormente se refleja directamente en la plataforma:
- Consulta la velocidad y la calidad en una sola pantalla. Crea una vista en los paneles de ClickUp con tarjetas de velocidad de sprint, duración del ciclo y flujo acumulativo junto a una lista de tareas filtrada por reelaboraciones y incidencias. La supuesta ganancia de velocidad y su coste en calidad dejan de aparecer en informes separados, lo que en la práctica constituye la regla de emparejamiento.
- Compara el trabajo asistido por IA con el resto. Añade un menú desplegable a través de «Campos personalizados» que marque las tareas como «asistidas por IA». A continuación, compara la duración del ciclo y las tasas de reelaboración entre los dos grupos. Esto aporta pruebas que ninguna consola de facturación puede ofrecer, ya que la consola solo sabe lo que se ha gastado, no lo que se ha entregado.
- Comprueba las afirmaciones sobre el ahorro de tiempo comparándolas con el tiempo registrado. Compara las duraciones estimadas con el tiempo real registrado en las tareas y agrupa ambos datos en una hoja de horas o en una tarjeta de elaboración de informes de tiempo en el mismo panel. Si la IA realmente acelera un flujo de trabajo, el tiempo registrado en tareas comparables se reducirá. En caso de que solo parezca más rápido, los números lo confirmarán.
- Obtén respuestas directamente del trabajo en lugar de elaborar informes. Hazle a ClickUp Brain, una IA contextual para el entorno de trabajo, una pregunta como «¿qué proyectos se retrasaron después de que cambiáramos el proceso de revisión?». Te responderá a partir de tareas en curso, paneles, documentos, chats y aplicaciones conectadas, en lugar de una presentación trimestral.
- Mantén al agente y el resultado en un mismo sistema. Los equipos que utilizan agentes de IA para tareas operativas rutinarias pueden ejecutar «Superagentes» dentro del entorno de trabajo. Estos compañeros de equipo asistidos por IA actualizan estados, publican seguimientos y redactan informes de progreso según un calendario o bajo demanda. El trabajo del agente y el registro de si ha sido de ayuda se encuentran en un mismo lugar, lo que elimina un paso de conciliación.
Si tu equipo está implementando agentes, aquí te mostramos cómo crear uno con una tarea definida:
Observa el recuento de tokens sin puntuar a las personas que los utilizan
Toda la historia se reduce a una regla: utiliza los datos de los tokens para plantear preguntas, nunca para calificar a las personas. Shopify se preguntó «¿qué están creando nuestros principales gastadores?» y descubrió agentes fuera de control y incidencias en la infraestructura. Meta y Amazon se preguntaron «¿quién utiliza más la IA?» y obtuvieron tareas falsas, malgastaron millones y se encontraron con clasificaciones inútiles.
Así pues, hay tres cosas pendientes este trimestre. Traslada el seguimiento de los tokens al nivel del equipo y elimina cualquier dato que muestre el nombre de una persona. Establece por escrito, en la política, que los datos de uso nunca se tengan en cuenta en una evaluación de rendimiento. E incluye una métrica de calidad (la tasa de fallos en los cambios es la más sencilla) en la misma pantalla que todas las métricas de velocidad que presentes.
Si quieres que esa pantalla esté junto al trabajo real en lugar de en una herramienta de elaboración de informes independiente, empieza a utilizar ClickUp de forma gratuita y crea el panel antes de que lo necesites.
Preguntas frecuentes sobre el «tokenmaxxing» (FAQ)
¿En qué consiste la regla del 30 % para el «tokenmaxxing»?
No existe una «regla del 30 %» oficial específica para el «tokenmaxxing». La expresión suele ser una forma abreviada de referirse a dos conclusiones distintas que la gente suele confundir: que la IA tiende a aumentar la productividad de ingeniería medida en aproximadamente un 10 %, no un 30 %, y que los desarrolladores suelen predecir ganancias de entre el 20 % y el 30 % que luego no se materializan. Considera cualquier porcentaje fijo como un indicador que hay que investigar, nunca como un objetivo que hay que alcanzar.
Un millón de tokens equivale aproximadamente a 750 000 palabras de texto en inglés, ya que un token tiene una longitud media de unas tres cuartas partes de una palabra. El coste depende totalmente del modelo y de la distribución entre entrada y salida. Según las tarifas de los modelos de vanguardia de 2026, tiene un intervalo que va de unos pocos dólares a unas pocas decenas de dólares por millón. Las sesiones «agenticas» consumen millones de tokens rápidamente porque cada bucle vuelve a leer el contexto, y las lecturas de la caché de indicaciones se suman al recuento.
«Tokenmaxxing» combina «token» con el sufijo de Internet «-maxxing», que significa maximizar una característica. Se extendió por los círculos de ingeniería a principios de 2026 después de que se filtraran a la prensa las clasificaciones internas de tokens de Meta y Amazon. Business Insider lo calificó como «el nuevo debate sobre la IA en Silicon Valley » en abril de 2026. Las clasificaciones públicas como Viberank y tokenmaxxing.sh adoptaron entonces el rótulo, clasificando a desarrolladores individuales de todo el mundo según su gasto en API.
En gran medida, sí. La revista Fortune declaró el fin del «tokenmaxxing» en mayo de 2026, después de que Meta, Amazon, Microsoft y Uber dieran marcha atrás o eliminaran sus clasificaciones de tokens. El Informe de Impacto de la IA de LeadDev reveló que solo el 19 % de los encuestados otorgó una valoración positiva al «tokenmaxxing» para medir el valor de la IA, mientras que el 57 % afirmó que fracasa rotundamente. Las clasificaciones públicas de aficionados persisten, pero como un juego, no como una práctica de gestión.
No existe un punto de referencia establecido. Tras la implantación de Uber, el intervalo de las facturas mensuales era de 500 a 2.000 dólares por ingeniero, antes de que la empresa limitara el gasto a 1.500 dólares por herramienta. El director ejecutivo de Nvidia, Jensen Huang, ha defendido que un ingeniero que gana 500.000 dólares debería consumir 250.000 dólares en tokens al año, pero lo más probable es que se trate de una provocación, no de una norma. Los resultados muestran una gran variabilidad entre trabajos comparables, lo que significa que nadie ha definido cómo es un uso adecuado.
La programación «vibe» es una forma de trabajar: delegar la implementación a un agente de IA y orientarse por los resultados. El «tokenmaxxing» es una forma de medir: tratar los tokens que se consumen como prueba de productividad. Se puede programar «vibe» de forma eficiente o derrochadora; el «tokenmaxxing» premia la versión derrochadora porque solo cuenta el consumo. Las empresas que limitaron los tokens para frenar el «tokenmaxxing» a menudo penalizaron, en el proceso, el trabajo legítimo de los agentes.