In 30 dagen tijd verwerkten Meta-medewerkers ongeveer 60 biljoen AI-tokens via een intern klassement dat hen rangschikte op basis van verbruik; een rekening die waarschijnlijk de 100 miljoen dollar overschreed voor werk dat grotendeels voor de show was. Negentig dagen later was het klassement verdwenen en legde het bedrijf strenge beperkingen op aan het gebruik van AI.
Dat proces wordt ‘tokenmaxxing’ genoemd: het is het moment waarop het maximaliseren van het gebruik van AI-tokens wordt gepromoot tot een prestatiescore en een indicator van productiviteit. Bedrijven zijn inmiddels wijzer geworden, en sommige zijn te ver doorgeschoten in een fenomeen dat de bijnaam ‘tokenminning’ heeft gekregen: het gebruik van zo min mogelijk AI-tokens om de rekenkosten te verlagen. Beide benaderingen mislukken omdat ze het aantal tokens behandelen als een betrouwbare indicator voor door AI aangestuurde groei.
In dit artikel bespreken we wat tokenmaxxing daadwerkelijk kost, hoe ingenieurs het systeem omzeilden en welke installatie bestand is tegen mensen die goed zijn in het manipuleren van nummers.
TL;DR: Tokenmaxxing, oftewel het beschouwen van het gebruik van AI-tokens als een teken van productiviteit, faalt als managementpraktijk omdat het verbruik van tokens een kostenindicator is. Toch werd het behandeld als een prestatiemaatstaf. Het betrouwbare alternatief voor tokenmaxxing is een koppelingsregel: elk gebruiks signaal dat een team publiceert, moet gepaard gaan met een daadwerkelijk resultaat dat niet kan worden opgeblazen.
Om dit te bereiken moeten bedrijfs- en AI-leiders de gegevens op teamniveau samenvoegen, deze buiten prestatiebeoordelingen houden en afwijkingen in de uitgaven gebruiken om onderzoeken te starten. Bedrijven die dit patroon volgden, behielden een bruikbaar signaal. Degenen die individuen rangschikten, verloren dit binnen een kwartaal.
Wat is tokenmaxxing?
Tokenmaxxing is de praktijk waarbij het verbruik van AI-tokens wordt gemaximaliseerd en een hoger verbruik wordt gezien als bewijs van grotere productiviteit of een grotere acceptatie van AI. Tokens zijn de eenheden die een AI-model als input verwerkt en als output produceert.
Het gebruik van tokens werd een aantrekkelijke prestatiemaatstaf omdat het zichtbaar en meetbaar is en al door veel AI-platforms wordt bijgehouden. Daardoor is het makkelijker voor de rapportage dan resultaten zoals tijdwinst, verbeterde beslissingen of gegenereerde omzet. Maar tokens meten rekenactiviteit, niet nuttig werk. Herhaalde prompts, mislukte agent-loops en zinloze output zorgen er allemaal voor dat het nummer omhoog gaat, terwijl er niets wordt geproduceerd.
AI-agenten maken dit nog erger. Een agent leest de context, roept tools op, herziet zijn eigen werk en draagt taken over aan andere agenten. Elke stap kost tokens. Hoewel meer activiteit meer nuttig werk kan betekenen, kan het ook leiden tot inefficiënte werkstroomen en stijgende kosten.
Simpel gezegd is de belangrijkste tekortkoming van tokenmaxxing dat teams het zichtbare nummer maximaliseren, terwijl de productiviteit, kwaliteit en het rendement op de investering gelijk blijven.
Waarom werd tokenmaxxing populair?
Tokenmaxxing werd populair omdat het management een nummer nodig had om aan te tonen dat er daadwerkelijk AI werd geïmplementeerd binnen bedrijven. En het tokengebruik was de enige statistiek die in de factureringsconsole te zien was.
Jensen Huang, CEO van Nvidia, zette begin 2026 de toon in de All-In Podcast met een gedachte-experiment over de tokenrekening van een goedbetaalde ingenieur.
„Als de ingenieur van 500.000 dollar niet minstens voor 250.000 dollar aan tokens verbruikte, zou ik me ernstig zorgen maken”, zei hij. En als het antwoord 5.000 dollar zou zijn? Dan zou hij door het lint gaan.
„Als de ingenieur van 500.000 dollar niet minstens voor 250.000 dollar aan tokens verbruikte, zou ik me ernstig zorgen maken”, zei hij. En als het antwoord 5.000 dollar zou zijn? Dan zou hij door het lint gaan.
Het gebruik van AI was een zichtbare indicator geworden van wie er bijbleef. Dit gebeurde in een tijd waarin tijdens elke planningsvergadering vragen rezen over welke rollen door AI zouden worden overgenomen. Ingenieurs die tokens uitgaven, leken zich aan te passen aan het nieuwe paradigma, terwijl degenen die dat niet deden het risico liepen als een probleem te worden gezien.
Hier zit de ironie: het eerste token-klassement was nooit bedoeld als wedstrijd. Shopify ontwikkelde het om te begrijpen waarom zijn topklanten zoveel uitgaven, niet om hen ten opzichte van elkaar te rangschikken. VP en hoofd Engineering Farhan Thawar beschreef later hoe de tool zich verder ontwikkelde.
Het bedrijf gaf het de nieuwe naam ‘dashboard’, voegde circuitbreakers en uitgavenwaarschuwingen toe en gebruikte de gegevens om op hol geslagen agents en infrastructuurfouten op te sporen. Farhan schreef:
Tokenmaxxing is een controversieel onderwerp. Meer betekent niet per se beter. We hebben het eerste ranglijst voor AI-tokens opgesteld. Daarna hebben we onze visie bijgesteld. Het werd een dashboard. Dezelfde gegevens, maar in een ander kader. We hebben circuitbreakers en uitgavenpieken toegevoegd. We hebben op hol geslagen agents opgespoord. We hebben bugs in onze eigen infrastructuur ontdekt. Het echte signaal: niet wie het meest heeft uitgegeven, maar degenen wiens tokens de grootste impact hebben gegenereerd. Dat zijn de engineers met wie ik wil praten.
Tokenmaxxing is een controversieel onderwerp. Meer betekent niet automatisch beter. We hebben het eerste AI-tokenklassement opgezet. Daarna hebben we onze visie bijgesteld. Het werd een dashboard. Dezelfde gegevens, maar in een ander kader. We hebben circuitbreakers en uitgavenpieken toegevoegd. We hebben op hol geslagen agents opgespoord. We hebben bugs in onze eigen infrastructuur ontdekt. Het echte signaal: niet wie het meest heeft uitgegeven, maar degenen wiens tokens de grootste impact hebben gegenereerd. Dat zijn de engineers met wie ik wil praten.
De meeste bedrijven die het klassement van Shopify hebben gekopieerd, gebruikten het om medewerkers te rangschikken in plaats van de AI-uitgaven te onderzoeken. De onderstaande tabel laat zien hoe dat bij elk bedrijf is verlopen.
| Bedrijf | Het mechanisme | Wat er daarna gebeurde |
|---|---|---|
| Shopify | Het eerste bekende token-klassement, gebruikt om grote besteders in kaart te brengen | Omgedoopt tot een ‘gebruiksdashboard’, met ingebouwde beveiligingen om op hol geslagen agents in toom te houden |
| Meta | „Claudeonomics“, een door medewerkers opgezette ranglijst met de top 250 van meer dan 85.000 medewerkers, met titels als „Token Legend“ | 60. 2 biljoen tokens in 30 dagen; binnen enkele dagen na berichtgeving in de pers uit de lucht gehaald |
| Amazon | Kirorank, een onofficieel klassement dat ontwikkelaars beoordeelt op basis van hun Kiro AI-activiteit, met PhoneTool-badges als prijzen | Medewerkers gaven de agents triviale en verzonnen taken, en het klassement werd geschrapt |
| Uber | Geen ranglijst; Claude Code is uitgerold naar ongeveer 5.000 ingenieurs | Het jaarlijkse AI-budget was binnen vier maanden opgebruikt, waarna er een maandelijkse limiet van $1.500 per tool werd ingesteld |
| Walmart | Code Puppy, een interne AI-agent met aanvankelijk onbeperkte tokens | Vaste tokenvergoeding per medewerker na dubbele aanvragen die de kosten opdreven |
Het patroon in deze tabel is consistent. Organisaties die tokengegevens gebruikten om hoge uitgaven te onderzoeken, behielden een bruikbaar signaal. Andere organisaties die de gegevens gebruikten om mensen te rangschikken, verloren dat signaal binnen een kwartaal.
Hoe hebben ingenieurs hun tokengebruik opgeblazen?
Engineers bliezen hun tokengebruik op door dure AI-activiteiten te genereren die ze nooit van plan waren uit te rollen. The Pragmatic Engineer deed rapportage van dit gedrag bij Meta, Microsoft en Salesforce en ontdekte vier veelvoorkomende tactieken. Bij geen van deze tactieken was sprake van kwade opzet. Mensen zagen simpelweg een zichtbaar nummer, maakten zich zorgen over ontslagen en gingen ervan uit dat intensief AI-gebruik hen zou beschermen:
- Onnodige vragen stellen aan de AI: Ingenieurs stelden de AI vragen over code die al gedocumenteerd was. Het model las de documentatie door en gaf repetitieve en verkeerde antwoorden, terwijl het een groot aantal tokens verbruikte
- Wegwerp-prototypes bouwen: Ze bouwden functies die ze nooit wilden gebruiken, voerden nog een paar extra rondes uit en verwijderden vervolgens de vertakking
- De agent voor alles gebruiken: Ze gaven de AI taken die ze met de hand sneller konden afhandelen, alleen maar om het gebruik ervan te vergroten
- Parallelle agents draaien: Ze zetten meerdere agents in om elkaars werk te beoordelen en te bespreken, wat weliswaar lange logbestanden opleverde, maar geen werkende software.
Veel ingenieurs keken wat hun collega’s verbruikten. Vervolgens verbruikten ze net genoeg om iets boven het gemiddelde uit te komen. Ze wilden niet zozeer de eerste plaats innemen, maar vooral niet worden aangemerkt als iemand die onvoldoende gebruikmaakt van AI.
Bij Amazon gaven medewerkers triviale en verzonnen taken aan AI-agenten om hun Kirorank-scores te verhogen. Dit verhoogde de cloudkosten zonder dat er enige zakelijke output werd gegenereerd. Toen Amazon het klassement afschafte, vertelde Senior Vice President Dave Treadwell het personeel dat het met goede bedoelingen was opgezet. Vervolgens vroeg hij ronduit: “Gebruik AI alsjeblieft niet alleen maar omwille van het gebruik van AI.”
Als onderdeel van deze verandering houdt Amazon nu bij of door AI gegenereerde code werkt en waarde oplevert. Het verbruik van tokens is niet de belangrijkste prioriteit.
Hoeveel heeft tokenmaxxing bedrijven gekost?
Tokenmaxxing heeft Meta waarschijnlijk meer dan 100 miljoen dollar gekost in één maand en het jaarlijkse AI-budget van Uber in vier maanden uitgeput. De schatting van Meta is gebaseerd op eenvoudige rekenkunde. Volgens de lijst met prijzen van de Claude Opus-API (op het moment dat het nieuws bekend werd) zouden 60,2 biljoen tokens ongeveer 900 miljoen dollar kosten. Een bedrijf van de grootte van Meta bedingt forse kortingen, maar zelfs dan zou de rekening nog in de negen cijfers kunnen lopen.
Uber biedt het duidelijkste beeld van de kosten, omdat het nooit een ranglijst heeft bijgehouden. Het bedrijf gaf ongeveer 5.000 ingenieurs agentische programmeertools zonder kostenmodel. Binnen een maand steeg het aandeel ingenieurs dat als agentische gebruikers werd aangemerkt van 32% naar 84%. Het volledige jaarbudget was binnen vier maanden opgebruikt .
De CTO, Praveen Neppalli Naga, gaf toe dat het bedrijf wat betreft zijn aannames “terug bij af” was. Het bereik van de maandelijkse kosten was van 500 tot 2.000 dollar per engineer, en de oplossing was onverbiddelijk: een maandelijks maximum van 1.500 dollar per programmeertool, per engineer.
Wanneer engineers die vergelijkbaar werk doen zulke uiteenlopende bedragen uitgeven, wijst die variatie erop dat niemand had gedefinieerd wat ‘goed gebruik’ precies inhield. Dus bedacht elke engineer zijn eigen definitie. Andrew Macdonald, COO van Uber, gaf dit punt toe en vertelde aan Fortune dat het “erg moeilijk was om een grens te trekken” tussen AI-ondersteunde code en nuttige functies die daadwerkelijk werden uitgerold.
Uit het AI Impact Report van LeadDev blijkt dat slechts 19% van de technische leidinggevenden tokenmaxxing als effectief beoordelen. 57% van hen zeggen dat het de werkelijke waarde niet goed weergeeft.
Dit is waarom het geld zo snel wegvloeit: een agent die een codewijziging plant, leest de opslagplaats, roept tools aan, voert tests uit en probeert het opnieuw totdat het lukt. Eén enkele lus kan tienduizenden tokens verbruiken, en het lezen van de prompt-cache drijft dat aantal nog verder op.
Financiële teams begrootten AI alsof het een gebruikerslicentie was. Maar in werkelijkheid gedraagt het zich als cloudcomputing. Dezelfde boekhoudkundige kloof ontstaat wanneer teams een AI-stack samenstellen met verschillende leveranciers, zonder dat iemand de eigendom heeft van de rekening. Dit is dezelfde faalmodus als ongecontroleerde toolwildgroei, maar dan een niveau hoger.
Wat is tokenminning?
Tokenminning is de praktijk waarbij het verbruik van AI-tokens tot een minimum wordt beperkt en een laag verbruik als doel wordt gesteld. Zoals we in de inleiding al bespraken, is dit een overcorrectie die eveneens slechte resultaten oplevert. De naam is een afkorting van ‘token minimizing’ en ontstond als tegenhanger van tokenmaxxing. De New York Times berichtte over deze verschuiving bij verschillende bedrijven.
Meta liet zijn medewerkers weten dat het het gebruik van AI zou beperken na een “exponentiële stijging” van de kosten. Uber stelde een maximum in op de maandelijkse uitgaven, Walmart legde limieten op voor het gebruik van tools, en zowel Amazon als Meta haalden hun ranglijsten offline. Binnen enkele weken leerden dezelfde bedrijven die hun grootste AI-gebruikers nog maar kort daarvoor hadden geprezen, iedereen nu om zuinig om te gaan met AI.
Deze correctie herhaalt juist de fout die ze had moeten verhelpen. De wet van Goodhart legt het het beste uit : wanneer een maatstaf een target wordt, is het geen goede maatstaf meer. Dus als je het gebruik van AI-tokens als doel stelt, zullen mensen manieren vinden om op die maatstaf te optimaliseren, zelfs ten koste van de oorspronkelijke bedoeling. De wet van Goodhart waarschuwt tegen tokenmaxxing en tokenminning.
Beloon een team voor het verbranden van tokens, en het zal tokens verbranden die het niet nodig heeft. Beloon een team voor het sparen van tokens, en het zal de AI-run overslaan die een bug zou hebben opgespoord. Of het zal één grondige sessie opsplitsen in drie goedkope sessies, die elk een oppervlakkiger antwoord opleveren. Beide teams halen hun doelstellingen voor tokengebruik, terwijl de kwaliteit van het daadwerkelijke werk achteruitgaat.
Kostenbeheersing op zich is niet de fout. Net als in het voorbeeld van Uber is het maandelijkse maximum van 1.500 dollar een budgettaire beslissing nadat het bedrijf het budget van een heel jaar in vier maanden had opgebruikt. Maar de instelling van een uitgavenlimiet lost alleen een financieel probleem op. Het geeft geen antwoord op de vraag of de tokens iets nuttigs hebben opgeleverd.
De oplossing is om twee soorten nummers van elkaar te scheiden: signalen waar je op let en resultaten waar je naar streeft. Tokengebruik, acceptatiegraad en het aandeel code die door AI is geschreven zijn signalen die laten zien wat er binnen het systeem gebeurt. Ze zijn nuttig bij het onderzoeken van een probleem, maar ze zijn geen goede doelstellingen. Elk van deze nummers kan namelijk sterk veranderen zonder dat de klant enig verschil merkt.
Een organisatie moet in plaats daarvan naar resultaten streven. Deze volgen dezelfde logica als elke goed opgezette reeks KPI’s voor softwareontwikkeling: maak een verbinding tussen een vroeg signaal en het resultaat dat het zou moeten voorspellen. Het conversiepercentage op het dashboard van Shopify is het sjabloon: dezelfde gegevens, maar er is geen ranglijst aan gekoppeld.
Neil Dhar, senior vicepresident bij IBM Consulting, beschreef in een essay over AI-kosten hoe de verwarring zich verspreidt.
#Tokenmaxxing haalt de laatste tijd voortdurend de krantenkoppen. Het streven van organisaties om zo veel mogelijk AI zo snel mogelijk in te zetten, waarbij het gebruik als maatstaf voor waarde werd gebruikt. Nu moeten de rekeningen worden betaald. Aangezien de kosten van AI de opbrengsten overstijgen, is de neiging groot om te bezuinigen. Maar alleen bezuinigen lost het onderliggende ROI-probleem niet op.
#Tokenmaxxing is de laatste tijd volop in het nieuws. Het streven van organisaties om zo veel mogelijk AI zo snel mogelijk in te zetten, waarbij het gebruik werd gezien als een maatstaf voor waarde. Nu moeten de rekeningen worden betaald. Aangezien de kosten van AI de opbrengsten overstijgen, is de neiging groot om te bezuinigen. Maar alleen bezuinigen lost het onderliggende ROI-probleem niet op.
Volgens IBM is de oplossing om het gebruik als een signaal te beschouwen en dit te koppelen aan een resultaat dat niet kan worden vervalst.
Betekent meer tokengebruik ook een hogere productiviteit?
Nee, een hoog tokengebruik betekent niet automatisch een hoge productiviteit. Uit de grootste beschikbare datasets blijkt dat beide factoren onafhankelijk van elkaar evolueren. Onderzoek van het ontwikkelaarsinformatieplatform DX toonde aan dat de acceptatie van AI bijna verzadigd is, terwijl de gemeten productiviteitswinsten stabiel bleven.
Laura Tacho, CTO van DX, deelde de cijfers. Van de ontwikkelaars gebruikt 92,6% nu minstens één keer per maand een AI-codeerassistent, en ongeveer 75% gebruikt er wekelijks een. AI schrijft 26,9% van de productiecode. Toch is de zelfgerapporteerde tijdwinst al meer dan een jaar stabiel gebleven op ongeveer vier uur per week. En de aanvankelijke productiviteitswinst van 10% is nooit verder toegenomen.
Het gebruik bleef stijgen, terwijl de resultaten stabiel bleven. Elke maatstaf die alleen het gebruik bijhoudt, verzorgde de rapportage voor een succes dat nooit heeft plaatsgevonden.
Het DORA-rapport van Google Cloud legt uit waarom dezelfde tools zulke verschillende resultaten opleveren. Daaruit bleek dat de invoering van AI de leveringssnelheid verbeterde, maar de leveringsstabiliteit schaadde. Het rapport beschrijft AI als een versterker: het vergroot de sterke punten van goed geleide organisaties en de zwakke punten van organisaties die het moeilijk hebben.
Uit de eigen gegevens van DX blijkt hoe deze versterker werkt. In een groep van 67.000 ontwikkelaars zagen sommige organisaties het aantal incidenten met klanten verdubbelen, terwijl andere het aantal halveerden, terwijl ze in dezelfde periode dezelfde tools gebruikten. Tacho legt de verantwoordelijkheid daar waar de gegevens naar wijzen:
Dit is eigenlijk een managementprobleem. Door alle hype leek het alsof het simpelweg proberen van AI automatisch vruchten zou afwerpen. Maar tot nu toe zijn de meeste tools gebruikt voor individuele programmeertaaken. Om echte impact te zien, moeten we AI op organisatieniveau inzetten, niet alleen voor afzonderlijke taken.
Dit is eigenlijk een managementprobleem. Door de hype leek het alsof het simpelweg uitproberen van AI automatisch vruchten zou afwerpen. Maar tot nu toe zijn de meeste tools gebruikt voor individuele programmeertaaken. Om echte impact te zien, moeten we AI op organisatieniveau inzetten, niet alleen voor afzonderlijke taken.
Onder het eerste probleem schuilt nog een tweede: mensen schatten de snelheidswinst door AI verkeerd in. Het non-profit onderzoekslaboratorium METR voerde een gerandomiseerde gecontroleerde studie uit. 16 ervaren open-sourceontwikkelaars voltooiden 246 echte problemen in opslagplaatsen die ze gemiddeld vijf jaar hadden onderhouden. Vooraf voorspelden de ontwikkelaars dat AI hen 24% sneller zou maken. Na afloop schatten ze dat het hen ongeveer 20% sneller had gemaakt. De stopwatch gaf aan dat ze 19% langzamer waren.
Onder het eerste probleem schuilt nog een tweede: mensen schatten de snelheidswinst van AI verkeerd in. Het non-profit onderzoekslaboratorium METR voerde een gerandomiseerde gecontroleerde proefversie uit. 16 ervaren open-sourceontwikkelaars voltooiden 246 echte problemen in opslagplaatsen die ze gemiddeld vijf jaar hadden onderhouden. Vooraf voorspelden de ontwikkelaars dat AI hen 24% sneller zou maken. Na afloop schatten ze dat het hen ongeveer 20% sneller had gemaakt. De stopwatch gaf aan dat ze 19% langzamer waren.
In een vervolguitgave legde het lab uit dat het volgende experiment te maken kreeg met selectie-effecten die het niet kon corrigeren. Het lab zei ook dat ontwikkelaars nu waarschijnlijk daadwerkelijk sneller werken met AI, grotendeels dankzij agentische tools. Wat blijft overeind: zelfgerapporteerde productiviteit is geen vervanging voor gemeten productiviteit, en het verschil tussen beide kan beide kanten opgaan.
Wat moet je meten in plaats van het tokengebruik?
Meet in plaats van het tokengebruik de resultaten op team- en vervolgens op organisatieniveau. Beschouw het tokengebruik als een kostenindicator waarop niemand wordt beoordeeld. Wat telt, zijn de behaalde resultaten.
Een praktische regel om naar te leven: koppel elk signaal dat je publiceert aan een resultaat dat er niet door kan worden opgeblazen. Een team kan tokens vernietigen zonder iets op de markt te brengen. Het kan echter geen daling van het percentage mislukkingen in de verandering simuleren.
| Metriek | Type | Hoe gebruik je het? |
|---|---|---|
| Verbruikte tokens per team | Signaal | Let op kostenpieken en op hol geslagen agent-lussen; rangschik individuen hier nooit op |
| Gebruiksgraad van AI-tools | Signaal | Controleer of de uitrol de doelgroep heeft bereikt, en kijk er daarna niet meer naar |
| Percentage van de door AI geschreven code | Signaal | Achtergrondinformatie voor capaciteitsplanning bij codereviews |
| Wijzig het percentage mislukkingen | Resultaat | Koppel dit aan elke beweerde snelheidswinst; problemen komen hier als eerste aan het licht |
| Per team samengevoegde pull-aanvragen | Resultaat | Alleen op teamniveau, altijd afgewogen tegen een kwaliteitsmaatstaf |
| Score voor ontwikkelaarservaring | Resultaat | Signaleert culturele schade voordat mensen beginnen weg te lopen |
| Percentage van de tijd besteed aan nieuwe mogelijkheden | Resultaat | Koppelt technische inspanningen aan waarde voor het bedrijf |
Deze structuur is afgeleid van meetkaders waarop technische leiders al vertrouwen. DORA omvat leveringssnelheid en stabiliteit, en de bevinding dat AI beide versterkt, is de reden waarom deze combinatie van belang is.
De DX Core 4 meet vier dimensies: snelheid, effectiviteit, kwaliteit en zakelijke impact. Abi Noda en Laura Tacho hebben het ontwikkeld samen met Nicole Forsgren en Margaret-Anne Storey, de onderzoekers achter DORA, SPACE en DevEx. De vier dimensies staan bewust in tegenstelling tot elkaar.
Een team dat het ene verbetert ten koste van het andere, legt de afweging meteen bloot. Geen van beide frameworks bevat een token-statistiek, en geen van beide heeft er een toegevoegd.
Drie regels zorgen ervoor dat de combinatie in de praktijk werkt:
- Aggregeer altijd op teamniveau. Wanneer een signaal aan een individuele naam wordt gekoppeld, wordt het een target en keert het tijdperk van de ranglijsten binnen een Sprint terug. Teams kunnen verschillen in het AI-gebruik van leden opvangen. Individuen zullen het nummer beheren in plaats daarvan
- Toon nooit een signaal zonder het bijbehorende resultaat in dezelfde weergave. Een dashboard dat alleen de tokenuitgaven weergeeft, nodigt uit tot optimalisaties. Door de tokenuitgaven naast het percentage mislukte wijzigingen weer te geven, ontstaat een betere vraag: werken de uitgaven wel?
- Houd signalen volledig buiten prestatiebeoordelingen . Wanneer een gebruikscijfer invloed heeft op beloning of promotie, treedt de wet van Goodhart in werking, ongeacht in welke richting de prikkel wijst. Gebruik gebruiksgegevens voor onderzoek, niet om individuele verdiensten te beoordelen
Hoe stel je een beleid voor AI-gebruik op dat medewerkers niet kunnen manipuleren?
Om een beleid voor AI-gebruik op te stellen dat medewerkers niet kunnen manipuleren, moet u alle zichtbare nummers uit de individuele status verwijderen en vijf beslissingen nemen:
1. Bepaal waarvoor het nummer dient voordat je het verzamelt
Elke statistiek in het beleid moet een schriftelijk doel hebben voordat het eerste dashboard wordt gelanceerd. Het klassement van Shopify werkte in zijn eerste levensfase. Het management gebruikte het om gesprekken aan te knopen met grote besteders over wat ze aan het opbouwen waren. Het nummer was aanleiding voor een onderzoek. Zodra datzelfde nummer een onderzoek afsluit en een conclusie trekt over een persoon in plaats van vragen te stellen over het werk, verandert het in een score. En scores worden beheerd.
Noteer per maatstaf drie zaken:
- De trigger: Welke verandering in tokenuitgaven zet aan tot actie (een piek van 3x ten opzichte van de vorige week of een team dat zijn basisniveau verdubbelt)?
- De actie: Wie vraagt wat, en aan wie (‘de EM vraagt het team wat ze aan het bouwen zijn’, niet ‘het rapport gaat naar de VP’)
- Wat er NIET gebeurt: Waarvoor het nummer nooit zal worden gebruikt, net zo expliciet vermeld
De ‘geen actie’-regel doet het meeste werk, omdat medewerkers het beleid hieraan toetsen. Als het eerlijke antwoord op de vraag ‘wat gebeurt er als de uitgaven plotseling stijgen’ te maken heeft met iemands positie, dan heb je een ranglijst gecreëerd met extra stappen.
2. Stel het budget vast op teamniveau
Een gezamenlijk teambudget vervangt het maximum per persoon, en het verschil zit in het gedrag, niet in de boekhouding. Het maandelijkse verschil van 500 tot 2.000 dollar bij Uber tussen ingenieurs die vergelijkbaar werk doen, laat zien wat er gebeurt zonder een gemeenschappelijk referentiepunt. Iedereen bedenkt zijn eigen definitie van ‘redelijk’. Budgetten werken op dezelfde manier als elke andere poging om versnipperde AI-uitgaven samen te brengen op één verantwoordelijke plek.
Met de ‘envelope’ krijg je drie dingen die een limiet per persoon je niet kan bieden:
- Elasticiteit: Een echt kostbare migratie kan deze maand meer verbruiken, terwijl een routinematige Sprint minder verbruikt
- Psychologische veiligheid: Niemand beschouwt zijn eigen item als een prestatiebeoordeling, omdat er geen item is waarop zijn naam staat
- Zelfcontrole: Oglopende uitgaven worden door het team zelf opgemerkt, aangezien de envelop wordt gedeeld en er zichtbaarheid is voor iedereen die er deel van uitmaakt
Bepaal de grootte van de eerste budgetruimte op basis van waargenomen gegevens. Neem het gemiddelde van de afgelopen drie maanden van het team en voeg daar ruimte toe voor één duur project. Een op giswerk gebaseerde budgetruimte wordt al in week twee overschreden, waardoor iedereen leert dat het beleid slechts voor de vorm is.
3. Maak de dure route zichtbaar
Laat engineers de kosten van elke run zien in plaats van een limiet te stellen aan wat ze mogen uitgeven. Agentic-runs die blijven herhalen bij mislukte tests zijn de plek waar budgetten verdwijnen, waardoor een harde limiet op de voorgrond treedt. Een andere optie is om de kosten per run zichtbaar te maken voor de engineer die deze heeft getriggerd, zonder hierover rapportage te doen.
Een engineer die ziet dat een herhalingslus 40 dollar verspilt, zal die lus repareren. Een engineer die daarentegen bang is voor een rapportage, zal de agent helemaal niet meer gebruiken – ook niet in de gevallen waarin die dure run de juiste keuze was.
De circuitbreakers van Shopify werken als volgt: het systeem detecteert de afwijking en de persoon die het dichtst bij het werk staat, beslist wat er moet gebeuren. Zichtbaarheid verandert gedrag sneller dan een limiet dat doet, en het zorgt ervoor dat de dure maar juiste werkwijze beschikbaar blijft wanneer het werk de kosten rechtvaardigt.
4. Maak een onderscheid tussen het doel voor AI-implementatie en de prestatiebeoordeling
Leg de scheiding schriftelijk vast, want mondelinge toezeggingen overleven een cyclus van ontslagen niet. De Microsoft-ingenieur die aan The Pragmatic Engineer vertelde over het opblazen van hun eigen gebruiksstatistieken, was niet uit op een prijs. Hij wilde een label vermijden in een jaar waarin ontslagen in het teken stonden van AI.
Als mensen denken dat gebruiksgegevens worden meegenomen in een kalibratievergadering, zullen ze die gegevens beheren, ongeacht wat iemand hardop zegt.
De beleidstekst hoeft uit precies twee regels te bestaan:
- Of gebruiksgegevens kunnen worden meegenomen in prestatiegesprekken (ja of nee, niet ‘contextgebonden’)
- Waar de gegevens ook naartoe gaan, zodat niemand de stilte opvult met een nog slechtere veronderstelling
Houd vervolgens rekening met beide. De eerste engineer die gebruiksgegevens in een evaluatie ziet opduiken, zal dit aan iedereen doorgeven, waardoor de metric overbodig blijkt te zijn.
5. Evalueer de koppeling elk kwartaal
Vraag jezelf elk kwartaal af of elke diagnose nog steeds het resultaat verklaart waarmee deze is gekoppeld. Modelprijzen, cachinggedrag en agentarchitectuur veranderen allemaal sneller dan een jaarlijkse planningscyclus.
De manier waarop teams AI toepassen bij planning en rapportage blijft veranderen. Een aantal tokens dat in januari nog iets betekende, heeft in juni, na twee prijsverlagingen en een upgrade van de agent, een heel andere betekenis gekregen.
De evaluatie levert eerlijke resultaten per statistiek op: de statistiek voorspelt nog steeds het verwachte resultaat, moet worden bijgesteld aan de hand van nieuwe prijzen, of verklaart niets meer en wordt zonder veel ophef buiten gebruik gesteld. Teams verzetten zich het meest tegen het buiten gebruik stellen van statistieken. Het is echter een belangrijke stap, want een statistiek die zijn betekenis heeft verloren, is precies het soort nummer waarop het tijdperk van de ranglijsten was gebaseerd.
Veelgemaakte fouten die teams maken bij het meten van AI-acceptatie
De vier meest voorkomende fouten zijn: acceptatie als einddoel beschouwen, vertrouwen op zelfgerapporteerde tijdwinst, het publiceren van individuele ranglijsten en het meten van snelheid zonder de stabiliteit te meten. Je kunt ze allemaal opsporen voordat ze je duur komen te staan.
1. Adoptie beschouwen als de eindstreep
Het implementatiedashboard geeft 90% aan, het management verklaart het AI-initiatief voltooid en niemand vraagt zich af wat er stroomafwaarts is veranderd. De gegevens van DX legden deze valkuil op grote schaal bloot: 92,6% acceptatiegraad terwijl de productiviteit stabiel bleef op 10%. Acceptatie bevestigt alleen dat de tools de mensen hebben bereikt. Het zegt niets over wat de tools hebben veranderd.
De oplossing: Schrap de acceptatiegrafiek zodra de uitrol is voltooid en vervang deze door een combinatie van signalen en resultaten.
2. Vertrouwen op zelfgerapporteerde tijdwinst
Uit een enquête blijkt dat het team vijf uur per week bespaart, maar de cyclustijd is al twee kwartalen niet veranderd. De proefversie van METR laat zien waarom deze twee cijfers niet met elkaar overeenkomen: ontwikkelaars die aantoonbaar langzamer werkten met AI, schatten achteraf toch een versnelling van 20%. Wat mensen geloven en wat de klok registreert, zijn twee verschillende metingen.
De oplossing: Behoud de enquête voor de ervaring van ontwikkelaars, waar perceptie van belang is. Gebruik systeemgegevens voor alle uitspraken over tijd.
3. Een individueel klassement publiceren, gewoon voor de lol
Iemand bouwt het in een middagje op een interne wiki, geeft het speelse titels, en het team heeft er ongeveer drie weken lang oprecht plezier aan. Daarna neemt de drang naar winst het over. Meta’s Claudeonomics en Amazon’s Kirorank begonnen beide als grassroots-plezier. Beide bedrijven hebben ze stopgezet zodra het spel het enthousiasme overtrof.
De oplossing: Voeg de gegevens samen op teamniveau, of verstuur ze helemaal niet.
4. Snelheid meten zonder de stabiliteit te meten
De doorvoer stijgt, iedereen juicht, en het aantal incidenten klimt in het dashboard van een ander team. Het DORA-rapport bracht precies deze tweedeling aan het licht: de snelheid neemt toe, terwijl de stabiliteit afneemt. Door de twee nummers op aparte dashboards weer te geven, blijft het probleem onzichtbaar.
De oplossing: Zet het percentage mislukte wijzigingen op hetzelfde scherm als de snelheidsstatistieken, en niet in een aparte betrouwbaarheidsanalyse waar niemand naar terugkijkt.
Hoe je de impact van AI in ClickUp kunt bijhouden

Om de impact van AI in ClickUp bij te houden, meet je de resultaten naast het werk zelf: de taken, sprints en deliverables die de AI had moeten versnellen. De meeste token-dashboards bevinden zich in een providerconsole, ver verwijderd van het werk dat ze beschrijven. Door de resultaatstatistieken naar de werkruimte te verplaatsen, wordt die kloof gedicht.
De koppeling tussen signaal en resultaat uit eerdere kaarten is direct van toepassing op het platform:
- Bekijk snelheid en kwaliteit op één scherm. Stel in ClickUp Dashboards een weergave samen met kaarten voor sprintsnelheid, cyclustijd en cumulatieve doorstroom, naast een lijst met taken die zijn gefilterd op herwerk en bugfixes. Een geclaimde snelheidswinst en de daarmee gepaard gaande kwaliteitskosten hoeven niet langer in afzonderlijke rapporten te worden weergegeven – dit is in de praktijk de regel voor het koppelen van deze gegevens.
- Vergelijk AI-ondersteund werk met de rest. Voeg via aangepaste velden een keuzemenu toe waarmee taken als AI-ondersteund kunnen worden gemarkeerd. Vergelijk vervolgens de cyclustijd en het percentage herwerk tussen de twee groepen. Dit levert bewijs op dat geen enkel factureringssysteem kan leveren, omdat het systeem alleen weet wat er is uitgegeven, niet wat er is geleverd
- Toets beweringen over tijdwinst aan de hand van geregistreerde tijden. Vergelijk tijdsinschattingen met de daadwerkelijk geregistreerde tijd per taak en breng beide samen in een Urenregistratie-kaart of tijdrapportage-kaart op hetzelfde dashboard. Als AI een werkstroom daadwerkelijk versnelt, daalt de geregistreerde tijd voor vergelijkbare taken. Mocht het alleen maar sneller aanvoelen, dan bevestigen de cijfers dat ook.
- Krijg antwoorden uit het werk zelf in plaats van rapporten op te stellen. Stel ClickUp Brain, een contextuele AI voor de werkruimte, een vraag zoals ‘welke projecten zijn achterop geraakt nadat we het beoordelingsproces hebben aangepast’. Het geeft antwoord op basis van live taken, dashboards, documenten, chats en gekoppelde apps, in plaats van een presentatie uit het kwartaalverslag.
- Houd de agent en het resultaat in één systeem. Teams die AI-agenten inzetten voor routinematige operationele taken kunnen Super Agents binnen de werkruimte laten draaien. De door AI ondersteunde teamgenoten werken statussen bij, plaatsen follow-ups en schrijven voortgangsrapporten volgens een schema of op verzoek. Het werk van de agent en de registratie of het heeft geholpen, bevinden zich op dezelfde plek, waardoor een afstemmingsstap overbodig wordt.
Als je team agents gaat implementeren, laat dit zien hoe je er een kunt bouwen met een gedefinieerde taak:
Houd het aantal tokens bij zonder mensen daarvoor te beoordelen
Het hele verhaal komt neer op één regel: gebruik tokengegevens om vragen te stellen, nooit om mensen te beoordelen. Shopify vroeg: ‘Wat bouwen onze grootste spenders?’ en ontdekte op hol geslagen agents en infrastructuurfouten. Meta en Amazon vroegen: ‘Wie gebruikt AI het meest?’ en kregen nep-taken, verspilden miljoenen en eindigden met nutteloze ranglijsten.
Doe dit kwartaal dus drie dingen. Verplaats het bijhouden van tokens naar het teamniveau en verwijder alles waar de naam van een individu op staat. Leg in het beleid vast dat gebruiksgegevens nooit een rol spelen bij een functioneringsgesprek. En zet één kwaliteitsmaatstaf (het verlagen van het uitvalpercentage is het eenvoudigst) op hetzelfde scherm als alle snelheidsmaatstaven die je rapporteert.
Als je dat scherm naast je eigenlijke werk wilt hebben in plaats van in een aparte tool voor rapportage, begin dan gratis met ClickUp en bouw het dashboard voordat je het nodig hebt.
Veelgestelde vragen over Tokenmaxxing (FAQ's)
Wat is de 30%-regel voor tokenmaxxing?
Er bestaat geen officiële ‘30%-regel’ die specifiek betrekking heeft op tokenmaxxing. De term is meestal een afkorting voor twee afzonderlijke bevindingen die mensen door elkaar halen: dat AI de gemeten technische productiviteit doorgaans met ongeveer 10% verhoogt , niet met 30%, en dat ontwikkelaars stelselmatig winststijgingen van zo’n 20–30% voorspellen die niet worden gerealiseerd. Beschouw elk vast percentage als een aanwijzing om nader te onderzoeken, nooit als een target dat gehaald moet worden.
Een miljoen tokens komt overeen met ongeveer 750.000 woorden Engelse tekst, aangezien een token gemiddeld ongeveer driekwart van een woord beslaat. De kosten hangen volledig af van het model en de verhouding tussen input en output. Tegen de tarieven van de geavanceerde modellen van 2026 variëren ze van enkele dollars tot enkele tientallen dollars per miljoen. Agentic-sessies verbruiken snel miljoenen tokens omdat bij elke lus de context opnieuw wordt gelezen en het lezen van de prompt-cache bijdraagt aan het totaal.
"Tokenmaxxing" is een samentrekking van "token" en het internetsuffix "-maxxing", wat betekent dat een eigenschap tot het uiterste wordt gemaximaliseerd. Het begrip verspreidde zich begin 2026 onder technici nadat interne token-ranglijsten bij Meta en Amazon naar de pers waren gelekt. Business Insider noemde het in april 2026 “het nieuwe AI-debat in Silicon Valley ”. Openbare ranglijsten zoals Viberank en tokenmaxxing.sh namen het label vervolgens over en rangschikten individuele ontwikkelaars wereldwijd op basis van hun API-verbruik.
Grotendeels wel. Fortune verklaarde in mei 2026 dat tokenmaxxing voorbij was, nadat Meta, Amazon, Microsoft en Uber hun token-ranglijsten hadden teruggeschroefd of helemaal hadden geschrapt. Uit het AI Impact Report van LeadDev bleek dat slechts 19% van de respondenten tokenmaxxing als effectief beoordelen voor het meten van AI-waarde, en 57% zeggen dat het ronduit faalt. Door hobbyisten bijgehouden openbare ranglijsten bestaan nog steeds, maar dan als een spel, niet als een managementpraktijk.
Er bestaat geen vastgestelde benchmark. Bij de uitrol door Uber bereikte de maandelijkse kostenbereik $500 tot $2.000 per engineer, voordat het bedrijf de uitgaven beperkte tot $1.500 per tool. Jensen Huang, CEO van Nvidia, heeft betoogd dat een engineer die $500.000 verdient, jaarlijks $250.000 aan tokens zou moeten verbruiken, maar dat is hoogstwaarschijnlijk een provocatie, geen norm. Uit onderzoek blijkt dat er grote verschillen bestaan tussen vergelijkbare werkzaamheden, wat betekent dat nog niemand heeft gedefinieerd wat ‘goed gebruik’ inhoudt.
Vibe-coding is een manier van werken: de implementatie delegeren aan een AI-agent en sturen op basis van het resultaat. Tokenmaxxing is een manier van meten: de tokens die je verbruikt, beschouwen als bewijs van productiviteit. Je kunt efficiënt of verspillend aan vibe-coding doen; tokenmaxxing beloont de verspillende versie omdat het alleen het verbruik meet. Bedrijven die een limiet op tokens instelden om tokenmaxxing tegen te gaan, straften daarbij vaak legitiem, agentisch werk af.

