The Engineer Who Could Not Work Without More Tokens

Go back to that request and start asking the engineer ordinary questions. What did the agent build? Why is the system structured this way? Where does this responsibility live? What would you change to add the next feature?

The answers reveal a different problem. The engineer has been using the coding agent to build software they do not really understand. They cannot find their way around the codebase with any confidence, and they do not know why most of the implementation decisions were made. Every new change requires another long conversation with the agent, because the agent has effectively become the only participant capable of reasoning about what the previous session produced.

Those tokens did not buy productivity. They bought dependency, which is a much more expensive problem than the token bill, partly because it never appears on the bill at all.

What Are You Buying With a Token?

A token is not inherently productive. It is computational capacity, and what matters is what you point that capacity at.

You can spend tokens accelerating implementation after you have made the important decisions yourself. You can spend them exploring several approaches so you understand the tradeoffs before you commit, or chasing down why something is failing so you actually learn the cause. You can automate repeatable work, and you can delegate work according to rules you already understand. Or you can spend tokens as a substitute for your own understanding, which in practice sounds a lot like "figure everything out for me."

On an invoice those uses look identical, and they are nowhere near equivalent in value. The first group can build up what an engineer is capable of. The last one slowly wears it away, one conversation at a time.

AI Is Expensive When It Has to Rediscover You

I use AI heavily when I build software. I want it writing code, generating tests, researching APIs, chasing errors, refactoring, and doing the mechanical work that used to eat enormous amounts of engineering time. What I have also learned is that a coding agent starts every session knowing nothing about how I build software.

It does not know my architectural preferences. It does not know how I organize a repository, structure an API, handle configuration, think about dependencies, approach testing, or design for deployment and rollback. Without that context it has to make those decisions itself, and a capable model will usually make reasonable ones. The trouble is that reasonable is not the same thing as mine, and every reasonable but different decision is something I now have to review, argue with, or undo.

So I have been capturing those preferences as reusable instructions and skills. I am onboarding the agent, teaching it how I work once instead of explaining it again in every conversation.

That changes the economics. If I explain the same architectural preference in every session, I am paying to teach the same lesson over and over. If I capture it once and reuse it, future tokens go toward doing the work rather than rediscovering how I want the work done. Keep teaching AI the same lesson and you are paying tuition every time.

Work With AI the Way You Work With People

I would never hire a talented engineer, point them at a repository, and tell them they are smart enough to build whatever architecture seems reasonable. I would onboard them. I would walk them through the architecture and the patterns we use, explain the decisions that came out of painful experience, and tell them what good looks like, where the dangerous parts are, and which assumptions they should not casually change. Then I would expect them to work within that system unless they had a good reason to change it.¹

AI deserves the same treatment. It is not a person, but delegation requires context no matter who or what you are delegating to. Good delegation to people and good delegation to an agent have a lot in common: clear expectations reduce rework, shared context removes decisions nobody needed to make, standards make the output easier to review, and feedback improves the next result. If you want AI to work the way you work, you have to teach it how you work.

The Human Still Owns the Judgment

None of this means engineers need to personally type every line of code. Quite the opposite: AI should take enormous amounts of implementation work off their plate, and that is the whole opportunity. What has to stay with the engineer is understanding.

The engineer still needs to know why the architecture looks the way it does, where responsibilities live, which assumptions are baked into the system, how a failure in one place spreads to another, and how to change any of it safely. The engineer asking for a bigger budget could write prompts all day. What they could not do was answer those questions, and that is what the budget request was really about.

That shifts the skill profile of software engineering. An engineer who can only understand code they personally wrote is going to struggle in an AI-heavy environment, because all of us are going to spend more time reviewing, reading, debugging, and extending code we did not type. The skill that matters is building and maintaining a mental model of the system. That means less typing and more of the part of engineering that mattered all along.

The Worst Token Spending Creates More Token Spending

Dependency is expensive for one more reason: it compounds. If AI produces a system you do not understand, the next feature needs AI to interpret it. So does the debugging session, and so does the refactoring, and then understanding the refactoring needs AI too. Every previous token creates demand for another one. That is a terrible cost curve, and it is exactly the curve the engineer asking for a bigger budget has been riding.

Reusable context compounds in the opposite direction. Architectural guidance, coding conventions, examples, skills, and workflows make each next interaction easier. The agent makes fewer unnecessary decisions, reviews go faster because the output looks familiar, and the engineer spends less time reverse engineering what the agent decided to do. AI usage can compound either way, and the difference fits in one line: dependency compounds consumption, while context compounds capability.

Token ROI Should Be Measured by Outcomes

This is why raw token consumption is such a dangerous organizational metric. Take two engineers. One burns through five million tokens and delivers a system that solves a valuable problem, fits the platform architecture, has good tests, can be operated safely, and is understood by the rest of the team. The other uses one million tokens and produces much less. Which one was more expensive?

You cannot answer that from the token count, because the denominator matters. Organizations should care about AI cost, but the useful measure is not tokens per engineer. It is something closer to useful outcomes per dollar of inference, where the outcomes include delivery speed, quality, maintainability, learning, operational work that went away, and reusable capability created along the way.²

By that measure, a team consuming a large token budget while creating serious business value may be an excellent investment. A team consuming less while repeatedly asking AI to rediscover its own work may be wasting both the tokens and the engineering time, and it will look thrifty on the dashboard the entire time.

Do Not Optimize the Wrong Thing

Companies are going to put controls around AI spending, and they should, because at sufficient scale inference is a real operating expense. But tell teams to simply use fewer tokens and you will get exactly the behavior you would expect. People will optimize the metric. They will use fewer tokens, and that tells you nothing about whether they are creating more value.

This is the same old management mistake with a new unit of measurement: measure the wrong thing aggressively enough and people get very good at improving it. The invoice model cannot tell a team building capability from a team building dependency, and it only notices the engineer from the opening when their budget request arrives, long after the real cost has been paid. The cheapest AI organization is not necessarily the one consuming the fewest tokens. It is the one getting the most durable capability out of the tokens it does consume.

What Remains After the Tokens Are Gone?

The pressure to produce more with AI is justified. The productivity gains are real, and they are going to get larger. But speed without understanding creates debt, and eventually somebody pays it, whether that is during the next feature, a major refactoring, or an incident where the person responsible for the system cannot explain what it is doing.

AI does not remove the need to understand our systems. It makes that understanding more valuable, because our ability to produce software is growing much faster than our ability to comprehend it.

So use the tokens, and use a lot of them when the return justifies it. Let AI write the code, automate the tedious work, and explore possibilities faster than you could by hand. But teach it how you work, capture what matters, reuse what you learn, and keep the judgment and the understanding on the human side of the relationship.

The cost of tokens is not what you spend on AI. It is what remains after the tokens are gone. If all that remains is code nobody understands and an engineer who cannot work without another budget increase, those were expensive tokens. If what remains is working software, stronger engineers, reusable skills, better processes, and an organization that can move faster the next time, they may have been some of the cheapest productive capacity you ever bought.