En mayo de 2026, Tom's Hardware informó de que «los empleados de Amazon están usando la IA innecesariamente para cumplir cuotas internas». La empresa fijó un objetivo interno según el cual «más del 80 % de los desarrolladores debe usar herramientas de IA cada semana», y el consumo de tokens aparecía en un tablero clasificatorio interno. Los empleados respondieron bombeando tokens: «pasar igualmente por la IA tareas dignas de un copiar y pegar», «dividir una pregunta en muchas», «pedirle a Claude que escriba poesía solo para quemar tokens». Comportamientos similares se documentaron en Meta y Microsoft.

Silicon Valley puso nombre a la tendencia: «Tokenmaxxing». Una nueva norma laboral en la que maximizar el consumo de tokens es recompensado. Casi todas las empresas del Fortune 500 miden el uso de IA, pero muy pocas miden el ROI (según el CTO de ModelOp). La métrica «cantidad usada = cantidad de trabajo realizado» empieza a torcer las decisiones organizativas en mala dirección.

Mi posición de entrada: «consumo de tokens = trabajo producido» es la reedición de los años 2020 de evaluar a los desarrolladores por KLOC (miles de líneas de código) en los noventa. El volumen es fácil de medir, pero volumen y valor son cosas distintas. Un estudio sobre 22 000 desarrolladores y 4 000 equipos muestra que el uso de IA elevó las tareas completadas un +34 %, pero los bugs subieron un +54 % y el tiempo de revisión de PR se multiplicó por 5. Este artículo explica por qué se extendió la mala métrica, qué falla en ella, qué alternativas existen (AWU de Salesforce, DORA, métricas de resultados de AWS) y cinco acciones prácticas que individuos y organizaciones pueden tomar desde hoy, respaldadas por datos de campo y fuentes primarias.

TOKENMAXXING · 2026

Mide solo «cuánto» y el terreno se rompe

— Volumen +34 %, pero la calidad se quiebra: bugs +54 % / tiempo de revisión x5

Volumen (tareas completadas)
+34 %
Épicas completadas +66 %. El uso de IA sí acelera el desarrollo.
Calidad (bugs por desarrollador)
+54 %
Los bugs de producción por desarrollador suben más de la mitad. «Rápido pero con bugs» ya es real.
Tiempo de revisión
El tiempo mediano de revisión de PR se multiplica por 5. El volumen recae sobre los revisores: los humanos no pueden absorber el ritmo de salida de la IA.

Fuente: Estudio «Tokenmaxxing» de Faros AI (22 000 desarrolladores × 4 000 equipos).
Perseguir solo el volumen rompe el terreno. La lección que ya aprendimos con KLOC en los noventa, ahora repetida con una nueva unidad.

1. El mandato de Amazon del «80 % de uso semanal de IA» y el bombeo de tokens que siguió

En mayo de 2026, Tom's Hardware publicó un reportaje de investigación que puso al «Tokenmaxxing» en el mapa. Amazon había fijado un objetivo interno: «más del 80 % de los desarrolladores debe usar herramientas de IA cada semana». El consumo de tokens se visualizaba en un tablero clasificatorio interno, y los responsables lo referenciaban en las evaluaciones de desempeño.

¿Qué hicieron los empleados? «Pasar igualmente por la IA tareas dignas de un copiar y pegar.» «Dividir una sola pregunta en muchas.» «Hacer que Claude escriba poesía solo para quemar tokens.» Consumo ocioso de tokens, con otro nombre. Los empleados de Amazon citados por Tom's Hardware afirmaban que la presión de la cuota era intensa y que estaban «forzando la IA en trabajos donde no usarla habría sido más rápido». Los mismos patrones afloran en Meta y Microsoft: esta no es una historia exclusiva de Amazon.

Trending Topics (prensa tecnológica europea) resumió el cambio como «una métrica técnica convirtiéndose en el credo de una nueva cultura del trabajo». «Aparentar uso de IA» pasa a ser su propio eje de evaluación. Esto ocurre simultáneamente en empresas del Fortune 500 a lo largo de 2026.

2. Por qué se extendió «consumo de tokens = trabajo producido»

¿Por qué las grandes empresas adoptan, para empezar, una métrica tan tosca? Tres razones.

Razón ①: la inversión en IA necesita justificarse

Las empresas del Fortune 500 han invertido miles de millones en IA durante los últimos dos años. Cada vez que el CFO o el consejo pregunta «¿cuál es el retorno de esta inversión?», el CTO necesita una cifra. El consumo de tokens es la cifra más fácil de producir. Logs de las pasarelas de API, historial de chat interno, uso de herramientas de codificación: todo se agrega automáticamente. Leer «cantidad usada» como «cantidad de valor creado» se convirtió en el camino de menor resistencia para la explicación.

Razón ②: sacar a la luz a quienes se resisten a la IA

Toda organización tiene empleados escépticos respecto a la IA: preocupaciones de privacidad, de calidad o simplemente reticencia a aprender herramientas nuevas. La dirección quiere imponer el uso de IA, pero las órdenes por sí solas no mueven a la gente. Exponer el consumo de tokens se convierte en una herramienta para identificar «a las personas que no están usando IA». El objetivo del 80 % de Amazon está pensado precisamente para esto.

Razón ③: demanda de un escalar único y comparable

Las medidas cualitativas como «calidad», «resultados» o «limpieza del código» no se comparan fácilmente. «La persona A usó 1 M de tokens este mes; la B, 500 K»: un único valor escalar se lee como si A hubiera hecho obviamente más. La comparación fácil invita a decisiones perezosas. Esto es estructuralmente idéntico al fracaso del KLOC (miles de líneas de código) de los noventa.

3. Datos duros sobre la divergencia entre cantidad y calidad

Si «cantidad usada = trabajo realizado» se sostuviera, la métrica de tokens sería válida. ¿Qué muestra la realidad? El estudio de Faros AI de 2026 —22 000 desarrolladores en 4 000 equipos— publicó cifras que la descartan de forma contundente.

Faros AI 2026 / N=22 000

Qué eleva el uso de IA y qué rompe

↑ Eleva
  • Tareas completadas: +34 %
  • Épicas completadas: +66 %
  • Líneas de código añadidas: marcado aumento
  • Número de PR: claramente al alza
↓ Rompe
  • Recuento de bugs: +54 %
  • Tiempo de revisión de PR: x5
  • Tasa de reelaboración: al alza
  • Incidentes en producción: tendencia ascendente

«El volumen de salida sube, pero la calidad y la mantenibilidad se llevan el golpe».
Esa es la realidad sobre el terreno. Las métricas de consumo de tokens solo miran una mitad del cuadro.

«La IA acelera el desarrollo» en sí no es falso. Tareas +34 %, épicas +66 %: son cifras reales que muestran valor real. El problema es lo que ese mismo conjunto de datos muestra sobre el coste. Bugs +54 %, tiempo de revisión x5: los revisores humanos no pueden seguir el ritmo del código generado por IA y los defectos se filtran aguas abajo. Algunos investigadores advierten de que las ganancias de productividad a corto plazo pueden quedar compensadas por el crecimiento de la deuda técnica a largo plazo.

4. Tres distorsiones que están ocurriendo sobre el terreno

Basta de teoría. ¿Qué está sucediendo realmente sobre el terreno? Tres patrones observables.

Distorsión ①: bombeo de tokens

El más común. Invocar la IA solo para «que se vea que se usa». Los comportamientos de Amazon: «pasar tareas de copiar y pegar por la IA», «dividir una pregunta en muchas», «charlar con la IA sobre temas no relacionados». Aumento puro de coste, sin valor. La métrica está ahora degradando activamente el ROI de IA de la empresa, exactamente lo que se suponía que debía vigilar.

Distorsión ②: velocidad por encima del fondo

Si la regla es «escribir más te da mejores evaluaciones», la gente responde en consecuencia. Revisar más por encima y fusionar más rápido, saltarse los tests, posponer los refactors: todas son acciones racionales para impulsar la producción a corto plazo. El «+54 % de bugs» de Faros es el resultado previsible.

Distorsión ③: deriva hacia las tareas «amigables con la IA»

Una distorsión más sutil. El trabajo se desplaza desde los problemas difíciles e importantes (diseño, limpieza de deuda técnica, investigación profunda) hacia el trabajo rutinario en el que la IA es buena (código CRUD, generación de documentación, andamiaje de tests). Solo avanza el trabajo medible. Esta es la ley de Goodhart (cuando una medida se convierte en objetivo, deja de ser una buena medida) en su forma de manual.

La historia se repite: en los noventa, muchas empresas intentaron evaluar a los desarrolladores por KLOC (miles de líneas de código). Los resultados: «código inflado sin propósito», «lógica simple escrita de forma prolija», «refactors útiles evitados (porque reducen el recuento de líneas)». Treinta años después, estamos repitiendo el mismo error con una nueva unidad llamada «tokens».

5. Mejores métricas: AWU, DORA y enfoque por resultados

Si los tokens no son la respuesta, ¿qué deberías medir? Tres alternativas de cosecha 2026.

Métricas alternativas × 3

Medir el impacto de la IA más allá de los tokens

① AWU (Agentic Work Units)
Propuesta de Salesforce de 2026. Traduce las entradas de IA (tokens, cómputo) en unidades de trabajo completado. Escalariza «lo que se ha construido». La estandarización aún está en curso.
② 4 métricas DORA
De origen Google. Frecuencia de despliegue, tiempo de entrega, tasa de fallos en cambios y MTTR. Centradas en resultados y validadas durante 15 años. Siguen funcionando en la era de la IA.
③ Indicadores de resultados
Recomendados por AWS. Velocidad de despliegue, calidad del código, eficiencia operativa, productividad del equipo e impacto en el negocio combinados. Sacrifican la simplicidad a cambio de precisión.

Lo que comparten: medir «qué salió», no «qué se utilizó».
Más difíciles de capturar, pero cualquiera de ellas conducirá a mejores decisiones que el consumo de tokens por sí solo.

Mi recomendación personal: DORA es la más práctica. Quince años de uso operativo, abundantes datos de referencia y poco probable que se deforme en la era de la IA. El AWU de Salesforce es ambicioso pero todavía no es un estándar de la industria. Si quieres algo que puedas medir mañana, empieza por DORA.

6. Cinco acciones que individuos y organizaciones pueden tomar hoy

La teoría está zanjada. ¿Qué puedes hacer realmente mañana por la mañana? Lo dividimos por roles.

Para desarrolladores individuales

  • ① No conviertas el consumo de tokens en tu propia métrica: aunque tu responsable lo vigile, evalúate por lo que completaste. Si una tarea es más rápida sin IA, no fuerces el uso de IA
  • ② Presupuesta tiempo de revisión: asume que el código generado por IA requiere «tiempo de lectura ≥ tiempo de escritura». Reserva el tiempo necesario para leer tu propio PR íntegramente antes de enviarlo a revisión
  • ③ Combínalo con ahorro de tokens: prompt caching, Batch API, instrucciones escuetas: «alto resultado con bajo uso de tokens» es la verdadera habilidad

Para la dirección

  • ④ Usa el consumo de tokens solo como señal de aprovisionamiento: nunca como evaluación individual. Mídelo a nivel de organización para confirmar que la inversión en IA se está usando, sin más
  • ⑤ Cambia a las métricas DORA: frecuencia de despliegue, tasa de fallos en cambios y MTTR con cadencia trimestral. Compara antes y después de adoptar la IA para ver si las ganancias son reales o solo bombeo de tokens
Lo más importante: al informar a la dirección, al CFO o al consejo, separa «el consumo de tokens es una métrica de actividad; los resultados de negocio son métricas de resultado». Intentar explicarlo todo con un único número es lo que produce decisiones descuidadas. Trata «cantidad usada» y «valor producido» como temas distintos: esa disciplina es la clave para dirigir bien una organización en la era de la IA.

Resumen

Recapitulemos:

  • 2026: el «Tokenmaxxing» (bombeo de tokens para inflar métricas) se observa en Amazon, Meta y Microsoft; ya es un término de la industria
  • Estudio de Faros AI con 22 000 desarrolladores: el uso de IA eleva las tareas completadas un +34 %, pero los bugs suben un +54 % y el tiempo de revisión se multiplica por 5. Cantidad y calidad divergen
  • «Consumo de tokens = trabajo producido» es la reedición en los años 2020 de la evaluación por KLOC de los noventa. La ley de Goodhart hace la deformación inevitable
  • Tres distorsiones de campo: bombeo de tokens / velocidad por encima del fondo / deriva hacia tareas amigables con la IA
  • Alternativas: AWU de Salesforce / 4 métricas DORA / indicadores de resultados de AWS. DORA es la más práctica hoy
  • Individuo: evalúate por lo hecho. Organización: cambia la evaluación a DORA y reporta el consumo de tokens solo como dato de nivel de actividad

En 2026, con la IA dentro de las organizaciones, la tentación de medir el volumen es más fuerte que nunca. Los logs de las API te dan recuentos de tokens gratis, y por eso la trampa de leer esas cifras como «trabajo producido» es tan profunda. La lección que ya aprendimos del KLOC hace treinta años no debería repetirse en una nueva unidad llamada «tokens». Esa es la primera pieza de inteligencia organizativa que se necesita en la era de la IA.

FAQ

Q1. ¿Ocurre esto también en empresas más pequeñas?

Sí, independientemente del tamaño. De hecho, las empresas más pequeñas afrontan una presión más fuerte para «evaluar por lo medible», y los líderes se aferran a la métrica más fácil. Incluso las startups fijan reglas internas como «objetivo del 100 % de uso de IA». La misma trampa.

Q2. ¿Cómo se mueve a los empleados que se resisten a la IA?

«Pruébalo y dime qué te parece» supera a «úsalo» a largo plazo. Las cuotas de tokens generan cifras a corto plazo, pero convierten a los reticentes en personas que lo usan solo de cara a la galería. La adopción real requiere seguridad psicológica e inversión en formación: una regla básica del despliegue de tecnología nueva, no exclusiva de la IA.

Q3. ¿Aplica esto fuera de ingeniería (ventas, marketing)?

Más todavía. Los resultados de ventas y marketing son cualitativos y difíciles de medir, así que los líderes recurren a métricas superficiales como «número de propuestas redactadas con IA» o «consultas lanzadas a ChatGPT». Lo que deberías estar midiendo: tasa de cierre, satisfacción del cliente, tiempo de entrega: métricas de resultado que ya existían antes de la IA.

Q4. ¿Cómo mido DORA en mi equipo?

Las herramientas gratuitas funcionan. GitHub Insights, Jellyfish, LinearB, Faros AI. El sitio oficial de Google, dora.dev, ofrece benchmarks y explicaciones. La agregación manual sirve al principio: solo comparar trimestre contra trimestre revela si la IA está produciendo valor real.

Q5. ¿Es «consumo de tokens = trabajo producido» completamente erróneo?

No completamente erróneo. Como indicador macro de la actividad global de IA en la organización, es útil. «No se está usando» es una señal real. El problema es usarlo para evaluación individual, KPIs o cuotas. OK como observación macro, NO OK como microevaluación individual: mantén ambas separadas.