Los tokens no son moneda. Son líneas de código con factura adjunta.

Nisha Talagala ha publicado en Forbes un texto introductorio sobre los tokens en el que sostiene que los tokens —la unidad con la que se mide y se cobra el consumo de los LLM— se están convirtiendo en una unidad de negocio fundamental. Introduce el término tokenmaxxing, señala que ya hay empresas que evalúan públicamente a sus empleados según su uso de tokens y plantea un marco sereno: presupuestos, seguimiento y decisiones de compromiso. Como introducción al tema, está bien. Como hoja de ruta para cualquier organización de ingeniería que tenga que cumplir un presupuesto, es la versión más cortés de una idea muy peligrosa.

La idea peligrosa es esta: que el uso de tokens mide el trabajo. No lo mide. Mide la factura. Para quien ha tenido que defender una partida de coste de IA ante un CFO y una guardia de SRE en la misma semana, el marco importa más que las cifras —y Forbes solo acierta a medias.

Lo que Forbes acierta

Tres cosas del artículo son correctas y deberían figurar ya en la hoja de ruta de cualquier CTO:

1. El gasto en tokens es real y va a más. El artículo cita que una sola revisión de un correo consume unos 100 tokens, con un coste cercano a 0,25 céntimos de dólar por tarea. Multiplica eso por cada empleado, cada flujo, cada reintento, cada agente encadenado, y la partida pasa de «ruido contable» a «negociación con el CFO» en un solo trimestre. Las empresas que empezaron repartiendo tokens ilimitados a cada empleado están, como era previsible, racionándolos.
2. No todos los tokens son iguales. Forbes acierta al señalar que un token no es comparable entre proveedores, modelos, tareas ni momentos distintos. El token de un modelo de razonamiento puntero no equivale, comercialmente, al de un modelo abierto pequeño, por mucho que contabilidad quiera sumarlos.
3. Hacen falta herramientas. El seguimiento de tokens va a generar la misma oleada de proveedores que el gasto en cloud hace una década: un mercado de FinOps para tokens. Ese mercado ya se está formando.

Esas tres observaciones bastarían para justificar el artículo. El problema es la cuarta idea, la que viene pegada a las anteriores.

Donde Forbes se equivoca: el token como indicador de productividad

El artículo describe —con poco espíritu crítico— una tendencia según la cual las empresas tratan los tokens por empleado y unidad de tiempo como una métrica de productividad. Incluso llega a compararlo con el presupuesto de viajes de un comercial: en ese marco, el empleado que gasta de menos su presupuesto de tokens equivale al comercial que no concierta visitas. Gastar de menos se convierte en una señal negativa.

Esto es la ley de Goodhart con un disfraz nuevo. Cuando una medida se convierte en objetivo, deja de ser una buena medida. El día que le dices a un ingeniero que su uso de tokens cuenta —formalmente, lo evalúa la dirección, pesa en la evaluación de desempeño—, no has medido nada sobre su productividad. Has creado un nuevo mercado de ruido.

Forbes reconoce que el sistema es fácil de manipular («abusar de los tokens es trivial»), pero lo trata como una cuestión menor y manejable. No lo es. La historia de las métricas de ingeniería es, exactamente, la historia de este patrón de fallo:

• Líneas de código por desarrollador. Se midieron durante dos décadas. Se optimizaron escribiendo más líneas de código. El premio: bases de código en Fortran 77 que ningún humano podía mantener. Lo que se pretendía medir —el valor creado— acabó descorrelacionado de la métrica y, al final, en correlación inversa con ella. He defendido este mismo argumento sobre las métricas de productividad, y la mecánica es idéntica.
• Tickets cerrados por sprint. Se optimizó partiendo tickets. O cerrando primero los triviales. O inflando los sprints. Los equipos que mejor manipulaban la métrica eran los peores entregando.
• Cobertura de tests. Se optimizó escribiendo tests que recorren líneas sin comprobar el comportamiento. La cobertura subió, los defectos subieron y los ingenieros fueron ascendidos.

«Tokens consumidos por empleado y mes» pertenece a este linaje. Y es peor, porque cada token manipulado le cuesta dinero real a un proveedor real. Las típicas métricas que te hacían quedar bien no costaban dinero y salia gratis que las "tunearas". El tokenmaxxing es manipulación de pago, con la factura remitida al departamento de finanzas y eso no es gratis.

La medida honesta es más difícil, y no se cuenta en tokens

Lo que de verdad quieres saber de un ingeniero que usa herramientas de IA es, más o menos, esto:

• ¿Se entregó el cambio?
• ¿Se entregó bien?
• ¿Se entregó más rápido que sin la herramienta?
• ¿El ingeniero aprendió algo reutilizable, o subcontrató el pensamiento?
• ¿El código resultante es revisable, mantenible y hay alguien que responde de él?

Ninguna de las cinco preguntas se responde en tokens. Las cuatro primeras se responden con métricas DORA honestas: frecuencia de despliegue, lead time, change failure rate y MTTR. La quinta solo se responde con revisión de código y tiempo. No hay atajo, y los tokens no son ese atajo disfrazado.

Forbes acierta cuando habla del «multiplicador de IA»: la idea de que es la pericia humana la que da valor al token. De acuerdo. Pero esa concesión socava todo el marco de presupuesto-de-tokens-como-productividad que defiende justo al lado. Si el multiplicador es el humano, la unidad relevante es resultado por ingeniero, no tokens por ingeniero. El gasto en tokens es un coste de insumo, como el cloud, la electricidad o el espacio de oficina; y a nadie lo ascienden por gastar más en electricidad.

Lo que los tokens son en realidad: una partida de cloud con peores ajustes por defecto

Si descartas el error de tratarlos como métrica de productividad, lo que queda es correcto y merece una buena gestión. Los tokens entran en la misma curva de madurez que el gasto en cloud, y el manual de la década del FinOps se aplica casi sin cambios:

1. Asigna el gasto a resultados, no a personas. Un token que consume un agente de CI al detectar una regresión en producción no es comparable al token que consume un ingeniero pidiéndole a un LLM que le reescriba un mensaje de Slack. Etiqueta los tokens por flujo de trabajo, no por empleado, igual que etiquetabas las instancias EC2 por servicio y no por la persona que las arrancó.
2. Pon cuotas por ruta, no por persona. El sobrecoste interesante en una organización con IA rara vez es un empleado parlanchín. Es un agente descontrolado que, dentro de un pipeline, llama en bucle a un modelo puntero con reintentos y backoff. Los presupuestos por empleado no lo cazan; los presupuestos por herramienta y por flujo, sí. Igual que los presupuestos por servicio cazaron aquella lambda que hacía 3.000 lecturas contra Aurora a las tres de la madrugada.
3. Arbitra precios entre modelos. Forbes acierta al decir que proveedores y precios fluctúan; la respuesta correcta es una capa de enrutamiento que mande cada tarea al modelo más barato que supere el listón de calidad de esa tarea concreta, y no un contrato fijo con un único proveedor puntero a precio de catálogo. La economía de los modelos fundacionales premia las decisiones de construir-o-comprar según la carga de trabajo, no estandarizarlo todo en la opción más cara.
4. Observabilidad antes que incentivos. La mayoría de las organizaciones está a punto de tomar decisiones normativas sobre los tokens antes de tener una atribución fiable por tarea. Es el orden equivocado. Resuelve primero la atribución —por servicio, por flujo, por reintento, por resultado de cara al usuario— y después habla de presupuestos. Si no, acabarás poniendo cuotas sobre el ruido.

Esto es FinOps con otra unidad. No es —ni debería ser— gestión del desempeño.

Lo que el «tokenmaxxing» dice en realidad de una organización

Si una organización de ingeniería acaba premiando el consumo de tokens —o, peor aún, descubre que sus ingenieros hinchan ese consumo para parecer productivos—, el problema no es de los ingenieros. Es de la dirección que eligió la métrica. El tokenmaxxing es un síntoma, y la enfermedad de fondo es la misma que veo en todos los clientes que no han cultivado una verdadera cultura de medición: la dirección quiere una sola cifra, finanzas quiere una sola cifra, y la factura del LLM ofrece, muy oportunamente, una sola cifra que además sube.

Una organización de ingeniería seria se resiste a esa simplificación. Mantiene en paralelo, como mínimo, dos líneas de análisis:

• Línea de coste. ¿Cuánto nos hemos gastado en IA, desglosado por flujo, por equipo, por modelo y por tipo de reintento? ¿Dónde está el desperdicio? ¿Está el router haciendo su trabajo? ¿Hay agentes en bucle?
• Línea de resultado. ¿Qué se ha entregado? ¿Qué no? ¿Cuál es el change failure rate? ¿Las PR hechas con IA tienen un perfil de defectos distinto al de las hechas sin ella? ¿La IA detecta más incidentes de los que provoca?

Si solo llevas la línea de coste, acabarás optimizando el consumo de tokens, y Forbes describe con precisión la clase de empresa en la que te vas a convertir. Si solo llevas la línea de resultado, no cazarás al agente descontrolado que te ha incendiado la factura de AWS. Necesitas las dos, y deben vivir en paneles distintos, revisados por personas distintas.

Lo que pondría delante de un CTO este trimestre

1. Atribución por flujo antes que presupuestos por empleado. Mientras no puedas nombrar los cinco flujos que más tokens consumen en tu stack, no tienes un problema de tokens que puedas resolver.
2. Un kill-switch por agente, el mismo que defiendo como innegociable para cualquier sistema agéntico en producción. Un bucle infinito en un agente ya es tanto un incidente financiero como uno de SRE.
3. Una capa de enrutamiento de modelos, aunque sea rudimentaria. Si todos los equipos llaman directamente al mismo modelo puntero, sin alternativa más barata para las tareas triviales, tu factura está pagando pereza de plataforma, no productividad de los ingenieros.
4. Una política de medición que excluya explícitamente los tokens de la evaluación individual. Por escrito. Y sin medias tintas. El primer día que un responsable felicite a un ingeniero por «haber consumido más tokens este trimestre», la métrica está muerta, y tu cultura, detrás.
5. Una partida presupuestaria para el desperdicio. Una parte del gasto en tokens será exploratoria, sin recorrido e irremediablemente experimental. Y está bien. Dale nombre a esa partida, presupuéstala y deja de intentar reducirla a cero. La partida de desperdicio es también donde se produce la mayor parte del aprendizaje.

Dónde trazo la línea

Forbes acierta en que los tokens son ya una partida real que las empresas tienen que planificar, seguir y gobernar. Forbes se equivoca —o, como mínimo, se muestra peligrosamente despreocupado— al extender esa partida hasta convertirla en una métrica de productividad individual. Lo primero es FinOps. Lo segundo es el viejo error de las líneas de código, reeditado, con una factura de proveedor adjunta.

Las empresas que capeen bien los próximos dos años serán las que traten los tokens con la misma disciplina aburrida que (por fin) aprendieron a aplicar al cloud: asignar el gasto a resultados, enrutar cada tarea al modelo más barato que dé la talla, observar antes de incentivar y nunca —nunca— ascender a un ingeniero por consumir más insumo.

Los tokens son el coste. El ingeniero es el multiplicador. Si tus métricas confunden ambas cosas, no tienes una estrategia de IA. Tienes una factura de IA.

---

Fuentes:

• Nisha Talagala, Are Tokens The New Currency? A Primer For Business, Forbes, mayo de 2026. forbes.com
• The Pragmatic Engineer, The Pulse: Tokenmaxxing as a weird new trend. blog.pragmaticengineer.com
• Wall Street Journal, Why Some Companies Say AI Tokenmaxxing Is Key To Survival. wsj.com

¿Quieres un presupuesto real un equipo de ingeniería potenciado con IA y no sabes cómo implementarlo sin romper al equipo? Habla con un CTO: te ayudamos a separar la factura del trabajo.