Tokenmaxxing: midiendo lo fácil y no lo importante

Cada cierto tiempo, el sector tech inventa una nueva forma de confundir el tocino con la velocidad. El tokenmaxxing es solo el último capítulo de una historia que ya conocemos.

En los últimos meses ha emergido un término en Silicon Valley que lo mismo te suena: tokenmaxxing. La práctica consiste en maximizar el consumo de tokens de IA (la unidad mínima que procesan modelos como Claude, GPT o Llama) como señal de productividad. Cuantos más tokens quemas, más moderno, más productivo o más código estás generando. 

Jensen Huang, CEO de Nvidia, fue uno de los primeros en decirlo públicamente: propuso que los ingenieros recibieran tokens como parte de su compensación (una especie de "cuarto pilar" junto al salario, el bonus y el equity) y que gastar poco sería directamente sospechoso. Meta creó leaderboards internos donde los empleados compiten por el título de Token Legend. Amazon exige que más del 80% de sus ingenieros usen herramientas de IA cada semana y rastrea el cumplimiento mediante KPI de consumo. 

Solo aplicando el sentido común, esto ya no parece una buena idea; como si generar más código o gastar más tokens fueran sinónimo de algo bueno.

¿Y qué pasó? La clásica historia de incentivos perversos: varios empleados de Amazon crearon una herramienta interna de agentes de IA para automatizar tareas innecesarias, con el único objetivo de inflar su consumo de tokens. Como dijo uno de ellos al Financial Times: "Cuando rastrean el uso, se crean incentivos perversos y hay gente muy competitiva con esto".

Esto no es nuevo. Ya hemos estado aquí antes

Al principio la productividad de un desarrollador se medía, entre otras cosas, por las horas trabajadas. Más tiempo en la silla, más trabajo hecho. El resultado fue una generación de managers obsesionados con el presentismo y una generación de trabajadores expertos en parecer ocupados.

Luego vinieron las líneas de código. Una métrica aparentemente objetiva, cuantificable, comparable. Bill Gates ya avisó de lo absurdo que era esto: "Medir el progreso del software por líneas de código es como medir el progreso de la construcción de un avión por su peso". Y de nuevo la volvimos a cagar: ingenieros creando código a paladas para salir mejor en las métricas, en vez de producir código de calidad y óptimo (o incluso no producirlo).

Después llegaron los commits. La lógica, de nuevo, parecía razonable: el que más contribuye al repositorio, más está aportando. El resultado fue commits triviales, fragmentación artificial de cambios y una carrera por aparecer activo en el gráfico de GitHub. De nuevo algo que no medía NADA y que volvía a generar el mismo efecto.

Ahora son los tokens. Una unidad técnica que mide el procesamiento de los modelos de IA ha pasado a funcionar como marcador de productividad, prestigio interno y, en algunos casos, compensación laboral (menos mal que todavía estamos a tiempo de cambiar esto)

La Ley de Goodhart lleva cincuenta años explicandolo: "Cuando una métrica se convierte en objetivo, deja de ser una buena métrica". La gente no es perezosa ni deshonesta por naturaleza; simplemente responde a los incentivos que el sistema crea.

La obsesión constante por medir la productividad individual de los desarrolladores nos ha llevado siempre a un sistema de valoración poco honesto y, además, muy poco fiable. Quizás, y solo quizás, llevemos años obsesionados con medir algo imposible. 

¿Puede ser interesante?

Claro que hay algo interesante en el tokenmaxxing, más allá del patrón recurrente.

La irrupción de la IA en el trabajo técnico está siendo transformadora. Hay ingenieros que, usando las herramientas adecuadas, están aumentando su capacidad de entrega de maneras que hace dos años habrían parecido imposibles. La adopción real sí importa, y tiene sentido que las empresas quieran entender cómo está ocurriendo para poder extenderlo a toda la organización.

El problema no es medir el uso de IA. Está bien saber cuánto nos estamos gastando en tokens, por supuesto. El problema es creer que la adopción real equivale al consumo de tokens. Es como medir las veces que haces clic con el ratón. 

Utilizar más tokens no implica entrar más valor. Y esto deberían saberlo todos los CEO’s. 

Y sin duda, no tiene ningún sentido usar los tokens como una métrica de rendimiento individual. 

Si esto ya viene de lejos, ¿por qué nos cuesta tanto cambiar?

Desde Manfred llevamos años hablando con empresas sobre cómo evaluar talento técnico. Y una de las conversaciones más recurrentes es precisamente esta: la tentación de medir lo que es fácil.

Las métricas de actividad —horas, líneas, commits, tokens— son atractivas porque son objetivas, cuantificables y fáciles de visualizar. Generan la sensación de control, permiten comparar y justificar decisiones. Parece que los datos no mienten.

El problema es que lo que realmente importa en un perfil técnico es difícil de medir. La calidad del juicio, la capacidad de resolver problemas complejos y el impacto real en el negocio. Incluso cosas mucho más complejas aún de medir, como la capacidad de decidir cuándo no construir algo, cuándo no usar una herramienta, cuándo la respuesta correcta es no añadir más código.

Todo esto no es cuantificable y, por tanto, difícilmente comparable, no tiene cabida en un dashboard y por eso es fácil que tendamos a ignorarlo y a sustituirlo por métricas como las líneas de código o los tokens. 

¿Estamos mirando en el sitio adecuado?

Es tentador crear el penúltimo framework que mide la actividad de nuestros IC. Métricas basadas en tokens, horas, commits, PR o cualquier cosa medible. Siempre tenemos en mente esa frase que dice: “Aquello que no se puede medir, no se puede mejorar”. Y es totalmente cierto, tenemos que medir lo que se entrega, pero quizás estamos poniendo la lupa en el lugar equivocado.

Este constante taylorismo digital que intenta llevar el trabajo intelectual a algo medible, como si de hacer tornillos se tratara, choca con que construir software nunca es algo individual.

Los grandes productos los crean equipos formados por personas diversas que trabajan en diferentes áreas. Los equipos se complementan y retroalimentan.

Dentro de un equipo habrá personas que generen más código y otras que menos, algunas que no producen nada directamente, pero que están asumiendo otros roles igual de críticos: coordinación, decisiones técnicas, prevención de problemas, simplificación de sistemas. La persona que convence al equipo de no construir una feature innecesaria puede ser la que más valor haya aportado ese trimestre. No tiene ni un token que enseñar, ni miles de líneas de código que cuantificar.

Un ingeniero que consume 200.000 tokens a la semana puede estar resolviendo problemas críticos para el negocio o puede estar ejecutando tareas innecesarias para parecer productivo. Uno que consume 5.000 puede estar escribiendo el código más limpio y más valioso del equipo, o puede estar evitando adoptar herramientas que le harían más efectivo.

El número no te dice nada a nivel individual. Y por eso seguimos en este bucle infinito de métricas individualistas. 

Actividad vs. impacto

Hay una distinción que parece obvia, pero que cuesta mucho aplicar en la práctica: la diferencia entre medir lo que alguien hace y medir lo que alguien consigue.

Las métricas de actividad miden movimiento: tokens consumidos, líneas escritas, horas invertidas, commits realizados. Son cuantificables y comparables. 

Las métricas de impacto miden resultados: ¿cuánto tardamos en entregar valor al usuario? ¿Estamos resolviendo los problemas que importan al usuario? ¿El sistema es más robusto, más mantenible, más barato de operar que hace seis meses? Estas preguntas son más difíciles de responder. Requieren conversación, criterio y alguien dispuesto a hacer zoom out.

Parece que siempre volvemos a la misma conversación: ¿el equipo entrega valor en tiempo y forma? ¿Hemos mejorado el tiempo que tardamos en entregar? ¿Lo entregado se usa, es útil y/o genera dinero para la empresa? ¿Hay menos caídas del software? ¿Hay menos errores y bugs?
Estas métricas no son individuales. Porque la construcción de software tampoco lo es. 

Por eso, si de verdad queremos aplicar métricas que tengan sentido, la mejor palanca es alejarse y mirar algo más arriba: pensar más en performance de equipo y menos en performance de persona. Entender a los equipos como unidades cuyo output conjunto sí es más medible que la suma de las métricas individuales de sus miembros. 

Del x100 Dev al x100 Team

Medir actividad y no impacto nos lleva a la nueva moda: la promesa del x100 Dev: un solo ingeniero, armado con las herramientas de IA adecuadas, capaz de hacer el trabajo de cien. Incluso algunos founders lo están usando como argumento para reducir plantillas. Y no es que no sea cierto, ya hablamos antes de ello, pero volvemos a caer en la misma trampa.

La promesa del x100 Dev comete exactamente el mismo error que el tokenmaxxing: asume que el valor del software es código producido. Y si hemos aprendido algo en décadas de construir equipos técnicos, es que eso no es así.

El software lo construyen equipos. Y los equipos no son simplemente la suma de sus miembros más productivos individualmente. Son el resultado de cómo se comunican, cómo toman decisiones bajo incertidumbre, cómo gestionan el conflicto, cómo alinean criterios técnicos con necesidades de negocio, cómo integran a alguien nuevo, cómo sostienen el ritmo cuando las cosas se complican. Nada de eso lo resuelve un ingeniero más productivo. Nada de eso lo resuelve la IA.

Quizás deberíamos mover la conversación hacia el concepto del x100 Team: usar la IA para multiplicar la capacidad del equipo como unidad, reduciendo la fricción operativa, automatizando lo que no necesita criterio humano y liberando tiempo para lo que sí lo necesita.

Equipos en tiempo de IA

El tokenmaxxing más allá del chascarrillo y la anécdota curiosa de Silicon Valley es un síntoma: una tendencia a medir el valor de las personas por su output directo y cuantificable, y a eliminar todo lo que no aparezca en ningún KPI, todo lo que parece que no da valor directo.

Esa idea llevada al extremo la estamos viendo ya en muchos mensajes y estrategias corporativas: eliminar las capas de coordinación y alineamiento porque "no producen directamente". Los Middle Managers están siendo los primeros damnificados. Hay voces que defienden equipos formados únicamente por ICs, con la IA asumiendo las funciones de coordinación. El argumento suena eficiente. En la práctica, es tokenmaxxing aplicado al organigrama de una empresa. Obsesión por medir la productividad individual. 

Es innegable que la IA ha cambiado la manera en la que trabaja un equipo de software. También la manera en la que contrata una empresa. Y también está cambiando la manera en la que se estructura una compañía. 

Pero no deberíamos volver a la obsesión perpetua de medir la productividad individual. Si no, seguir haciendo hincapié en esos x100 teams. Que la IA no sea la palanca que elimina la necesidad de construir buenos equipos, sino la que multiplique lo que un buen equipo puede conseguir. 

Una vez baje el hype y la conversación vuelva al cauce del sentido común, escucharemos más hablar de los x100 Teams: equipos donde la confianza, la coordinación y el criterio compartido hagan que lo que construyen juntos sea imposible de replicar de manera individual. Con IA o sin ella.