Wat er is gebeurd
TechCrunch legde een ongemakkelijk patroon bloot dat zich nu verspreidt onder teams die zwaar leunen op AI-codingagents: het tokenbudget begint op een statusmetric te lijken. Het artikel noemt dat 'tokenmaxxing', het idee dat hoe meer modelgebruik je toestaat, hoe productiever je engineers wel moeten zijn. Dat klinkt modern, maar het blijft dezelfde oude managementfout: input meten in plaats van uitkomst.
Wat dit verhaal interessant maakt, is de data erachter. TechCrunch bracht bevindingen samen van analyticsleveranciers die inmiddels duizenden AI-ondersteunde developers zien. Waydev zegt dat klanten initiële acceptatiecijfers van 80 tot 90 procent zien voor AI-code, maar dat het echte cijfer zakt naar ongeveer 10 tot 30 procent zodra diezelfde code in de weken na een merge wordt herzien. GitClear meldde 9,4 keer hogere code churn bij vaste AI-gebruikers, Faros AI zag churn met 861 procent stijgen bij hoge adoptie, en Jellyfish concludeerde dat de grootste tokenbudgetten ongeveer 2 keer zoveel pull requests opleverden tegen 10 keer de tokenkosten.
De directe context is softwareontwikkeling, maar het onderliggende signaal is breder dan code. Zodra een organisatie rauwe modelconsumptie gaat vieren, wordt het makkelijk om meer output te verwarren met meer waarde. Bedrijven schalen dan inferentiekosten, contextvensters en reviewdruk tegelijk op, terwijl ze zichzelf vertellen dat ze efficiënter worden.
Waarom dit ertoe doet
Dit is relevant omdat veel enterprise AI-projecten buiten softwareteams tegen precies dezelfde muur aanlopen. In documentintensieve processen kan een agent meer e-mails opstellen, meer bestanden classificeren of meer extractiepogingen per uur doen. Maar als het team downstream die tijd meteen weer kwijt is aan hallucinaties corrigeren, output herformatteren of uitzonderingen afhandelen die het model nooit had mogen aanraken, klapt de businesscase snel in. Volume is niet hetzelfde als throughput, en throughput is niet hetzelfde als afgeronde bedrijfswaarde.
Het TechCrunch-verhaal is dus vooral een waarschuwing over unit economics. De nuttige vraag is niet hoeveel tokens een workflow verbrandt of hoeveel concepten hij produceert. De nuttige vragen zijn: wat kost een afgeronde transactie, hoeveel rework ontstaat er, hoeveel latency voeg je toe, hoeveel approval last ontstaat er en wordt het proces na verloop van tijd beter bestuurbaar? Dat geldt net zo goed voor factuurverwerking, dossierbehandeling, offerte-opmaak of inboxtriage als voor AI-codingtools.
Strategisch is dit ook relevant omdat de markt nog steeds de verkeerde verhalen beloont. Leveranciers praten graag over grotere contextvensters, autonomere agents en hoger gebruik. Kopers zouden meer moeten letten op afgebakende workflows, strakke retrievaldiscipline, deterministische integraties en duidelijke momenten waarop mensen in de lus blijven. Als die ontwerpkeuzes zwak zijn, financieren grotere tokenbudgetten vooral meer chaos.
Laava-perspectief
Bij Laava zien we dit als bevestiging van een principe dat we al in productiewerk toepassen: meet afgeronde procesuitkomsten, niet modelactiviteit. Een nuttig AI-systeem is niet het systeem dat de meeste tekst produceert of de meeste schermen aanraakt. Het is het systeem dat handmatig werk end-to-end wegneemt, terwijl controle, auditability en voorspelbare kosten intact blijven. Dat vraagt meestal om een smalle scope, goede contextengineering, expliciete business rules en een deterministische action-laag rond het model.
Hier wordt ook soevereine, model-agnostische architectuur praktisch in plaats van ideologisch. Als een workflow goed is afgebakend, hebben veel stappen het duurste frontier-model niet nodig. Een kleiner open model, of een goedkoper gehost model, kan extractie, classificatie of een eerste concept vaak prima aan, terwijl een sterker model alleen wordt ingezet voor de echt complexe gevallen. Zo houd je keuzevrijheid en kostencontrole zonder kwaliteit op te offeren.
De sceptische lezing blijft belangrijk. Tokenmaxxing is vaak een symptoom van zwak procesontwerp eerder in de keten. Teams gooien grotere prompts en ruimere budgetten tegen een workflow aan omdat documenten rommelig zijn, metadata inconsistent is, systeemgrenzen onduidelijk zijn of approvallogica nooit goed in kaart is gebracht. In zulke situaties lost meer uitgeven aan de reasoning-laag de architectuur niet op. Het verbergt het echte probleem alleen nog een paar kwartalen.
Wat je nu kunt doen
Als dit herkenbaar voelt, begin dan met één workflow en meet die goed door. Volg de kosten per afgeronde uitkomst, hoe vaak mensen modeloutput herschrijven, hoeveel uitzonderingen buiten het happy path vallen en welke stappen echt een frontier-model nodig hebben. Zet dat af tegen de huidige handmatige baseline. Als je niet op één pagina kunt uitleggen waar de economische winst vandaan komt, is de workflow nog niet klaar om op te schalen.
Herontwerp daarna eerst op discipline en pas daarna op autonomie. Houd context lean, scheid extractie van reasoning en actie, dwing approval gates af waar het bedrijfsrisico stijgt en zorg dat een modelswap vanaf dag één mogelijk is. De teams die winnen met enterprise AI zijn niet de teams die de meeste tokens verstoken. Het zijn de teams die AI veranderen in een bestuurbaar onderdeel van een echt bedrijfsproces.