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

Nisha Talagala ha publicat a Forbes una introducció als tokens per a directius on defensa que els tokens — la unitat amb què es mesura i es factura el consum dels LLM — s'estan convertint en una moneda fonamental per a les empreses. Hi presenta el terme tokenmaxxing, assenyala que ja hi ha empreses que avaluen públicament els empleats pel consum de tokens, i exposa amb calma un marc de pressupostos, seguiment i compromisos. Com a introducció, està bé. Com a full de ruta per a una organització d'enginyeria que ha d'entregar de debò amb un pressupost tancat, é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. Ho dic com a algú que ha hagut de defensar, la mateixa setmana, una línia de cost d'IA davant del CFO i una rotació d'SRE: el marc importa més que els números — i Forbes només l'encerta a mitges.

On Forbes l'encerta

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

1. La despesa en tokens és real i va a més. L'article cita el cas d'una sola revisió d'un correu, que consumeix uns 100 tokens amb un cost aproximat de 0,25 cèntims de dòlar per tasca. Multiplica-ho per cada empleat, cada flux de treball, cada retry, cada agent encadenat, i la partida passa d'«error d'arrodoniment» a «cal negociar amb el CFO» en un sol trimestre. Les empreses que van començar donant tokens il·limitats als empleats ara, com era previsible, els racionen.
2. Els tokens no són uniformes. Forbes té raó: no tots els tokens valen igual — entre proveïdors, entre models, entre tasques i al llarg del temps. Un token d'un model de raonament de frontera no és comercialment comparable a un token d'un model petit open-weights, encara que comptabilitat els vulgui sumar.
3. Calen eines. El seguiment de tokens produirà la mateixa onada de proveïdors que va produir el cost del cloud fa una dècada: un mercat de FinOps per a tokens. Aquest mercat ja s'està formant.

Aquestes tres observacions ja justificarien l'article per si soles. El problema és la quarta idea que hi han cargolat al damunt.

On Forbes s'equivoca: els tokens com a proxy de productivitat

L'article descriu — sense prou esperit crític — una tendència en què les empreses tracten els tokens per empleat i unitat de temps com a mètrica de productivitat. Fins i tot estira l'analogia del pressupost de viatges d'un comercial: l'empleat que no s'acaba el pressupost de tokens equival, en el marc de l'article, al comercial que no concerta visites amb clients. Gastar poc passa a ser un 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 consum de tokens s'avalua — formalment, des de direcció, amb pes a la revisió d'acompliment — no has mesurat res sobre productivitat. Has creat un mercat nou de soroll.

Forbes reconeix el vector d'abús («abusar dels tokens és trivial»), però el tracta com una qüestió d'higiene gestionable. No ho és. La història de les mètriques d'enginyeria és la història d'exactament aquest mode de fallada:

• Línies de codi per desenvolupador. Es van mesurar durant dues dècades. Es van optimitzar escrivint més línies de codi. El premi van ser bases de codi en Fortran 77 que cap humà podia mantenir. Allò que es volia mesurar — el valor creat — no tenia cap correlació amb la mètrica, i va acabar tenint-ne de negativa. Ja he defensat exactament aquest argument per a les mètriques de productivitat i la mecànica de fons és idèntica.
• Tiquets tancats per sprint. S'optimitzava partint tiquets. O tancant primer els trivials. O inflant els sprints. Els equips que millor feien trampes amb la mètrica eren els que pitjor entregaven.
• Percentatge de cobertura de tests. S'optimitzava escrivint tests que executen línies sense verificar cap comportament. La cobertura pujava, els defectes pujaven, i els enginyers ascendien.

«Tokens consumits per empleat i mes» pertany a aquesta nissaga. I encara és pitjor, perquè cada token de trampa costa diners de veritat a un proveïdor de veritat. Les mètriques de vanitat clàssiques es podien falsejar gratis. El tokenmaxxing és fer trampes de pagament, amb la factura encaminada cap a finances.

La mesura honesta és més difícil, i no es fa en tokens

El que de debò vols saber d'un enginyer que treballa amb eines d'IA és, aproximadament, això:

• El canvi s'ha entregat?
• S'ha entregat bé?
• S'ha entregat més de pressa que sense l'eina?
• L'enginyer n'ha après alguna cosa reutilitzable, o ha externalitzat el pensament?
• El codi que en surt és revisable, mantenible i amb un propietari clar?

Cap d'aquestes cinc coses no es mesura en tokens. Les quatre primeres es mesuren amb mètriques de resultat a l'estil DORA — freqüència de desplegament, lead time, taxa de canvis fallits, temps mitjà de recuperació — aplicades amb honestedat. La cinquena només es mesura amb revisió de codi i temps. No hi ha drecera, i els tokens no són la drecera disfressada.

L'article de Forbes ho apunta amb la frase «infuse the AI force multiplier» — que vol dir, en llenguatge pla, que el que dona valor a un token és l'expertesa de domini de l'humà. D'acord. Però aquesta admissió desmunta tot el marc de pressupost-de-tokens-com-a-mètrica que té al costat. Si el multiplicador és l'humà, la unitat que importa és el resultat per enginyer, no els tokens per enginyer. La despesa en tokens és un cost d'entrada, com el cloud, l'electricitat o l'oficina — i a ningú no l'ascendeixen per gastar més en electricitat.

Què són els tokens en realitat: una partida de cloud amb pitjors defaults

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

1. Assigna la despesa a resultats, no a persones. Un token consumit per un agent de CI que caça una regressió a producció no és comparable amb un token consumit per un enginyer que demana a un LLM que li reformuli un missatge de Slack. Etiqueta els tokens per workflow, no per empleat — igual que etiquetaves les instàncies EC2 per servei, no per l'enginyer que les havia engegades.
2. Posa quotes per ruta, no pressupostos per persona. El sobrecost interessant en una organització augmentada amb IA gairebé mai és un empleat xerraire. És un agent desbocat dins d'un pipeline automatitzat que crida un model de frontera en bucle amb retry-with-backoff. Els pressupostos per empleat no el caçaran. Els pressupostos per eina i per workflow, sí — igual que els pressupostos per servei al cloud van caçar la lambda que disparava lectures d'Aurora a les tres de la matinada.
3. Arbitra preus entre models. Forbes té raó que els proveïdors i els preus fluctuen; la resposta correcta és una capa d'encaminament que enviï cada tasca al model més barat que superi el llistó de qualitat d'aquella tasca — no un contracte fix amb un sol proveïdor de frontera a preu de tarifa. L'economia dels models fundacionals premia decidir amb cura, càrrega a càrrega, entre construir i comprar, no estandarditzar-se en l'opció més cara.
4. Construeix observabilitat abans que incentius. La majoria d'organitzacions són a punt de prendre decisions de política sobre tokens abans de tenir una atribució fiable per tasca. L'ordre és exactament l'invers. Primer encerta l'atribució — per servei, per workflow, per retry, per resultat de cara a l'usuari — i després parla de pressupostos. Si no, posaràs quotes sobre soroll.

Això és FinOps amb una altra unitat. No és, i no hauria de ser, gestió del rendiment de les persones.

Què diu de debò el «tokenmaxxing» d'una organització

Si una organització d'enginyeria acaba premiant el consum de tokens — o pitjor, si descobreix que els seus enginyers inflen 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ò: la direcció vol un sol número, finances vol un sol número, i la factura de l'LLM és, convenientment, un sol número que puja.

Una organització d'enginyeria de debò resisteix aquesta compressió. Treballa, com a mínim, amb dues vies en paral·lel:

• Una via de cost. Què hem gastat en eines d'IA, desglossat per workflow, per equip, per model, per mode de retry? On és el malbaratament? La capa d'encaminament fa la seva feina? Hi ha agents en bucle?
• Una via de resultats. Què s'ha entregat? Què no? Quina ha estat la taxa de canvis fallits? Les PR assistides per IA tenen un perfil de defectes diferent de les altres? La IA ha caçat més incidents dels que ha provocat?

Si només segueixes la via del cost, acabaràs optimitzant el consum de tokens — i Forbes descriu amb precisió la mena d'empresa en què et convertiràs. Si només segueixes la via dels resultats, no caçaràs l'agent desbocat que t'ha calat foc a la factura d'AWS. Et calen totes dues, i han de viure en dashboards diferents revisats per persones diferents.

El que posaria sobre la taula d'un CTO aquest trimestre

1. Atribució per workflow abans que pressupostos per empleat. Mentre no sàpigues dir quins són els cinc workflows del teu stack que gasten més tokens, no tens cap problema de tokens que es pugui resoldre.
2. Un kill-switch per agent, del mateix tipus que defenso com a innegociable per a qualsevol sistema agèntic en producció. Un bucle infinit en un agent és, avui, tant un incident de finances com un d'SRE.
3. Una capa d'encaminament de models, ni que sigui rudimentària. Si tots els equips criden directament el mateix model de frontera, sense recurs a nivells més barats per a les tasques trivials, la factura de tokens està pagant la mandra de la teva plataforma, no la productivitat dels teus enginyers.
4. Una política de mesura que exclogui explícitament els tokens de l'avaluació individual. Per escrit. I ben fort. El primer cop que un mànager elogiï un enginyer per «haver consumit més tokens aquest trimestre», la mètrica ja és morta i la cultura anirà al darrere.
5. Una línia al pressupost per al malbaratament. Una part de la despesa en tokens serà exploratòria, de carreró sense sortida i irreductiblement experimental. No passa res. Posa-hi nom, pressuposta-la i deixa d'intentar optimitzar-la fins a zero. La línia de malbaratament és, també, on passa la major part de l'aprenentatge.

On traço la línia

Forbes té raó que els tokens ja són una partida real que les empreses han de planificar, seguir i governar. I s'equivoca — o com a mínim és perillosament frívol — quan estira aquesta partida fins a convertir-la en una mètrica de productivitat individual. La primera cosa és FinOps. La segona és l'error de les línies de codi reeditat amb una factura de proveïdor adjunta.

Les empreses que sortiran ben parades dels pròxims dos anys seran les que tractin els tokens amb la mateixa disciplina avorrida que (al final) van aprendre a aplicar al cloud: assignar la despesa a resultats, encaminar la feina al model més barat que faci el fet, observar abans d'incentivar, i no ascendir mai — mai — un enginyer per haver consumit més input.

Els tokens són un cost. L'enginyer és el multiplicador. Si les teves mètriques confonen aquestes dues coses, 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 intentant posar sota un pressupost real un equip d'enginyeria augmentat amb IA, i no saps com mesurar-lo sense trencar l'equip? Parla amb un CTO — t'ajudem a separar la factura de la feina.