En mayo escribí "Los mejores desarrolladores, consumen menos tokens". La tesis era simple: medir productividad por volumen de tokens es absurdo, el buen desarrollador hace más con menos, y la eficiencia es una disciplina de ingeniería.
Luego, cuando las empresas empezaron a racionar el acceso a Claude y GPT por presupuesto, escribí "Cuando te limitan o cortan los tokens, ¿te quedas sin trabajo?". El argumento evolucionó: ya no era una cuestión de estilo, era supervivencia profesional. El desarrollador que delegó su criterio en el modelo quedó paralizado cuando le cortaron el acceso.
Y ahora, me encuentro con este artículo de IBM donde acuñan un término para exactamente lo que veníamos argumentando: valuemaxxing.
Tokenmaxxing: la trampa de medir volumen
El artículo de IBM describe el tokenmaxxing como "la práctica de maximizar el uso de IA en los flujos de trabajo de desarrollo con la convicción de que el consumo intensivo eventualmente llevaría a mejores resultados", exactamente lo que critique en mayo: los leaderboards que premian al equipo que consume más tokens, como si la meta fuera volcar todo nuestro pensamiento en estas herramientas en vez de coexistir con ellas.
Neil Dhar, SVP de IBM Consulting comenta: "En ausencia de métricas reales, las organizaciones crearon leaderboards de uso, que la gente rápidamente aprendió a manipular. El uso pronto se convirtió en un proxy del valor."
La trampa inversa: token minimization
Cuando las empresas se dieron cuenta de que el consumo ilimitado era insostenible, cayeron en la trampa opuesta: minimizar tokens a toda costa. Restringir modelos, cortar prompts, y por supuesto, contratar consultoría en cómo hacer esto correctamente.
IBM explica:
"Las organizaciones a menudo confunden reducir el consumo visible de tokens con reducir los costos reales. Una vez que se eliminan las ineficiencias obvias, las reducciones adicionales frecuentemente atacan la información que ayuda a los sistemas de IA a tener éxito: descripciones de tareas, restricciones de negocio, contexto arquitectónico."
Te ahorras 500 tokens de contexto y pagas 2000 tokens en re-intentos y re-trabajo humano. El costo no desaparece, se mueve.
Esto es exactamente lo que argumenté: el desarrollador que sabe qué preguntar y cómo preguntarlo puede hacer arquitectura con un modelo de menor capacidad. El que no sabe guiar la conversación necesita que el modelo sea suficientemente inteligente para inferir lo que él ni siquiera articuló.
Valuemaxxing: medir resultados, no tokens
La propuesta valuemaxxing implica mover la conversación hacia resultados directos.
En vez de preguntar "¿cuántos tokens usamos?", preguntar:
- ¿Cuántas tareas se completaron?
- ¿Cuánto tiempo de desarrollador se ahorró?
- ¿Cuánto trabajo de modernización se aceleró?
- ¿Cuántas vulnerabilidades se resolvieron?
- ¿Cuánto re-trabajo se evitó?
Estas son las métricas que determinan si la IA está creando valor de negocio y si el consumo incremental de tokens está justificado.
Esto es lo que llamé "soberanía" anteriormente: no se trata de cuántos tokens consumes, sino de quién está guiando la interacción.
El desarrollador que usa la herramienta para potenciar su intención sigue en pie cuando le cortan el acceso.
El desarrollador que usa la herramienta para potenciar su intención sigue en pie cuando le cortan el acceso.
Modelos como infraestructura, sistemas como diferenciador
IBM hace un punto que conecta con lo que escribí en abril sobre Human-Augmented AI Development: el acceso a modelos eficientes ya no es el diferenciador principal. La ventaja competitiva se está moviendo del modelo mismo hacia los sistemas construidos alrededor: gestión de contexto, orquestación de flujos, memoria, gobernanza, evaluación y optimización.
Si los resultados importan más que los tokens, entonces los sistemas (outputs) importan más que los modelos (inputs). Esto es exactamente lo que significa "human-augmented": el humano no es un apéndice del modelo, es el arquitecto del sistema. El modelo es una pieza de infraestructura, no el cerebro.
La responsabilidad es compartida
IBM cierra con un punto que me parece crucial: desarrolladores y líderes son ambos responsables.
Para los desarrolladores, la eficiencia con IA se está convirtiendo en una nueva habilidad de ingeniería. Pensar en el uso de IA como piensas en recursos de cloud, bases de datos o rendimiento de aplicaciones. El objetivo no es usar menos IA, sino usarla de manera más efectiva.
Para los líderes, la responsabilidad es crear visibilidad tanto en costos como en resultados. Medir valor en vez de volumen. Y las plataformas también deben ser responsables. No puedes optimizar para un solo modelo cuando los modelos, costos y IA empresarial siguen evolucionando.
En fin
Lo escribí en mayo como una preferencia casi filosófica. Lo actualicé cuando la realidad corporativa me dio la razón. Y ahora IBM lo valida desde el enterprise con un nombre bonito: valuemaxxing.
La narrativa está completa: no se trata de maximizar ni minimizar tokens. Se trata de medir resultados, conservar agencia sobre tu propio trabajo, y entender que el pensamiento central sigue siendo tuyo.
No es virtud. Es ventaja competitiva. Y ahora IBM también lo dice.
Fuentes: https://www.ibm.com/think/insights/tokenmaxxing-dead-long-live-valuemaxxing
Foto de Jp Valery en Unsplash
Fuentes: https://www.ibm.com/think/insights/tokenmaxxing-dead-long-live-valuemaxxing
Foto de Jp Valery en Unsplash
