Hay una nueva moda en las empresas tech, y es exactamente tan absurda como suena.
Llevo meses viéndolo: empresas montando leaderboards internos para rastrear quién gasta más tokens de IA. El término que circula es tokenmaxxing — la práctica de maximizar tu consumo de tokens para demostrar que «estás adoptando IA». Algunas organizaciones están literalmente gamificando el uso de LLMs como si fuera un reto de pasos en una pulsera de empresa. Y no es un rumor de pasillo: Hard Fork, el podcast de tecnología del New York Times, le dedicó un segmento entero, y el patrón sigue apareciendo en cada Slack de ingeniería en el que me cuelo. Esto está pasando a escala.
Cuando escuché el término por primera vez, no me reí. Hice una mueca. Porque esta película ya la he visto.
El déjà vu: ya hicimos esto con las líneas de código
En 2019 escribí en Genbeta Dev un artículo sobre por qué medir la productividad de un programador por las líneas de código que escribe al día era una idea terrible. El argumento era simple: más código no significa mejor código. Un ingeniero senior que refactoriza 500 líneas hasta dejarlas en 50 es objetivamente más productivo que el que mete 2.000 líneas de espagueti que el equipo estará desenredando durante los próximos tres sprints.
Todos asentimos. Todos dijimos «sí, sí, líneas de código: métrica horrible». Los managers lo compartieron en LinkedIn. Se dieron charlas en conferencias. Se escribieron libros.
Y entonces llegó la IA, y aparentemente sufrimos una amnesia colectiva.
Porque el tokenmaxxing es simplemente líneas de código con una gabardina encima. La misma lógica rota, con un envoltorio más brillante. En lugar de «quién escribió más código», ahora preguntamos «quién quemó más tokens». Como si bombardear a Claude Sonnet 4.6 con prompts mal estructurados 47 veces al día te convirtiera en un ingeniero AI-forward.
No lo hace. Te convierte en un ingeniero caro.
Consumo no es impacto
Déjame pintarte dos escenarios.
La Ingeniera A gasta 3.000 tokens en un único prompt bien construido a Claude Sonnet 4.6. Describe el problema con claridad, aporta contexto, especifica restricciones y recibe una solución funcional que revisa, testea y despliega. Tiempo total: 25 minutos. La PR está limpia. Los tests pasan.
El Ingeniero B gasta 40.000 tokens volcando su codebase entero en la ventana de contexto de 1M de Opus porque puede, y luego dispara una tarde caótica de «arregla esto», «no, eso no», «prueba otra vez pero diferente» y «en realidad vuelve a lo que tenías antes». Acaba copiando y pegando una solución que no entiende del todo, y que introduce una regresión que lleva dos días diagnosticar.
¿En el leaderboard? El Ingeniero B es tu campeón de IA. Dadle un trofeo.
Esto no es hipotético. Llevo más de 15 años en desarrollo móvil, y te puedo asegurar que el patrón es siempre el mismo: cada vez que llega una herramienta nueva, alguien en management decide que la mejor forma de impulsar la adopción es medir el volumen de uso. Y todas y cada una de las veces, se optimiza para lo que no toca.
No mides cuántas veces alguien abrió el IDE. No mides cuántos tickets de Jira creó alguien. No mides cuántos mensajes de Slack envió alguien. Entonces, ¿por qué narices ibas a medir cuántos tokens consumió?
Qué deberías estar midiendo
Si de verdad quieres entender si la IA está haciendo a tu organización de ingeniería mejor — y no solo más cara — esto es lo que hay que mirar:
- Time to resolution. ¿Se resuelven los problemas más rápido? No «¿la gente promptea más rápido?», sino ¿se cierran los issues reales antes?
- Calidad de las PRs. ¿Las code reviews van más fluidas? ¿Hay menos rondas de ida y vuelta? ¿Menos comentarios de «esto no cubre el edge case»?
- Reducción de bugs. ¿El código que sale con asistencia de IA es realmente más fiable? ¿O estamos desplegando más rápido y rompiendo más cosas?
- Velocidad de equipo. No velocidad individual — velocidad de equipo. Porque la adopción de IA debería subir el barco entero, no hacer que una persona parezca productiva mientras genera trabajo de limpieza para todos los demás.
Esto encaja con la filosofía de las métricas DORA — medir resultados y estabilidad, no actividad en bruto. No voy a profundizar en ese framework aquí; eso da para un artículo propio, y está en camino. Pero el punto es claro: estas métricas miden resultados. El gasto en tokens mide actividad. Y si llevas más de cinco minutos en gestión de ingeniería, sabes que actividad y resultados a menudo están inversamente correlacionados.
La trampa del leaderboard
Aquí es donde la cosa se pone seria.
Cuando pones un leaderboard, la gente juega al juego del leaderboard. No al juego del valor. No al juego de «voy a usar la herramienta adecuada para el trabajo adecuado». El juego del leaderboard. Esto es la Ley de Goodhart en acción: cuando una medida se convierte en objetivo, deja de ser una buena medida.
Así que déjame hacer unas cuantas preguntas incómodas que nadie en el «comité de adopción de IA» parece estar haciendo:
¿El objetivo real del leaderboard es identificar a quién no se sube al tren? Porque si es así, enhorabuena: estás midiendo la adopción mediante presión social, no creación de valor. Eso no es una estrategia. Eso es hacer sentir culpable a la gente con un dashboard.
¿Qué pasa con la arquitecta senior que no usa IA porque su trabajo — diseño de sistemas, mentoría, alineación entre equipos — no se beneficia del consumo de tokens? ¿Está «atrasada» porque no promptea? ¿O está exactamente donde tiene que estar, haciendo el trabajo que ningún LLM puede hacer?
¿Estás incentivando calidad o volumen? Porque los leaderboards de tokens incentivan volumen. Punto. De la misma manera que las métricas de líneas de código incentivaban codebases inflados y sobreingeniarizados que hacían que todo el mundo pareciera ocupado y nadie pareciera efectivo.
La gamificación funciona cuando la métrica se alinea con el resultado que buscas. Los pasos de una pulsera funcionan para el fitness porque los pasos genuinamente correlacionan con la salud. Los tokens consumidos no correlacionan con el impacto en ingeniería. Correlacionan con la frecuencia con la que alguien le dio a «enviar» en un prompt.
La factura está en camino
Y esta es la parte de la que nadie quiere hablar todavía: el dinero.
Los informes sugieren que hasta un 40% de los presupuestos enterprise de IA se están desperdiciando en ineficiencias: prompts inflados, llamadas redundantes a la API, uso de modelos clase Opus para tareas que Haiku resolvería durmiendo. Las empresas con uso intensivo están quemando entre 200 y 500 dólares por empleado al mes en créditos de API. Multiplica eso por una organización de ingeniería de 500 personas y estás mirando una partida que hace que las antiguas licencias de Jira parezcan calderilla. El gasto global enterprise en IA alcanzó los 2,53 billones de dólares en 2026, y una parte significativa de eso es puro desperdicio disfrazado de adopción.
Gente como Aaron Levie y Andrej Karpathy ya están hablando de «token budgeting» como una disciplina real. Lo que significa que las mismas empresas que hoy reparten trofeos a quien más tokens quema estarán, en seis meses, contratando consultores para averiguar por qué su factura de IA tiene siete cifras y sigue subiendo. Spoiler: el problema no es el coste de los tokens. El problema es que incentivaste a la gente a quemarlos sin criterio.
El leaderboard da, y la revisión financiera quita.
El ciclo se repite
Llevo en tecnología el tiempo suficiente como para haber visto este patrón con cada cambio grande. Llega una herramienta nueva. Management entra en pánico por la adopción. Alguien propone una métrica de vanidad. La métrica se gamifica. La gente optimiza para la métrica en lugar del objetivo. Dos años después, todos fingen que siempre supieron que era mala idea.
Lo vi con el móvil. Lo escribí con las líneas de código. Y ahora lo estoy viendo otra vez con la IA.
La ironía es brutal: tenemos las herramientas de razonamiento más potentes de la historia de la ingeniería de software, y estamos usando la métrica más estúpida posible para evaluar si la gente las usa bien.
El tokenmaxxing no es una estrategia de adopción de IA. Es un cargo cult disfrazado de gestión data-driven.
Mide impacto. Mide resultados. Mide si el trabajo realmente está mejorando.
O no lo hagas. Y dentro de dos años, todos podemos escribir la retrospectiva sobre lo obvio que era.
Deja un comentario