Amazon gastó millones en IA y sus propios empleados la hackearon: la historia del Tokenmaxxing
Durante dos años, el mensaje de las grandes empresas tecnológicas a sus empleados fue consistente y simple: usen más IA. Las empresas que más la usen ganarán. Los números vendrán solos.
Los números no llegaron. Y ahora el mensaje está cambiando.
El 29 de mayo de 2026, Amazon cerró un sistema interno llamado KiroRank. Era un leaderboard — un tablero de clasificación — que medía cuántos tokens de IA consumía cada empleado en la plataforma interna de desarrollo Kiro. El más alto en el ranking ganaba lo que en Silicon Valley se llama "nerd points": reconocimiento interno, visibilidad, señales de carrera.
Lo que pasó después es uno de los ejemplos más claros y más costosos de algo que los economistas llaman la Ley de Goodhart: cuando una métrica se convierte en el objetivo, deja de ser una métrica útil.
Qué era KiroRank y por qué parecía buena idea
Amazon no es una empresa ingenua. Tiene miles de ingenieros brillantes. Tiene procesos internos sofisticados. Y tiene, desde hace dos años, una apuesta masiva en IA: aproximadamente $200 mil millones en gastos de capital para 2026, la mayor parte destinada a infraestructura de IA y centros de datos.
En ese contexto, querer medir la adopción interna de IA tiene sentido. Si inviertes $200 mil millones en infraestructura de IA, necesitas saber si tus propios empleados la están usando. Amazon se había propuesto que más del 80% de sus desarrolladores usaran herramientas de IA semanalmente.
KiroRank fue la implementación de esa meta. El tablero medía la cantidad de tokens de IA que cada empleado usaba en la plataforma Kiro — los tokens son las unidades con las que los modelos de lenguaje procesan texto, y cada uno tiene un costo de cómputo real. La lógica era directa: más uso de IA equivale a mayor adopción, y mayor adopción equivale a mayor productividad.
La lógica era incorrecta.
El hackeo que nadie esperó — y todos debieron haber anticipado
Lo que pasó a continuación era predecible en retrospectiva. Los empleados comenzaron a inflar sus puntajes a través del tokenmaxxing: corriendo tareas sin sentido a través de agentes de IA para consumir tokens y escalar en el ranking. Los costos subieron. El valor de negocio no.
El término "tokenmaxxing" — una combinación de "token" y "maxxing" (maximizar) — surgió internamente como el nombre de la práctica. Empleados configuraban agentes para ejecutar tareas de bajo o ningún valor: procesar documentos sin importancia, generar textos que nadie leería, correr loops de análisis sobre datos irrelevantes. No para resolver problemas. Para subir en el ranking.
Amazon también tenía una herramienta interna llamada MeshClaw, un agente estilo OpenClaw, que permitía a los empleados crear agentes propios que podían interactuar con sistemas del entorno laboral, incluyendo despliegues de código, triage de email, y comunicaciones internas. MeshClaw amplificó el tokenmaxxing: los agentes corrían solos, consumiendo tokens por horas, sin producir nada útil.
El resultado fue una factura de cómputo inflada artificialmente por empleados que técnicamente cumplían la meta — 80% de uso semanal — sin aportar ningún valor real al negocio.
El SVP Dave Treadwell le mandó un memo a los empleados diciéndoles que no usaran IA "solo por el hecho de usarla." Amazon cerró KiroRank y reemplazó la métrica por "normalized deployments" — código asistido por IA que realmente llega a producción — en lugar de volumen bruto de consumo de tokens.
Amazon no estaba sola: el patrón se repite en toda la industria
Lo más revelador de esta historia no es que le pasó a Amazon. Es que le pasó a todos al mismo tiempo.
El patrón entre Amazon, Meta, Uber y Microsoft es consistente: el uso intensivo de IA generó costos pero no resultados proporcionales, y el liderazgo comenzó a decirlo públicamente.
Meta y Claudenomics: Meta cerró su propio leaderboard llamado "Claudenomics" la misma semana que Amazon cerró KiroRank. Claudenomics cubría 85.000 empleados y destacaba a los 250 con mayor consumo de tokens. El sistema enfrentaba la misma dinámica de tokenmaxxing que mató a KiroRank: empleados compitiendo por el estatus de "Token Legend" con tareas sin valor real.
Uber y el presupuesto quemado: El CTO de Uber, Praveen Neppalli Naga, reveló que la empresa había quemado todo su presupuesto de Claude Code para 2026 en los primeros cuatro meses del año — apenas un cuarto de la jornada anual. A pesar de que más del 80% de los ingenieros de software de Uber usaban IA agéntica y más del 60% del código era generado por IA, los ejecutivos estaban teniendo dificultades para justificar el gasto en IA contra ganancias tangibles de productividad. El COO Andrew Macdonald lo dijo sin rodeos en un podcast: "Ese vínculo todavía no está ahí" cuando se trata de usar IA para lanzar features útiles para los consumidores.
Microsoft: Microsoft reportadamente comenzó a cancelar la mayoría de las licencias de Claude Code y redirigió a los desarrolladores hacia GitHub Copilot CLI. El CEO Satya Nadella también envió un mensaje interno que generó tanto debate como cualquier anuncio público de la empresa.
Cuatro grandes empresas. El mismo mes. El mismo problema. Eso no es coincidencia — es una industria entera chocando contra la misma pared al mismo tiempo.
La Ley de Goodhart: el principio económico que predijo todo esto
Charles Goodhart era un economista del Banco de England. En los años 70, formuló una observación sobre política monetaria que desde entonces se ha convertido en uno de los principios más citados del mundo del management: "Cuando una medida se convierte en un objetivo, deja de ser una buena medida."
La versión más coloquial: cuando la gente sabe que está siendo medida por un número, optimiza ese número — no el comportamiento subyacente que ese número supuestamente representa.
En el mundo del software, la Ley de Goodhart tiene una historia larga. Se vio con las métricas de líneas de código: cuando los equipos eran evaluados por cuántas líneas escribían, comenzaban a escribir más líneas de las necesarias, a evitar la refactorización, y a producir código inflado que era más difícil de mantener. Se vio con las métricas de commits: cuando el número de commits diarios se convirtió en señal de productividad, los desarrolladores comenzaron a commitear cambios mínimos múltiples veces por hora.
KiroRank es la Ley de Goodhart aplicada a los tokens de IA. Amazon describió KiroRank como una herramienta beta no oficial construida por un grupo de empleados que "nunca tuvo la intención de promover el uso de IA por el bien del uso". La empresa reemplazó el tracking de tokens crudos por "normalized deployments", que mide si el código generado por IA demuestra utilidad real — como commits exitosos y output de trabajo significativo — en lugar de simplemente contar cuántos tokens fueron consumidos.
El analista Gil Luria de D.A. Davidson lo formuló directamente: la dinámica de KiroRank es la demostración a escala de la Ley de Goodhart, con un producto nombrado y una respuesta ejecutiva con nombre propio.
El problema más profundo: ¿la IA realmente aumenta la productividad?
El escándalo del tokenmaxxing abrió una pregunta más incómoda que nadie en la industria quería hacer en voz alta: ¿están las empresas obteniendo retorno real de su inversión en IA?
Uber gastó $3.4 mil millones en investigación y desarrollo en 2025, un aumento del 9% respecto al año anterior. A pesar de que más del 80% de sus ingenieros de software usaban IA agéntica y más del 60% del código era generado por IA, los ejecutivos están luchando para justificar el gasto en IA contra ganancias tangibles de productividad.
Un artículo de James Shore — programador y autor — argumentó en un post que se volvió viral en Hacker News que el código generado por IA no necesariamente reduce las necesidades de mantenimiento futuro, y puede incluso aumentarlas. El código que nadie escribió con cuidado tiende a ser código que nadie entiende completamente. Y el código que nadie entiende completamente es el código que más cuesta mantener.
En febrero de 2026, METR publicó un hallazgo que nadie esperaba: cuando pusieron a developers experimentados a trabajar con herramientas de IA, tardaron un 19% más que cuando trabajaban sin ellas. Habían predicho que la IA les ahorraría un 24% del tiempo. La realidad fue la opuesta.
El problema no es que la IA no funcione. Es que la productividad es más compleja que el volumen de output. Generar más código más rápido no equivale automáticamente a entregar más valor. Y las métricas que solo miden el primero — tokens consumidos, líneas generadas, commits por día — son ciegas al segundo.
Lo que "normalized deployments" revela sobre el futuro de la medición
La decisión de Amazon de reemplazar KiroRank con "normalized deployments" es, en sí misma, una declaración sobre cómo debería medirse el trabajo con IA.
Una métrica de deployments normalizados responde preguntas diferentes:
- ¿El código generado por IA pasó code review?
- ¿Llegó a producción?
- ¿Resolvió el problema que pretendía resolver?
- ¿El PR fue mergeado o rechazado?
Esas preguntas son más difíciles de responder que "¿cuántos tokens consumiste esta semana?". Requieren instrumentación más sofisticada. Requieren conectar la actividad de IA con los outcomes reales del negocio. Y, crucialmente, son mucho más difíciles de falsificar — no porque los empleados sean honestos, sino porque deployments fallidos tienen consecuencias reales que ningún leaderboard puede esconder.
Para developers individuales, la implicación es directa: tu organización va a notar si tus sesiones de Copilot, Kiro, o Claude Code no se correlacionan con PRs que pasan review. Las horas de agente de vanidad son ahora un riesgo de centro de costos.
El mensaje no es que dejes de usar IA. Es que la uses para producir cosas que pasen el filtro de lo real: que funcionen, que lleguen a producción, que resuelvan el problema del cliente.
Las implicaciones para equipos que usan IA hoy
Si lideras un equipo o decides sobre herramientas de IA en tu empresa, la historia de KiroRank tiene cinco lecciones directas:
1. Nunca midas adopción de IA con una sola métrica de actividad. Tokens consumidos, prompts enviados, o sesiones iniciadas son indicadores de proceso, no de resultado. Son útiles para controlar costos, no para evaluar productividad.
2. Las métricas que se publican se convierten en objetivos. Si vas a hacer visible una métrica de IA para el equipo, asegúrate de que sea lo suficientemente compleja como para que optimizarla requiera hacer el trabajo real. Una métrica simple siempre puede ser jugada.
3. El presupuesto de tokens necesita dueño. Uber quemó el presupuesto anual en cuatro meses. Eso no ocurre por accidente — ocurre cuando no hay nadie rastreando el costo por unidad de valor entregado. Cada equipo debería tener una persona responsable de la relación entre gasto en tokens y outcomes medibles.
4. Los agentes autónomos amplifican el problema. KiroRank fue especialmente vulnerable porque los agentes de Kiro y MeshClaw podían correr solos durante horas, consumiendo tokens sin intervención humana. Cada workflow agéntico necesita un límite de presupuesto y un criterio de salida que esté ligado a un resultado real, no al tiempo de ejecución.
5. La pregunta correcta no es "¿cuánto usamos IA?" sino "¿qué produjo la IA que usamos?" Esa pregunta cambia cómo evalúas herramientas, cómo estructuras el trabajo, y cómo reportas resultados a quien decide el presupuesto.
Lo que esto dice sobre el momento que vive la industria
Hay algo significativo en que Amazon, Meta, Uber y Microsoft llegaron al mismo límite casi simultáneamente, en el mismo mes de mayo de 2026.
Durante dos años, la narrativa dominante fue que la IA era un multiplicador incondicional. Más uso equivalía a más valor, casi por definición. Las empresas que más la usaran tendrían ventaja competitiva. Invertir en adopción era invertir en el futuro.
Esa narrativa era demasiado simple, y la industria lo está descubriendo de la manera más cara posible.
Para dos años, el mensaje fue simple: usen más. Ahora las mismas empresas, incluso las que fabrican los chips que corren la IA, están preguntando si algo de esto funciona. Amazon fue una de las primeras en decir suficiente.
Esto no es el fin de la IA en las empresas. El presupuesto de capital de Amazon de $200 mil millones está intacto. Meta sigue invirtiendo. Uber sigue usando Claude Code. Lo que cambió es la conversación interna: de "usen más IA" a "usen IA que produzca resultados medibles."
Ese es un cambio de madurez, no de dirección. Y para los developers y founders que trabajan con estas herramientas día a día, es la señal más importante del año: el período de adopción a ciegas terminó. Ahora viene el período en que la IA tiene que justificar cada dólar que cuesta.
La pregunta que KiroRank no pudo responder
En el fondo, la historia del tokenmaxxing no es sobre empleados deshonestos ni sobre gestión deficiente. Es sobre una pregunta genuinamente difícil que ninguna empresa ha sabido responder bien todavía: ¿cómo mides el valor real que produce la IA?
Las métricas de actividad son fáciles de medir y fáciles de manipular. Las métricas de outcome son difíciles de medir y difíciles de manipular. Las empresas eligieron las primeras porque son más simples. El resultado fue KiroRank.
La Ley de Goodhart predijo exactamente lo que pasó. El problema no era la tecnología. Era que nadie se hizo la pregunta correcta antes de publicar el tablero.
La buena noticia: ahora la industria sabe cuál es la pregunta. La respuesta es "normalized deployments", o alguna variante de ella. Y eso es, paradójicamente, uno de los avances más importantes que ha hecho el mundo enterprise en su relación con la IA en lo que va del año.
¿Tu empresa mide el uso de IA de tus developers? ¿Con qué métricas? Cuéntalo en los comentarios — es exactamente la conversación que el sector necesita tener en público.
Comentarios