Mi feed de LinkedIn está lleno de ello desde hace semanas. Mi línea de tiempo X también. Gente publicando capturas de pantalla de gastos de tokens como si fueran informes de progreso. Fundadores de startups alardeando de que gastaron 16.000 dólares en Claude Code el mes pasado y que aspiran a 60.000 dólares el próximo. Tablas de clasificación. Clasificaciones. Títulos como "Token Legend" y "AI God".
Y entonces, la semana pasada, alcanzó la masa crítica. Forbes informó sobre el movimiento "tokenmaxxing" que arrasa en Silicon Valley, donde las empresas compiten para ver quién quema más tokens de IA. Jensen Huang acudió al podcast All-In y dijo: "A ese ingeniero de 500.000 dólares, al final del año, le voy a preguntar: '¿Cuánto gastaste en tokens? Si esa persona dice '5.000 dólares' me pondré como un mono. Si ese ingeniero de 500.000 dólares no consumió al menos 250.000 dólares en fichas, me voy a alarmar profundamente".
Entonces Fortune informó de que un empleado de Meta había construido una tabla de clasificación interna llamada "Claudeonomics" que rastreaba el consumo de tokens entre los más de 85.000 empleados de la empresa. Los mejores usuarios recibían títulos. En un periodo de 30 días, el uso total alcanzó los 60 billones de tokens. El mejor usuario individual alcanzó una media de 281.000 millones. Mark Zuckerberg ni siquiera se coló entre los 250 primeros. Mientras tanto, Andrew Bosworth, director de tecnología de Meta, decía públicamente que su mejor ingeniero gastaba su salario equivalente en tokens pero era "entre 5 y 10 veces más productivo". "Es como, esto es dinero fácil", dijo Bosworth. "Sin límite".
Llevo en el mundo del software el tiempo suficiente para reconocer lo que está pasando aquí. Esto son "líneas de código" con un precio mucho más alto.
Hemos estado aquí antes
En 2003, Martin Fowler escribió un breve artículo sobre por qué no se puede medir la productividad del software que probablemente debería ser de lectura obligatoria para todo ejecutivo técnico. Su argumento sobre las líneas de código era preciso:
"Una de mis mayores irritaciones son los estudios de productividad basados en líneas de código. Cualquier buen desarrollador sabe que puede codificar lo mismo con enormes variaciones en líneas de código".
El problema es obvio una vez que se dice en voz alta. El LOC mide la actividad, no la producción. Dos desarrolladores pueden construir la misma función: uno escribe 1.200 líneas, el otro escribe 80. El más conciso probablemente construyó un sistema mejor. En un régimen de LOC, el verborreico parece más productivo.
Los equipos evaluados en función de la LOC respondieron racionalmente. Escribieron más líneas. Copiaron y pegaron en lugar de abstraer. Evitaron la refactorización porque borrar código perjudicaría sus cifras. La métrica moldeó el comportamiento, pero no hacia un software mejor. Más código. Sistemas peores.
Entonces, en 2023, McKinsey publicó un artículo en el que afirmaba haber descifrado la medición objetiva de la productividad de los desarrolladores. La exhaustiva respuesta de Gergely Orosz y Kent Beck señalaba el mismo fallo: casi todas las métricas de McKinsey medían el esfuerzo y la producción, no los resultados. Kent Beck relató cómo las encuestas internas de Facebook sobre el sentimiento de los desarrolladores pasaron de ser una retroalimentación útil a convertirse en negociaciones de los directivos con los ingenieros para obtener puntuaciones más altas. Eso es lo que ocurre cuando se incentiva una métrica indirecta. La cifra mejora. Lo que realmente importa no lo hace.
Se podría pensar que hemos aprendido. No lo hemos hecho.
Mismo error, diferente unidad
La seductora lógica del tokenmaxxing funciona así. Consumo de fichas = uso de IA. Más uso de IA = los equipos están utilizando IA. Por lo tanto, alto consumo de tokens = alta adopción de IA = bueno.
Es precisamente tan erróneo como medir las líneas de código, sólo que con un panel de facturación en lugar de un gráfico de commit. Y para ser justos con el artículo de Forbes, el consejero delegado de Sendbird, John Kim, básicamente dijo exactamente eso: "Ya hemos visto esta película antes". Se refería a la cultura del LOC de los años 90 y 2000. El verdadero indicador, señaló, es cuánto código generado por IA llega realmente a la producción. El gasto en fichas "es más bien un iniciador de conversación". Estoy de acuerdo. Se convierte en un problema cuando el iniciador de la conversación se convierte en el KPI principal.
La encuesta de desarrolladores 2024 de GitHub descubrió que el 97% de los desarrolladores empresariales habían utilizado herramientas de codificación de IA en el trabajo en algún momento. Sin embargo, una adopción organizativa significativa requiere políticas claras, flujos de trabajo y resultados medibles vinculados a resultados empresariales reales. No sólo uso. No sólo consumo.
Boris Cherny, el ingeniero detrás de Claude Code, compartió públicamente que no abrió un IDE en absoluto durante un mes de trabajo, con Opus 4.5 escribiendo alrededor de 200 PRs. Eso es impresionante. Pero lo que lo hace impresionante no son los tokens que consumieron esos 200 PRs. Es que fueron 200 contribuciones fusionadas reales con software funcional en el otro extremo.
El valor está en el resultado. Los tokens son la energía que te ha llevado hasta ahí, nada más.
Cuando la métrica se convierte en el objetivo
Existe un principio llamado Ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. La historia del desarrollo de software es básicamente un museo de la Ley de Goodhart en acción.
El seguimiento de los tokens como KPI de adopción de la IA establece exactamente la misma dinámica. Los equipos de ingeniería que se midan por el consumo de tokens consumirán más tokens. Así es como funcionan los incentivos. ¿Quiere parecer más productivo? Ejecute algunos bucles agénticos más. Deje que el modelo razone largamente antes de generar la salida. Envuelva cada tarea en una capa de orquestación que llame a cuatro herramientas donde bastaría con una. El gasto en fichas aumenta. El valor entregado no.
En realidad, la historia de Claudeonomics lo demostró casi de inmediato. Fortune señaló que "algunos empleados han puesto a trabajar durante horas a agentes de IA para maximizar el uso de tokens". Ahí está. La Ley de Goodhart ejecutándose en tiempo real, dentro de una empresa que se supone que está en la frontera de la productividad impulsada por la IA. La tabla de clasificación llevaba en funcionamiento unas pocas semanas antes de que se cerrara, y los empleados ya estaban jugándosela ejecutando agentes en bucle. La métrica tenía tres semanas y ya había dejado de medir lo que se suponía que debía medir.
Cualquier desarrollador que lea esto probablemente pueda pensar en cinco formas de inflar las métricas de uso de tokens sin beneficiar a nadie. No voy a enumerarlas. Pero si yo puedo pensar en cinco, también pueden hacerlo los ingenieros que están siendo medidos en esto.
Andrej Karpathy describió el momento actual de la ingeniería de software como un "terremoto de magnitud 9" para la profesión. Tiene razón. Pero los terremotos no se miden en la electricidad consumida. Se miden en lo que se ha movido.
La versión documental de este problema
Esto no es sólo un problema para los equipos de ingeniería. Veo la misma dinámica en la gestión del conocimiento, que está mucho más cerca de casa para nosotros en Rasepi.
"Hemos publicado 400 documentos este trimestre" es una cifra que suena bien en una presentación de diapositivas. No tiene nada que decir sobre si esos documentos son precisos, si alguien los leyó o si la información que contienen sigue siendo cierta seis meses después. Se puede alcanzar esa cifra con IA y sin pensar en absoluto. Ruido asistido por tokens publicado a escala.
La métrica honesta es más difícil de recopilar pero mucho más útil: ¿qué porcentaje de su base de conocimientos refleja realmente el funcionamiento actual de sus sistemas? ¿Cuántas personas llegaron a una respuesta correcta utilizando su documentación? ¿Cuántos lo intentaron, fracasaron y acabaron preguntando a alguien en Slack en su lugar?
Esas preguntas aún no tienen bonitos cuadros de mando. Requieren una reflexión real sobre lo que quiere que la documentación haga por su organización. (Esto es, no por casualidad, exactamente el problema en torno al cual se construye Rasepi. Las fechas de caducidad forzadas existen precisamente para que los equipos tengan que calcular si el contenido sigue siendo válido, en lugar de dejar que decaiga silenciosamente detrás de una métrica de alto número de páginas).
Qué rastrear en su lugar
La respuesta honesta a "¿está dando frutos nuestra inversión en IA?" no puede leerse en un cuadro de mandos de facturación.
Puede aproximarla con mejores preguntas: ¿están mejorando los tiempos de ciclo? ¿La proporción entre las características enviadas y los errores notificados tiende en la dirección correcta? ¿Informan los ingenieros de que dedican más tiempo al trabajo de juicio y menos al mecanografiado? ¿Se mantiene actualizada su documentación en lugar de acumularse como un sedimento?
Estos datos son más difíciles de extraer de una API. Requieren pensar qué resultados quiere realmente de sus equipos, lo cual, hay que reconocerlo, es el trabajo más duro. Pero son las preguntas que importan, porque se refieren a los resultados más que a las entradas.
El gasto en fichas le dice cuánto cálculo ha comprado. Si ese cómputo se convirtió en algo útil es una cuestión totalmente distinta. Las empresas que no mantengan esa distinción van a construir cuadros de mando muy caros que no les mostrarán casi nada.
Pasamos años optimizando la métrica equivocada para la productividad de los desarrolladores. Tenemos quizá un trimestre antes de que el mismo error se cuele en todos los informes de adopción de la IA en la empresa. La ventana para evitarlo está abierta, pero no se quedará así.