Llevo dos décadas viendo organizaciones medir lo que es fácil de contar en lugar de lo que realmente importa. Líneas de código. Story points. Asistencia a reuniones. Porcentajes de uptime reportados al directorio con tres decimales de falsa precisión.
Ahora tenemos tokens.
Amazon supuestamente exige que más del 80% de sus desarrolladores usen herramientas de IA semanalmente, y rastrea el consumo de tokens en leaderboards internos. La respuesta fue predecible para cualquiera que haya gestionado una organización tecnológica: los empleados empezaron a correr su plataforma agéntica interna, MeshClaw, en tareas sin sentido — pegando texto irrelevante, loopeando requests idénticos — únicamente para escalar en el ranking. En Meta, un empleado construyó un dashboard llamado “Claudeonomics” que rankeaba a los casi 85.000 trabajadores de la empresa por consumo de tokens. En una ventana de 30 días, el uso total superó los 60 billones de tokens antes de que el leaderboard fuera discretamente dado de baja.
Sesenta billones de tokens. Quiero pausar en ese número un momento, no porque sea impresionante, sino porque no nos dice absolutamente nada sobre si alguien en Meta entregó mejor software, resolvió problemas de clientes más rápido, o tomó una sola decisión que no hubiera tomado sin asistencia de IA.
Esto es la Ley de Goodhart en su forma más pura: cuando una medida se convierte en objetivo, deja de ser una buena medida. El economista Charles Goodhart identificó esta dinámica en política monetaria en los años 70. Medio siglo después, las empresas tecnológicamente más sofisticadas del planeta la están redescubriendo de la peor manera, a un costo medido en ciclos de GPU desperdiciados y ansiedad organizacional.
Ya Estuvimos Acá Antes
El leaderboard de tokens es nuevo. El modo de falla es antiquísimo.
En los primeros días del desarrollo de software, los managers contaban líneas de código. Más líneas significaban más productividad, ¿no? Hasta que los desarrolladores descubrieron que el código verboso puntúa mejor que el código elegante, y el incentivo silenciosamente optimizó hacia el bloat. Después pasamos a los commits. Luego a los story points — una métrica tan sistemáticamente manipulada que la mayoría de los equipos de ingeniería la abandonaron como señal de productividad mientras la conservan para estimaciones. Después llegó la “asistencia a reuniones” y la “responsividad” como proxies de engagement, que produjeron la cultura de disponibilidad performativa que mató el trabajo profundo en la mayoría de las empresas.
Cada vez, el patrón es idéntico: una preocupación legítima de fondo (¿están trabajando? ¿son productivos? ¿adoptan las nuevas herramientas?) se traduce en una métrica proxy, el proxy se convierte en objetivo, y el comportamiento se reorganiza alrededor de optimizar el proxy en lugar de la cosa subyacente.
Los tokens son la última iteración. Y son un proxy particularmente malo por al menos tres razones.
Por Qué los Tokens Son una Métrica Especialmente Mala
Primero, el volumen de tokens está inversamente correlacionado con la habilidad. Un desarrollador junior que no sabe bien lo que hace genera muchos más tokens que un desarrollador senior que escribe un prompt preciso y obtiene una respuesta útil en un solo intercambio. Premiar el consumo de tokens es, estructuralmente, una forma de premiar la ineficiencia.
Segundo, los tokens miden input, no output. Todo mandato tecnológico empresarial que vi fracasar confundió actividad con resultados. Si alguien usó la IA no es la misma pregunta que si la IA le ayudó a lograr algo. Quemar tokens en MeshClaw mientras mirás el leaderboard es actividad. Entregar una feature es un resultado. No son la misma cosa.
Tercero, el gaming es trivialmente fácil. No hace falta ser maquiavélico para manipular un leaderboard de tokens. Solo hay que ser racional. Si el sistema premia el consumo de tokens y ese consumo es barato en relación al costo social de rankear bajo, cualquier actor racional va a generar tokens. Esto no es un defecto de carácter en los ingenieros de Amazon — es una respuesta predecible a un sistema de incentivos mal diseñado.
Qué Debería Medirse en Cambio
No estoy en contra de medir la adopción de IA. La adopción no ocurre sola, y hay razones organizacionales legítimas para rastrear si las herramientas costosas se están usando. Pero la medición debería ser honesta sobre lo que intenta aprender.
Si la preocupación real es la adopción, medí tasas de completitud de tareas con y sin asistencia de IA. Si es productividad, medí el cycle time en tareas comparables. Si es calidad, medí tasas de defectos o retrabajo. Estas son más difíciles de rastrear que los tokens. Requieren criterio para interpretarlas. No pueden reducirse a un leaderboard de la manera en que puede hacerlo un número de consumo crudo.
Esa dificultad no es un bug — es el punto. Las métricas fáciles son fáciles de manipular. Las métricas que vale la pena rastrear son las que te obligan a mirar el trabajo de verdad.
La Ironía Más Profunda
Hay algo casi poético en el hecho de que Amazon, una empresa que apostó más de 100.000 millones de dólares al potencial transformador de la IA, esté luchando por medir si esa transformación realmente está ocurriendo. Los hyperscalers le están diciendo a los inversores que los chips de inferencia se consumen tan rápido como se despliegan. El gasto de capital combinado de 2026 de los cuatro grandes actores está rozando los 700.000 millones de dólares, con algunas proyecciones que superan el billón para 2027.
En ese contexto, el mecanismo principal para rastrear el valor interno de la IA es… un leaderboard de tokens que los empleados están manipulando con scripts de loop.
El analista Gil Luria lo expresó diplomáticamente cuando le dijo a Fortune: “Obtenés el comportamiento que creás el incentivo para generar.” Lo que no dijo, pero que todo CIO que sobrevivió un rollout de ERP o una transformación DevOps ya sabe, es que el mal diseño de incentivos es una forma de autolesión organizacional. No solo fallás en medir lo que te importa — activamente creás ruido que ahoga la señal.
Los empleados que corren MeshClaw en círculos no son el problema. Los ejecutivos que confundieron el consumo de tokens con la adopción de IA lo son.
Una Nota para los Equipos de Ingeniería Latinoamericanos
Para quienes estamos construyendo organizaciones tecnológicas en América Latina, donde los presupuestos de IA son más ajustados y los costos de API importan más, esta historia tiene una advertencia específica. La presión por demostrar adopción de IA es real acá también — de directorios, inversores, clientes que quieren ver “estrategia de IA” en cada presentación.
No dejen que esa presión los empuje hacia métricas de vanidad. Los tokens consumidos son un costo, no un logro. La pregunta que vale la pena hacerse en cada sprint review no es “¿cuánta IA usamos?” — es “¿qué construimos que no hubiéramos podido construir sin ella, y cuánto tiempo nos llevó?”
Esa es la métrica que sobrevive a la Ley de Goodhart.