Els tokens no són moneda. Són línies de codi amb factura adjunta.

La Nisha Talagala ha publicat a Forbes un primer sobre tokens on defensa que els tokens — la unitat de cost i mesura del consum dels LLM — s'estan convertint en una moneda de negoci fonamental. Hi introdueix el terme tokenmaxxing, assenyala que ja hi ha empreses avaluant públicament els empleats per ús de tokens i planteja un marc tranquil de pressupostos, seguiment i trade-offs. Com a primer, està bé. Com a full de ruta per a qualsevol organització d'enginyeria que hagi d'entregar amb pressupost, és la versió més educada d'una idea molt perillosa.

La idea perillosa: que l'ús de tokens mesura feina. No la mesura. Mesura factura. Des del seient de qui ha hagut de defensar una línia de cost d'IA davant d'un CFO i una rotació SRE la mateixa setmana, el marc importa més que els números — i Forbes només encerta a mitges.

El que Forbes encerta

Tres coses de l'article són correctes i haurien de ser ja al roadmap de qualsevol CTO:

1. La despesa en tokens és real i creix. L'article cita que una sola revisió d'email consumeix ~100 tokens, amb un cost al voltant de 0,25 cèntims per tasca. Multiplica-ho per cada empleat, cada flux, cada retry, cada agent encadenat — i la partida passa de "error d'arrodoniment" a "negociació amb el CFO" en un trimestre. Les empreses que van arrencar regalant tokens il·limitats als empleats estan, previsiblement, racionant.
2. No tots els tokens són iguals. Forbes encerta: un token no és comparable entre proveïdors, models, tasques i èpoques. Un token a un model de reasoning de frontera no és comercialment equivalent a un token a un model petit open-weights, encara que comptabilitat els vulgui sumar.
3. Cal tooling. El seguiment de tokens generarà la mateixa onada de proveïdors que el cost cloud fa una dècada: un mercat de FinOps per a tokens. Aquest mercat ja s'està formant.

Aquestes tres observacions bastarien per justificar l'article. El problema és la quarta idea que hi encasten a sobre.

On Forbes s'equivoca: el token com a proxy de productivitat

L'article descriu — amb poca crítica — una tendència en què les empreses tracten tokens per empleat per unitat de temps com a mètrica de productivitat. Fins i tot fila l'analogia amb el pressupost de viatges d'un comercial: l'empleat que sub-consumeix el seu pressupost de tokens equival, en aquest marc, al comercial que no agenda visites. Gastar de menys passa a ser senyal negatiu.

Això és la Llei de Goodhart amb vestit nou. Quan una mesura es converteix en objectiu, deixa de ser una bona mesura. El dia que dius als enginyers que el seu ús de tokens s'avalua — formalment, per management, amb pes a la performance review — no has mesurat res sobre productivitat. Has creat un nou mercat de soroll.

Forbes admet el vector d'abús ("els tokens són trivials d'abusar") però el tracta com una qüestió d'higiene gestionable. No ho és. La història de les mètriques d'enginyeria és exactament la història d'aquest mode de fallada:

• Línies de codi per desenvolupador. Mesurades durant dues dècades. Optimitzades escrivint més línies. Premi: bases de codi Fortran 77 que cap humà podia mantenir. La cosa mesurada — valor creat — es va descorrelacionar i acabar anti-correlacionar amb la mètrica. Ja he defensat aquest mateix punt sobre mètriques de productivitat i la mecànica és idèntica.
• Tickets tancats per sprint. Optimitzat partint tickets. O tancant primer els trivials. O inflant l'sprint. Els equips que millor gamejaven la mètrica eren els pitjors entregant.
• Cobertura de tests. Optimitzada escrivint tests que executen línies sense afirmar comportament. La cobertura pujava, els defectes pujaven, els enginyers eren promocionats.

"Tokens consumits per empleat per mes" entra en aquesta nissaga. I és pitjor, perquè cada token gamejat costa diners de veritat a un proveïdor de veritat. Les mètriques de vanitat clàssiques es gamejaven gratis. El tokenmaxxing és gaming pagat, amb la factura desviada a finances.

La mesura honesta és més difícil, i no són tokens

El que realment vols saber d'un enginyer que utilitza eines d'IA és, aproximadament:

• El canvi s'ha entregat?
• S'ha entregat correctament?
• S'ha entregat més ràpid del que hauria estat sense l'eina?
• L'enginyer ha après alguna cosa reutilitzable, o ha subcontractat el pensament?
• El codi resultant és revisable, mantenible i owned?

Cap dels cinc es mesura en tokens. Els quatre primers es mesuren amb mètriques DORA honestes — freqüència de desplegament, lead time, change failure rate, MTTR. El cinquè només es mesura amb code review i temps. No hi ha drecera, i els tokens no són la drecera disfressada.

Forbes assenteix amb la frase "infuse the AI force multiplier" — la idea que és la perícia humana la que dóna valor al token. D'acord. Però aquesta concessió desmunta tot el marc token-budget-as-productivitat que té al costat. Si el multiplicador és l'humà, la unitat rellevant és resultat per enginyer, no tokens per enginyer. La despesa en tokens és un cost d'entrada, com el cloud, l'electricitat o l'oficina — i ningú es promociona per haver gastat més en electricitat.

El que els tokens són realment: una partida de cloud amb pitjors defaults

Si treus l'error mètrica-de-productivitat, el que queda és correcte i val la pena gestionar-ho bé. Els tokens entren en la mateixa corba de maduresa que la despesa cloud, i el playbook de la dècada FinOps s'aplica gairebé sense canvis:

1. Assigna la despesa a resultats, no a persones. Un token consumit per un agent de CI que captura una regressió en producció no és comparable amb un token consumit per un enginyer demanant a un LLM que reformuli un Slack. Etiqueta els tokens per workflow, no per empleat — igual que etiquetaves instàncies EC2 per servei, no per la persona que les havia engegat.
2. Posa quotes per ruta, no per persona. El sobrecost interessant en una organització amb IA rarament és un empleat xerraire. És un agent runaway en un pipeline cridant un model frontera en bucle amb retry-with-backoff. Els pressupostos per empleat no l'agafen. Els pressupostos per eina i per flux sí, igual que els pressupostos per servei van agafar la lambda que feia 3.000 lectures Aurora a les 3 de la matinada.
3. Arbitra preu entre models. Forbes encerta: venedors i preus fluctuen; la resposta correcta és una capa de routing que envia cada tasca al model més barat que compleix el llindar de qualitat per a aquella tasca — no un contracte fix amb un únic venedor frontera a preu de catàleg. L'economia dels models de fundació premia decisions build-vs-buy per càrrega, no estandarditzar en el més car.
4. Observabilitat abans d'incentius. La majoria d'organitzacions està a punt de prendre decisions de política sobre tokens abans de tenir atribució fiable per tasca. L'ordre està malament. Resol primer l'atribució — per servei, per flux, per retry, per resultat de cara a l'usuari — i després parla de pressupostos. Si no, vas a posar quotes sobre soroll.

Això és FinOps amb una altra unitat. No és, i no hauria de ser, performance management.

El que el "tokenmaxxing" diu de debò d'una organització

Si una organització d'enginyeria es troba premiant el consum de tokens — o pitjor, troba els seus enginyers gamejant el consum per semblar productius — el problema no és dels enginyers. És del lideratge que va triar la mètrica. El tokenmaxxing és un símptoma, i la malaltia de fons és la mateixa que veig a cada client que no ha construït una cultura de mesura de debò: management vol un número únic, finances vol un número únic, i la factura del LLM dóna convenientment un número únic que puja.

Una organització d'enginyeria seriosa resisteix aquesta compressió. Fa córrer, com a mínim, dos streams en paral·lel:

• Stream de cost. Què hem gastat en IA, desglossat per workflow, per equip, per model, per mode de retry? On hi ha el malbaratament? Està el router fent la seva feina? Hi ha agents en bucle?
• Stream de resultat. Què s'ha entregat? Què no? Quin és el change failure rate? Les PRs assistides per IA tenen un perfil de defectes diferent que les no-assistides? La IA captura més incidents dels que provoca?

Si només fas córrer el stream de cost, optimitzaràs el consum de tokens — i Forbes està descrivint correctament el tipus d'empresa en què et convertiràs. Si només fas córrer el stream de resultat, no agafaràs l'agent runaway que va incendiar la factura AWS. Et calen tots dos, en dashboards diferents revisats per persones diferents.

El que posaria davant d'un CTO aquest trimestre

1. Atribució per flux abans de pressupostos per empleat. Mentre no puguis anomenar els cinc workflows que més tokens gasten al teu stack, no tens un problema de tokens que puguis resoldre.
2. Un kill-switch per agent, el mateix que defenso com a innegociable per a qualsevol sistema agèntic en producció. Un bucle infinit en un agent és avui un incident de finances tant com un de SRE.
3. Una capa de routing de models, ni que sigui rudimentària. Si tots els equips criden directe al mateix model frontera sense fallback a nivells més barats per a tasques trivials, la teva factura està pagant mandra de plataforma, no productivitat dels enginyers.
4. Una política de mesurament que exclogui explícitament els tokens de l'avaluació individual. Per escrit. I ben alt. El primer dia que un manager elogiï un enginyer per "haver consumit més tokens aquest trimestre", la mètrica està morta i la cultura va al darrere.
5. Una línia pressupostària per al malbaratament. Una part de la despesa en tokens serà exploratòria, sense sortida i irreduïblement experimental. Està bé. Posa-li nom a aquesta partida, pressuposta-la i deixa d'intentar optimitzar-la a zero. La partida de malbaratament és també on passa la major part de l'aprenentatge.

La línia que traço

Forbes encerta que els tokens són ja una partida real que les empreses han de planificar, seguir i governar. Forbes s'equivoca — o si més no és perillosament casual — quan estén aquesta partida fins a convertir-la en mètrica de productivitat individual. El primer és FinOps. El segon és l'error línies-de-codi reeditat amb una factura de proveïdor enganxada.

Les empreses que navegaran bé els pròxims dos anys seran les que tractaran els tokens amb la mateixa disciplina avorrida que (finalment) van aprendre a aplicar al cloud: assignar despesa a resultats, encaminar la feina al model més barat que basta, observar abans d'incentivar, i mai — mai — promocionar un enginyer per consumir més de l'input.

Els tokens són el cost. L'enginyer és el multiplicador. Si les teves mètriques confonen els dos, no tens una estratègia d'IA. Tens una factura d'IA.

---

Fonts:

• Nisha Talagala, Are Tokens The New Currency? A Primer For Business, Forbes, maig de 2026. forbes.com
• The Pragmatic Engineer, The Pulse: Tokenmaxxing as a weird new trend. blog.pragmaticengineer.com
• Wall Street Journal, Why Some Companies Say AI Tokenmaxxing Is Key To Survival. wsj.com

Estàs posant un equip d'enginyeria potenciat per IA sota un pressupost real i no saps com mesurar-lo sense trencar l'equip? Parla amb un CTO — t'ajudem a separar la factura de la feina.