After Tokenmaxing, Who Is Thinking for Whom?

They paint the Qinchuan landscape from afar — how many have truly stood in Chang’an? — Yuan Haowen, Thirty Poems on Poetry, No. 11

Recently I did something at the company that won me no friends: I put usage limits on some of our most expensive AI models.

Since January, our AWS Bedrock bill has climbed relentlessly — every month it either doubles or rises by more than 50%. There are more employees burning several thousand dollars a month than you could fit on a bus. Even a product manager demoing a tool had Fable read the documentation and run the install. Looking at last month’s AI spend, I — someone who normally pays no attention to finance — felt my blood pressure spike.

In the first week after the quota system went live, there was wailing and gnashing of teeth. Plenty of people burned through an entire month’s budget in a day or two. We had capped only the most expensive models — Fable, Opus, Astra, Sol — leaving everything else uncapped, and still the complaints rolled in about Sonnet and Luna not being up to the job.

One DM stuck with me. The tone was cordial; the message was unmistakable: by forcing me onto Sonnet, you’ve compromised our marketing workflow, and when the KPI isn’t met, who’s accountable?

My first reaction was: what a time to be alive — were you unable to work six months ago?

Once the irritation passed, what I really wanted to understand was this: why does a tool that barely existed a few months ago become a precondition for the work so quickly? People are getting more done with AI — is their understanding of that work growing along with it?

From Personal Plans to Enterprise Procurement

I’ve always thought that Claude Code and Codex capturing programmers’ minds with $200-a-month personal plans was a masterstroke of commercial strategy.

For heavy users, such a plan yields $3,000–5,000 worth of usage at API list prices. That doesn’t mean the vendor actually bears costs of that magnitude, nor that the quota is unlimited; what it changes is how the user feels when making decisions: as long as you’re inside the quota, trying one more time costs nothing extra.

Exploration therefore carries almost no psychological friction. Reading a repo, writing scripts, installing tools, tweaking configs — all of it can be handed to the strongest model first. If it doesn’t work, try again; run several agents in parallel, why not. That freedom has real value: plenty of things people used to skip because they were too much hassle are now within reach.

Use it long enough and you grow numb to the price. We quickly learn how to make the strongest model work for us, without necessarily thinking hard about which tasks deserve it.

Back at the company, the experience can feel very similar while the payment model is entirely different. In our case, nearly all coding-agent usage runs through Bedrock on a pay-as-you-go basis. Employees still spend as freely as they would on a personal plan, but the company pays for every call.

They say the wool comes from the sheep; here, the enterprise is the pig. The vendors may not have designed this path deliberately from the start, but judging by our usage, personal plans have absolutely shaped enterprise purchasing.

The brilliant part is that the vendor gets into the enterprise’s procurement decision without having to convince the procurement department first. Developers have already done the trial, the training, and the workflow rework on its behalf. By the time the company sits down to seriously reckon with costs, the question has shifted from “should we buy this?” to “why are you taking it away from us?”

Nor is the difficulty of switching models mainly about data migration. People write prompts, decompose tasks, and build pipelines around the model they know. Many conditions that ought to have been spelled out never got written down, because the model usually guessed them right. Switch models and those omitted conditions surface; the old pipeline stops feeling natural. And once the team has committed to delivery dates on the strength of that pipeline, adjusting gets even harder.

Why Everyone Defaults to the Strongest Model

Blaming runaway spend entirely on employees being profligate is only half the story.

Suppose I own a project. The company evaluates me on ship dates but doesn’t put model costs inside my decision. Choosing the strongest model is then perfectly rational: even if it only marginally raises the success rate, it’s worth trying. The cost lands on a shared budget, while a delay lands directly on my performance review. Switching to a cheaper model means saving the company money; failing means it becomes my problem.

That DM about “who’s accountable for the KPI” did more than annoy me — it exposed the incentive structure. Business owners worry about delivery slipping; infrastructure owners worry about costs climbing. Each side feels the other doesn’t understand their situation. As long as nobody is weighing benefit and cost together, it’s very hard to have a real conversation about how much to spend.

Which also explains why “everyone should just be more mindful” doesn’t work. People willing to try cheaper models have to spend time reworking pipelines and may have to explain why things got slower; people who keep using the strongest model ship on time. Unless the evaluation criteria change, frugality will never be anyone’s top priority.

That said, rising spend by itself still doesn’t prove waste. The company may also be doing more of the things it previously couldn’t afford. To distinguish the two, you need to know what the extra calls produced: more acceptable deliverables, shorter waits, or a lot of waste on trivial problems. Without that information, lifting quotas and blanket caps alike are just guesses.

The Agent Is Busy — What Is the Employee Doing?

Agents let a person mobilize enormous resources with a sliver of attention. In the past, if you spent an hour digging into a problem yourself and got nowhere, you’d at least stop and wonder whether you were looking in the wrong direction. Now, a vague task can have an agent reading files, trying approaches, and retrying for half a day. The human spends a few seconds issuing the instruction, and the system starts working continuously.

Being able to hand off execution is fundamentally a good thing. But those laborious steps of the past sometimes forced people to think: do I have enough information? Is this the right direction? Is there a more direct route? Once the agent makes execution easy, people can skip those questions, and in the short term it’s hard to see what’s wrong.

Imagine someone fires off “optimize this system for me.” The agent quickly lists several directions — performance, architecture, testing, observability — analyzes each, and starts changing code. The whole process is impeccably organized. But what the system’s actual problem is may never have been asked, by anyone, from beginning to end. A vague hunch has become a project in flight.

Strong models make this step especially easy to skip. They’re excellent at filling a vague request into a complete plan, with rationale, steps, and a discussion of risks. Read it through and it flows; you conclude you’d thought it through yourself. But between understanding an explanation and justifiably accepting it lies the checking of facts and premises.

What worries me is people gradually getting used to choosing only among the options the model offers. It says performance should be optimized, and people start comparing caching strategies; it says refactoring is needed, and people start picking architectures. What premises the plan rests on, and whether those premises hold, never comes up again.

Sometimes asking a second model doesn’t help either. If both models accept the same unchecked premise, then however close their answers, the premise is still unproven.

Independent thinking has a very concrete meaning here: I need to know why I accept this recommendation, and what facts would make me change my mind. The reasoning can come from AI, but I need to check it against reality. For instance, where exactly the system is slow, how many users it affects, where the data comes from — if I don’t know any of that, I should investigate first and hold off on letting the agent start a big rewrite.

In unfamiliar territory, of course you can let the model help you understand things; you don’t have to derive every answer yourself before asking. But before turning a recommendation into action, you need to be sure you have good reason to follow it. Otherwise, the agent busies itself for hours and we’re still stuck on the question we never thought through in the first place.

What Does “I Can’t Work Without the Strongest Model” Actually Mean?

In September I ran an experiment on myself: apart from complex system design, which used Opus 5.5/Astra, everything else went to the cheapest model, Luna 6. I completed everything I’d previously done with other models, without hitting any obvious blockers.

Plenty of my everyday tasks genuinely don’t need the most expensive model. But “no blockers” doesn’t prove the total cost was lower, let alone that my colleagues would get the same result. My familiarity with the system and my habits of decomposing tasks all affect whether Luna can get the job done.

If a problem requires a very long chain of reasoning and a weak model simply can’t do it, that’s a capability gap. If what it lacks is context, acceptance criteria, or a tool that lets it observe results, then upgrading the model may paper over the problem without fixing the workflow. And there’s a third case: the output is actually usable, but the user can’t tell, so they reach for the more expensive model that makes them feel safe.

On the surface all three look like “the cheap model isn’t good enough,” yet they call for completely different responses.

For the marketing workflow: content that doesn’t pass might mean the model can’t write, or it might mean the brand requirements were never made explicit. Wrong customer segmentation might be a reasoning error, or the input data might be missing required fields. Unstable formatting might only need structured output plus validation. Only by pinpointing which step failed can you know whether to upgrade the model or fix the process.

Comparing frontier research to marketing doesn’t answer this either. How sophisticated a task sounds doesn’t determine what it should cost. An apparently mundane marketing pipeline that touches a large number of customers may well justify a very expensive model; conversely, a mechanical cleanup job wearing the label of frontier research may not.

Model budget should follow the value of the task, the cost of failure, and the difficulty of verification.

There’s another easily overlooked value in strong models: they let people without the relevant background accomplish things they otherwise couldn’t. You can’t demand that every product manager become an engineer before AI can install a tool. If a little model spend saves a cross-team escalation, that may be an excellent trade.

So whether a model is any good has to be judged in the context of specific work. Saying flatly “we can’t do without it” neither explains the failures nor tells you whether a different approach would work.

Does Anyone Need What We Built?

There’s another situation that’s even easier to overlook: the task was well defined, the agent executed it well, and the thing itself wasn’t worth doing.

This is why I’ve come to value product thinking more and more. An engineer can’t care only about whether a requirement can be implemented; they need to understand who is struggling with what, why existing approaches fall short, and what change they plan to observe after it ships. Even if these questions nominally belong to the PM, whoever picks up the implementation needs the answers. Otherwise, all AI does is speed up execution after the instruction is given.

Take the marketing workflow again. Suppose the team wants a tool that generates and sends marketing content automatically. The agent will happily build around that request: pull in customer data, segment users, generate variants, schedule sends, then add a dashboard. Every feature makes sense, and the demo looks complete.

But the team’s real difficulty might be that sales doesn’t know which customers to contact first, or that content review is too slow, or that no one has found a topic customers will actually respond to. Each of these calls for very different improvements. Building the whole system may never touch the one that matters.

What might be worth doing instead: take a small set of real customer records, hand-pick a group, use AI to help prepare content, and actually run one test. See whether the targeting and the content help at all, then decide which steps deserve automation. If this small step doesn’t help, go back and reexamine your understanding of the customer rather than enriching the dashboard.

This was true before AI. What’s changed is that implementation used to be so laborious that teams were forced by headcount to prioritize and cut. Now a new feature seems to need just one more instruction, and shipping it feels rewarding, so it’s easy to keep piling on.

But users still have to spend time understanding and using these features, the team still has to maintain them, and other work is still waiting. Fast generation doesn’t make any of that downstream burden disappear. A feature may be nearly free to build and still not worth keeping.

For engineers, this means getting involved in judgment earlier. Sometimes the most valuable work is talking to users until something becomes clear, running a small experiment sufficient to test an idea, or pointing out that existing tools already meet the need. That kind of contribution doesn’t show up in the commit log, but it determines whether the development that follows means anything.

When Is It Worth Continuing?

Once you’ve decided something is worth trying, you still have to decide how much to invest and how far to take it. Model unit price is only one factor.

A cheap model that fails repeatedly and needs someone watching it debug can cost more than an expensive model that finishes in one shot. The true cost of a task includes model calls, human intervention, waiting, and the rework and losses caused by errors. Squeeze one of those down and the others may rise more.

So I don’t accept “every task must start with the cheapest model.” For tasks already known to be hard, where failure is expensive, going straight to the strongest model is ordinary engineering judgment; there’s no point walking a known dead end first.

But “human time is expensive, so always use the strongest model” is equally insufficient. What needs comparing is: how much human time does the extra model spend actually save, and how much failure risk does it reduce? For tasks both models can complete, if the expensive one brings no corresponding improvement, no salary level can justify that spend.

Once a task is underway, you also need to adjust based on progress. The agent has already retried ten times — is the eleventh worth it? If it has new logs and has ruled out a hypothesis, continuing may have value; if it is merely repeating the same attempt in different words, more budget will likely only prolong the failure. Money already spent is not a reason to keep calling.

What’s usually missing is a stopping condition. Tell a system to “do the best you can” and it will always find something more to do. When assigning a task, you should say clearly what result counts as acceptable and what circumstances should trigger stopping to consult a human.

Exploration, of course, can’t require proof of success in advance. Unknown problems inherently require trial and error. The sensible approach is to set aside a budget for exploration, agree on checkpoints, and decide whether to continue based on what you learn. One failure that rules out an important path may still be worthwhile; ten polished outputs that reduce no uncertainty may be no progress at all.

What makes me most wary of tokenmaxing is how easily it turns input into achievement. How many agents ran, how many tokens burned — all easy to display; what problem was actually eliminated takes far more effort to explain. Once an organization starts rewarding the former, consumption acquires a reason to grow on its own.

When Implementation Speeds Up, the Team Bottlenecks Elsewhere

Chatting with a colleague a couple of days ago, he said his group could be cut by more than half — keep three or four people plus AI and they could take on anything.

I understand the feeling. Assigning work to people is assignment; assigning it to AI is also assignment. If a colleague takes a task and simply tosses my exact words at an AI, comes back for direction when stuck, and in the end still needs me to review everything item by item, what did that middle layer contribute?

Handing off a task is supposed to mean the person taking it can independently resolve part of the problem. They can use any tool they like, but when it comes back, the facts should be verified, the ambiguities clarified, and only a few trade-offs that genuinely need to be decided together should remain. If every difficulty comes back untouched, or gets handed to the AI to decide, that person’s presence loses its point.

In the past, implementation itself was the barrier: a hard problem, and the excellent person would find a way while the mediocre one stared at it helplessly. Now every employee, with AI’s help, can implement any requirement — but only a few truly understand the business constraints, understand the architecture, can judge which direction is sensible, can guide the AI to write higher-quality code, and can actually get the AI’s output into production. The bottleneck has moved from production to acceptance. Making generation faster only piles up more things waiting for review.

Worse, review often doesn’t count against the producer’s cost. Someone who submits ten PRs a day looks more productive than someone who submits two — but if the former requires a senior colleague to rebuild context on each one, spot the false premises, and clean up the downstream rework, he has simply shifted the work onto someone else.

One person’s output can rise while the whole team’s effective output falls.

That’s why I’ve grown uneasy about some notions of “high performance.” The easier generation becomes, the more measuring contribution by volume of deliverables distorts. Conversely, someone who kills a wrong direction, leaving almost no code behind, may save the whole team weeks of work.

I call the people who deliver a lot while leaving all the core judgment to others — or to the AI — the new breed of “coasting.” And yet if a company proves the success of its AI transformation with PR counts and task counts, it is encouraging exactly that behavior. We keep telling managers that PR counts, review counts, experiment counts, and success counts must all be read in the context of the actual work, and that no single metric should be used to evaluate an employee. But there’s no denying that these numbers still shape people’s choices.

Whether a plan is sound, whether delivery is reliable, whether rework has gone down, whether the next person can understand it — these say far more about a person’s contribution, and are precisely the things that don’t quantify well. Managers need to spend time looking at the actual work and understanding where collaboration hurts. Metrics can offer clues, but they can’t replace that judgment.

The Work Is Done — What Did You Learn?

Last year’s Reshaping the Programmer’s Role already discussed judgment, clarification, and accountability. But these abilities don’t grow just because someone is told to “think more.” They require repeated practice in real work, and they require knowing where your own thinking went wrong.

In the past, writing code came bundled with a great deal of feedback. You assumed the API worked a certain way, and running it told you otherwise; you assumed a boundary case would never occur, and an outage told you it would. Implementation was slow, but it forced you to keep revising your model of the system.

Once AI takes care of the details, learning no longer accompanies delivery automatically. The task is done, and the user may only know “this phrasing gets me a result,” without ever wondering why it succeeded or what they learned. Over time, they ship a great deal while their understanding of the work barely grows.

So retrospectives need to be more deliberate. Tossing the chat log at a model and generating a “lessons learned” write-up, then skimming it, is not the same as learning. Models are very good at explaining what already happened in a way that sounds reasonable, but what we need to check is why we thought what we thought at the time, and what the later evidence actually showed.

One method of mine: before a key decision, write down what you expect. No formal document needed — a few sentences will do. If I suspect an API timeout is caused by a slow database query, I note which requests should be affected and what should appear in the logs. With that record, after the task ends I can compare what I originally thought with what actually happened, instead of reading the result and concluding “that’s what I figured all along.”

Suppose the agent eventually relieves the timeout by adjusting the connection pool. The retrospective can’t stop at “problem solved.” You need to confirm whether the original diagnosis held, why the pool was exhausted, and whether this change eliminated the cause or merely masked the symptom. Otherwise, the next time load shifts, you’ll be guessing from scratch again.

Success deserves a retrospective too. Some approaches work because the judgment was right; others merely happened not to run into bad conditions. If the tests never covered a particular boundary and nothing has gone wrong in production yet, that doesn’t mean the boundary is safe. Telling these apart is how you know which lessons are reusable and which are still unverified guesses.

AI can absolutely take part in this. Asking it to find evidence in the logs that contradicts the original judgment, to construct inputs that would break the approach, or to analyze an alternative explanation is far more useful than having it write another “three takeaways from this project.” But the evidence still has to come from the real system and real users. If the model generates both the implementation and the tests from the same understanding, their agreement doesn’t rule out that the requirement was misunderstood from the start.

The marketing workflow is the same. How much content was generated and how many emails were sent automatically only shows the pipeline is running. What’s actually worth revisiting: which customers did we think would respond, who actually did, and did the difference come from targeting, content, or timing? A small experiment that changes your understanding of customers lets the next attempt be better grounded.

Not every small thing needs a formal retrospective. What deserves the time: results that surprised you, failures that keep recurring, and decisions where being wrong would have obvious consequences. Write the corrected understanding into tests, runbooks, or the next experiment — only then does learning actually affect the work that follows.

If an employee uses AI longer and grows more dependent on it for judgment, to the point of being unable to say where a problem lies once the model changes, the company genuinely needs to ask: what is this person still providing the team, and what is the point of keeping the role? Simply relaying a model’s output is hard to defend as a sufficient reason for a job.

Pulling the Switch Is Only the Beginning

Back to the quotas. They can hold spend in check for now, but they won’t by themselves improve how people use AI.

Give everyone the same allowance and stop them when it runs out, and it looks fair while ignoring differences between tasks: whoever owns the hardest project may be the first to get stuck. Others will neither change their approach nor seriously analyze why the model failed, and will retreat behind “I ran out of quota” whenever things get hard. If limiting spend only teaches people to avoid overspending — or to avoid hard problems — it has failed at its purpose. Several things still need doing.

First, make consumption visible to users and owners. How much a task roughly cost, which steps consumed it, whether a long-running job produced new information — all of this should be queryable. Different models cost different amounts; actual spend is a better reference than raw token counts. Everyday small usage shouldn’t require layers of approval, or the model costs saved will simply turn into more coordination costs.

Second, leave clear channels for expensive tasks and open-ended exploration. Important projects can have their own budgets, and reasonable failures can be tolerated. When things exceed expectations, the conversation should be about what we now know and how much the next stage is worth. If a business owner judges the expensive model indispensable, they should be able to put expected benefit and cost on the table together; the infrastructure team should show the basis for the limit and accept that the limit may need adjusting.

Third, keep what has already been figured out. A complex task is worth exploring with the strongest model the first time, but once it succeeds, the necessary context, verification method, scripts, and handoff notes should be written down. That way the next colleague can continue, rather than having the strongest model re-investigate everything each time the person changes.

Finally, managers need to adjust their own expectations. Demanding that employees fully embrace AI and dramatically raise output while treating AI spend as an expense that ideally wouldn’t exist — these two cannot hold together for long. Cost constraints and delivery targets must be discussed together. The DM that annoyed me needs the sender to produce evidence that the workflow was affected, and it needs us to be willing to revise budgets or targets in light of that evidence.

I’m still happy to pay a lot for strong models. If it solves an important problem, the investment is warranted. But if everyone merely expects the model to do everything while their own understanding of the problem doesn’t deepen and their way of working doesn’t improve, then adding more budget shouldn’t be the first thought.

Of the time AI saves, I hope at least some goes to talking to users, checking our assumptions, and understanding one unexpected thing. The work can be handed to agents — but when it’s done, we ought to understand a little more than we did at the start.