There’s No Tokenmaxxing in Finance
At Gartner’s annual finance conference, as CFO Dive reported, Uber’s Director of Finance, Tiho Nedkov, stood up in front of the room and said: “There’s no sort of token-maxxing in finance… But you do have to be mindful of that. You have to make sure limits are in place.”
Tokenmaxxing, if the word’s new to you, is what happens when using an AI tool a lot quietly becomes proof, on its own, that you’re using it well. A token is just the unit these tools meter and bill by, roughly a chunk of a word. Burn enough tokens and it looks like progress, whether or not anything useful actually got done.
Nedkov wouldn’t deny something like that from a stage unless it was already close enough to worry about. He did it anyway, on the record, in front of a room of his peers.
How the Leaderboard Forms
Most new tools brought into an organisation don’t take. They die on the vine unless someone inside champions them hard enough to drag the rest of the team along, and that’s real, slow work. AI skipped all of that. The on-ramp needed no training and no rollout, so people just opened it and started typing. That’s genuinely different from how tools normally spread, and it explains why usage exploded the way it did.
Easy access was never the same thing as using something well, though. Section AI’s own Proficiency Report found that while most knowledge workers now use AI every week, only 5.5% meet a real proficiency bar, and 73.5% are still stuck on basic, one-off tasks. Nearly everyone got the tool. Almost nobody got told what success would look like.
That mismatch is really the whole problem, and it was never about the tool itself. It’s about the wrong thing getting measured. When nobody names the outcome, the only thing left to measure is whether people are using the tool, visibly, a lot. Meta’s own internal usage dashboard, reported by The Information and picked apart in detail by The Pragmatic Engineer, is the sharpest example on record: 85,000 employees, gamified titles like “Session Immortal,” tens of trillions of tokens burned in a month, a leaderboard pulled once the backlash landed. Engineering hit this first and loudest, since a usage number was the easiest thing to point at there, but the same wrong-metric habit is available to any function once nobody’s actually named the outcome.
What AI Actually Can’t Tell You
Fixing what gets measured is only half of it, though. The other half is knowing what the tool can actually be trusted with on its own, and that’s where people are finding out, directly, what these tools genuinely can’t do.
Andrej Karpathy told a story at Sequoia’s AI Ascent event, written up afterwards on his own blog, that’s stuck with me. He wanted to go to a car wash, fifty metres from his house, so he asked the model: should he drive or walk? A state-of-the-art model, he said, will often tell you to walk, because it’s close. The same model can refactor a hundred-thousand-line codebase or spot a genuine security flaw, and it still can’t reliably tell you whether walking or driving is the right call for the question actually being asked.
It’s not a criticism of the tool, just a clear dividing line: these models are genuinely excellent at things you can check, code that runs, a proof that holds, and much weaker at ordinary judgement calls, which nobody can check in the same way. The right response isn’t to hand the tool less work. It’s to keep the framing and the judgement for yourself, since that’s the half it genuinely can’t do, and let the tool handle the half it’s actually built for.
That’s the piece I wrote about in Reimagine to Deploy: upstream is the thinking that decides what’s worth doing, downstream is the actual building and delivery of it. Downstream got fast and cheap. That never removed the upstream work; skipping it just shows up faster now.
Where the Value Actually Sits
So what does the right objective actually look like? Not value per token; nobody can track that number in any way that means anything. It’s the value of the outcome you’re actually trying to reach, judged workflow by workflow, and these workflows often cut across functions rather than sitting inside one.
Getting that right isn’t a box you tick once, upstream, before anyone touches the tool. Usage starts the moment anyone opens the tool, upstream or downstream, so the thinking has to be right from the first prompt, not bolted on after the fact.
Praveen Neppalli Naga, Uber’s CTO, put a real number on what happens when nobody does that thinking. Uber burned through its entire year’s AI coding budget in the first four months, as MLQ News reported, driven by rapid adoption of tools like Claude Code across engineering. That’s not a result, it’s a warning sign, and it’s exactly what you’d expect once tokenmaxxing, rather than the outcome, becomes the thing being chased. Nobody sets out to burn a year’s budget in four months. It happens by default when nothing else was ever named as the target.
Jake Van Clief gets closest to what the actual target should be, and he’s worth crediting properly. In a video on his channel, he lays out a framework he uses in his own workshops and his own company: build a service or a workflow, and roughly 60% of it is ordinary code, plumbing and file handling and the rest. Another 30% is rule-based logic, routing, security. Only 10% is actually AI calls. “The AI is a component, not the whole thing,” as he puts it. “The value is often in everything around the AI, not the AI itself.”
Here’s the layer I’d add on top of that. That 10% isn’t staying a small, contained slice of effort; it’s increasingly the layer directing execution inside the other 90%, writing a good share of the ordinary code itself and taking on real work inside the routing and the rules too. What’s left for a person is the discovery: deciding the rules and the routing that shape the system. That’s not a claim that discovery takes longer than the code it’s replacing; it’s that time spent on discovery, rather than on writing the code by hand, is what actually produces the better outcome. It’s also the counterintuitive part worth sitting with: get that upstream thinking right and the downstream work often costs fewer tokens too, not more. Spending less while still landing the outcome beats tokenmaxxing every time; it’s proof the problem was framed correctly, not a consolation prize for using the tool less impressively. Score people on how visibly they used the AI, though, and you’re scoring the smallest, least determinative part of the whole thing.
There’s a nice footnote to this. Van Clief published research on using folder structure as agent architecture a few months before Google put out something covering strikingly similar ground of its own, built on the same basic idea: plain markdown files and folders as the way to organise what an AI agent needs to know. Van Clief’s own read on it, in a short video responding to Google’s post, wasn’t that anyone had copied anyone. It’s old, Unix-era methodology arriving at the same conclusion twice because it’s the right one. None of this is as new as the hype suggests, and the value was never in the newness. It’s always been in the agency a person brings to the tool, and the direction they point it in.
So What Are You Aiming At?
None of this is fully worked out on my end either, if I’m honest. I’m happy admitting that, though; I feel like I’m building and iterating on steadier ground now than I was before any of this started. If you’re trying to close this gap in your own organisation, Barry O’Reilly’s book, Artificial Organizations, is a good place to start; it’s squarely about this problem.
But here’s the actual question. When you handed your team the new tool, what did you tell them it was for? And how would you know, right now, whether it’s working?
