22 min read
“We cannot afford to build this with tokens.”
That is the sentence I keep hearing. The strange word is not “tokens.” It is “this.”
No one defines “this.” Is it a migration that removes $400,000 in manual operations? A compliance fix? A product bet no customer asked for? A way to stop manual QA from consuming two people every release? Nobody knows, because nobody priced the value before pricing the model.
Worse, nobody can usually tell you what it costs to produce anything in the current system either. Not the ticket estimate. The actual cost to produce accepted software: planning loops, meetings, QA passes, release coordination, rework, senior review, transformation-office overhead, and the delay between approved and done.
Then the conversation does the move I cannot get past.
“We cannot afford frontier models.” Fine. But the same organization is still paying for manual QA passes, hand-built release notes, rework after brittle test coverage, release coordination, and senior engineers doing cleanup work on Friday afternoon. It may have funded a full agile transformation office for a decade without knowing whether cycle time, release quality, or total cost improved. Someone says Model X is 20% cheaper, and everyone nods as if that means something. Twenty percent cheaper than what? Per token? Per accepted change? Per production defect avoided? Per week pulled out of the schedule? Per hour of senior review not consumed?
Nobody knows.
A model invoice is visible. Another QA pass is payroll. Ten years of transformation staff is an org chart. Tokens did not become expensive. They became itemized, and itemized costs make executives feel like they finally found the leak. The leak was already there. It was hiding in another row on the fiscal-year spreadsheet.
So the decision becomes: we cannot justify the token investment because “this” has no value case, therefore we will build “this” using the old human-intensive process, and somehow that will be cheaper because payroll already exists and delay has worse accounting.
That is the cycle I keep hearing.
I have VP friends who tell me the private version after the meeting. “We have a budget. We made commitments. We hope to get it out, but we probably won’t.” They are not being cynical. They are describing a system where budget is a promise, delivery is a hope, and nobody can see the production economics clearly enough to intervene before the miss becomes normal.
It may be survivable this year. You can hide another QA pass in payroll. You can let the transformation office produce another operating-model update. You can absorb another release delay. You can ask the same senior people to do one more rescue pass and call it teamwork. But next year, when the companies learning this system have turned machine production into muscle memory, the same confusion becomes an operating disadvantage.
That first sentence is not one objection. It is four separate claims stacked on top of each other, and the stack matters. “We cannot afford” means the work either does not have an economic case or the organization has not priced the alternatives accurately. “Tokens” means the company is staring at the visible meter while ignoring senior human attention, delay, coordination, rework, review queues, and the opportunity cost of pulling your best people back into mechanical production.
“To build this” is the phrase everyone skips. What is this? A revenue-protecting migration? A compliance requirement? A support-cost reduction? A product bet with no measurable value? The answer changes the economics before anyone opens the model dashboard. “With tokens” is not compared with magic. It is compared with the old path, where humans absorb the work because payroll was already approved and delay rarely sends an invoice.
That is why the sentence matters. It sounds like token discipline, but it is usually portfolio confusion.
Tokens are the cheapest form of building software.
They are cheap because the alternative is senior human attention, calendar time, coordination, rework, and the quiet death of the next thing your best people were supposed to build. The mistake is not watching token spend. The mistake is watching token spend as if it is a software strategy.
What I keep telling leadership teams is simpler and harder: this is portfolio management. You are making bets on software.
Why is the cheapest input on trial before anyone names the value of the bet?
The Portfolio Is the Work
I wrote recently that your AI token burn is not the problem, the work is. This is the next conversation, because once the token line becomes visible the organization has to decide what kind of management system it wants.
Most readers also read: The Engineers Who Can’t Use AI Agents Don’t Have a Tools Problem
A hedge fund does not assume every position wins. It sizes the position, hedges exposure, watches downside, cuts losers, and lets winners compound. The discipline is not believing harder. The discipline is knowing how much capital to put at risk before the signal proves itself.
Software leaders make the same kind of bets, just with worse vocabulary. Every roadmap item is an investment thesis. This feature will reduce churn. This migration will lower support load. This integration will protect revenue. This compliance work will reduce audit exposure. Some bets win. Some miss. The immature move is pretending everything on the roadmap is equally strategic because a steering committee approved it in March.
The mature move is to manage the software portfolio.
A small reversible bet gets a small model, a narrow budget, and fast acceptance criteria. A strategic bet gets stronger models, better tests, tighter governance, and executive visibility. A weak bet gets starved early. A bad bet gets killed before it becomes a six-month plan with a sunk-cost lobby.
This is where the hedge matters. You do not hedge by starving every position. You hedge by limiting exposure on uncertain work, preserving capital for high-conviction work, and making sure one bad bet cannot wreck the portfolio. In software, that means bounded agent budgets, security controls, human review on risky changes, rollback paths, and a clear owner who can stop the work.
The token budget is not morale spend for engineers. It is risk capital for software production.
A token cap is not portfolio management. It is the company trying to manage the factory by rationing the cheapest machine in the building.
That is the frame executives need before they argue about caps. Ask whether the company is placing too many low-conviction software bets, underfunding the high-conviction ones, and confusing cost control with starving the cheapest production input. A useful portfolio review has a thesis, a budget, a risk boundary, an owner, an acceptance standard, and a kill condition. If the work cannot survive that lightweight discipline, the token bill is doing you a favor by making the weakness visible early.
Are you managing a software portfolio, or just starving every bet until the spreadsheet looks calm?
The Objection Is Rational
When someone says, “We cannot afford to build this with tokens,” I do not dismiss it. I ask what this is worth.
That question changes the room. If a billing migration is worth $400,000 in avoided manual operations and risk reduction, a $4,000 token budget is not the scary part. If a settings-page redesign has no measurable value and wants the same treatment, the token estimate is not the issue. The work is.
A $60 agent run that saves two hours of senior engineering time is not expensive. A $600 run that closes a production risk before the weekend is not expensive. A $6,000 run that finishes a migration a month earlier may be cheap if the migration removes support load, audit exposure, manual operations the business is already paying for, or gets a customer-visible capability into market before a competitor takes the slot.
And yes, you have competitors. Some are obvious. Some are not companies at all. They are the budget your customer moves somewhere else because your feature is still in release coordination.
The same math applies to remediation. An agent sequence that finally pays down enough technical debt to let you release when you choose is not overhead. It is capacity recovery. If the work reduces fragile deployments, cuts QA passes, removes manual checks, and lowers the cost of the next ten releases, the token bill is buying option value the old process kept promising and never delivered.
A $6 run that creates a half-day of cleanup is expensive.
The token number is not the unit of economics. The accepted outcome is.
That is why Before You Build a Token Economics Dashboard, Build a Value Dashboard matters. A dashboard that starts with “how much did we spend?” will train the company to worship the smallest visible number. A dashboard that starts with “what did the spend finish?” has a chance of becoming a management instrument.
The CFO is not wrong to ask about the model line. The wrong move is comparing that line to zero. The comparison is model spend plus human attention plus delay plus rework risk plus governance overhead against the old path that already contains all of those things, just with worse labels.
Your CFO should not be asking what you spent tokens on as if the model invoice is a minibar tab. Your CFO should be asking why the highest-ROI production input in the software portfolio is underfunded.
For the CFO, this should fit on one page. What is the value if the work lands? What does the old path cost in people, delay, and risk? What does the machine path cost in tokens, model choice, review time, and controls? What metric tells you the bet worked? If the answer needs a 40-slide deck, someone is hiding uncertainty inside formatting.
What exactly is the company approving when the old path and the machine path never appear on the same economic page?
The Old Constraint Was People
For most of my career, when software capacity ran out, leaders had four choices. Hire more people. Delay the work. Cut scope. Burn down the people they already had.
Hiring more people worked at first. That is why executives kept doing it. A five-person team became twelve, the backlog moved, customers got features, and the organization felt the burst of speed. That burst was real. It was often worth it.
Then the curve bent.
Every new engineer needed onboarding, context, environment access, code review, architecture explanation, product judgment, and a place in the communication graph. The team got more hands and more coordination. The more people you hired, the more time the best people spent making the larger system function.
Fred Brooks gave us the warning in The Mythical Man-Month. Adding people to late software makes it later because software work is not typing. It is sequencing, integration, communication, and shared understanding. You can buy more hands. You cannot buy instant context.
Companies got comfortable with that tradeoff because it was familiar. Hiring was slow, but it looked strategic. Delay was expensive, but it rarely had its own invoice. Scope cuts were political, but survivable. Burnout was shameful, but easily disguised as commitment until the exit interviews arrived.
I say that with fingerprints on the scene. I spent time as an agile consultant helping companies make the people constraint look manageable: ceremonies, boards, backlogs, planning cadences, transformation language, the respectable furniture of coordination. Some of it helped. Some of it became another meeting wrapped around a delivery system nobody could price. If I made one of your status rituals longer, I apologize. Mostly.
Some companies took the next obvious step: if people are the constraint, buy cheaper people. Offshore it. Nearshore it. Vendor it. Turn software into labor arbitrage and call it delivery strategy. Sometimes that helped. Often it just moved the coordination cost somewhere harder to see.
AI turns that model on its head because the cheapest unit is no longer a lower-cost person with less context. The cheapest unit is machine production wrapped in human judgment. A few great engineers with enough token budget can ship more accepted software than an army of low-cost developers arranged for a 2018 operating model.
That is not permission to treat the people in the old model as disposable. It is a warning that the old model was wasting them.
The old game was buying cheaper hands. The new game is giving better builders more machine capacity and holding them accountable for what ships.
That sentence is uncomfortable because a lot of companies built their software economics around the opposite bet. That is a different article, but pretending the old labor race still fits the new production model is how you buy yesterday’s constraints at tomorrow’s price.
Tokens expose a fifth choice: buy machine work in small, metered increments and reserve human judgment for the work that actually needs it.
That is a better constraint. It is not an unlimited constraint. It is not a magic constraint. It still needs governance, budgeting, security, architecture, and adult supervision. But compared with senior engineering attention, it is cheap.
If the work is worth doing, the first question should not be “how do we minimize tokens?” The first question should be “what is the cheapest safe production path to accepted work?”
Sometimes that path uses a small model. Sometimes it uses a frontier model. Sometimes it uses a human. Sometimes it tells you the work should not exist.
All four answers are useful.
Why keep treating headcount as the only lever when tokens are now the cheaper constraint?
Estimation Is Not New
Once the room accepts that tokens are a production constraint, the conversation usually moves to estimation. “We do not know how much this will cost.”
Correct. You probably do not. You also did not know how much the feature would cost when you approved the people.
Software estimation has always had a dark-magic layer. We dressed it up as story points, t-shirt sizes, planning poker, confidence intervals, and roadmap commitments with “tentative” written in small gray type. Some teams got decent at it. Most teams got decent at defending the miss after the miss was already obvious.
Tokens did not create estimation uncertainty. They moved some of it from invisible labor to visible consumption, which is why the number feels rude. It interrupts the old fiction that the human process was predictable because the invoice arrived as salary.
The model bill feels risky because it tells the truth sooner than the roadmap does.
That should make the conversation better, not worse. A visible constraint can be managed. An invisible constraint gets rationalized until everyone is tired and the roadmap still has the same work on it.
Do the same thing with agentic work that you should have been doing with human work all along. Low-context, reversible work gets a small model or a narrow agent budget. Medium-context product work gets a bounded frontier-model budget with human review. High-context, multi-step work gets an explicit investment case, logs, tests, rollback, and a named owner. Work with no value hypothesis gets nothing until someone can explain why it belongs on the roadmap.
That is not exotic. It is portfolio discipline applied one feature at a time.
The standard should not become magically higher because the cost is finally visible. If a company could approve six months of human labor with a fuzzy estimate, it can approve a machine path with a bounded range.
Why did uncertainty become unacceptable only when the cost moved from payroll to the model bill?
Cheaper Models Can Cost More
That uncertainty creates a safe-sounding answer. “We will just use a cheaper model.”
Sometimes that is exactly right. Low-context work, reversible changes, rote transformations, summarization, classification, test scaffolding, and well-bounded refactors often do not need the strongest model in the building. If the small model gets the work to acceptance safely, use it. There is no award for spending frontier-model money on work a cheaper model can finish.
But “use the cheaper model” is not a strategy. It is a routing decision.
This is where I keep hearing the 20% cheaper argument. It sounds financially serious until you ask what the 20% is attached to. A weaker model can cost less per token and still cost more to produce the accepted outcome. It may need twice the tokens because you have to restate context, narrow the task, recover from wrong turns, and run the same workflow again. It may need triple the human labor because a senior engineer has to babysit the plan, repair the patch, explain the domain rules, and review the work more carefully because trust is lower.
The model invoice will still look smaller. The production cost will not.
That is not savings. That is hiding labor inside a discount model and calling the spreadsheet disciplined.
This is where teams fool themselves. Procurement sees cheaper unit price. Engineering sees more retries. The staff engineer sees another hour gone. The roadmap sees another day slip. Finance sees model savings and misses the labor conversion happening under the table.
The cheapest model is the one that gets the work to acceptance at the lowest total cost, including tokens, retries, review, rework, delay, and risk. Sometimes that is the small model. Sometimes it is the frontier model. Sometimes it is a human because the data cannot leave the boundary or the judgment burden is too high.
Model choice is part of portfolio management. Do not standardize on the weaker model because the spreadsheet likes the unit price. Route the work to the cheapest safe production path. At consumer scale, that may mean ruthless unit economics. In a bank, hospital, law firm, public agency, or European insurer, it may mean a slower sovereign or approved model because data handling and auditability are part of the cost model. The right answer is not always the most capable model. It is the model path that can finish the work without smuggling risk into the business.
If the cheaper model needs more retries, more review, and more repair, what exactly got cheaper?
Governance Is Not a Freeze
After model choice comes the governance fear. “People will burn tokens on nonsense.”
Some people will. Professional engineers will not. That is why they are professionals. They spend tokens the way they spend production access, cloud budget, review time, and customer trust: deliberately, with a reason, and with a record.
If your governance model assumes professional engineers will set money on fire the second they touch a model, the problem is not tokens. The problem is that leadership does not trust its own production system.
People waste everything when the system lets them. They waste meeting time. They waste sprint capacity. They waste cloud compute. They waste vendor hours. They waste roadmap slots on features a customer never asked for. They waste senior engineering attention on style debates because the organization never built a better review system.
AI did not invent waste. It attached a meter to a new part of it.
So govern it. Put alerts on spend. Attach agent runs to work items. Keep logs. Separate personal use from company use. Require a written value hypothesis for expensive runs. Scope credentials. Put human review where the risk justifies it. Build the controls the security review needs when the work touches customer data, auth, billing, infrastructure, or regulated workflows.
Those controls are normal. What is not normal is turning governance into a production freeze.
In regulated work, the control set may be heavier. Good. Say that plainly. Data classification, approved models, audit trails, prompt and output retention, explainability, rollback, and named accountability are not bureaucracy when the work touches patients, payments, privileged documents, student records, critical infrastructure, or public services. They are part of the production method. Price them, plan them, and stop pretending the only economic variable is the model invoice.
A universal cap teaches the wrong behavior. It teaches engineers to optimize the dashboard instead of the work. It makes them choose the weaker model when the stronger model is the right production path. It encourages them to stop just before the agent becomes useful because the spend line changed color.
If misuse is the problem, handle misuse. If low-value work is the problem, kill low-value work. If nobody can explain what a feature is worth, fix the portfolio conversation.
Why protect the roadmap from the model bill if the real problem is the work?
Waiting Has an Invoice
When caps, routing, and governance do not settle the argument, timing shows up. “Prices will fall. Why not wait?”
Prices will fall. Capability will rise. Next year’s models will make this year’s models look awkward and expensive, the same way this year’s models make last year’s look like autocomplete wearing a blazer.
That does not make waiting free.
Waiting for cheaper tokens is still spending money. You are just paying in delay, competitor learning, and the slow decay of your own operating model.
That can be a strategy if the goal is to become a cheaper acquisition target for a private equity firm that already knows how to turn AI into software ROI. They will not praise your restraint. They will buy your delay at a discount, fund the machine path, and call the spread margin expansion.
If the work is a non-urgent experiment, waiting can be rational. Use a smaller model. Use a cheaper path. Put a tight boundary around the exercise and move on. There is no virtue in spending frontier-model money to learn something the business does not need to know yet.
But if the work matters now, waiting has its own invoice. Your competitors are not waiting for the perfect price curve before learning how to build with agents. They are learning where agents fail. They are changing tests. They are changing review. They are changing architecture. They are learning which work belongs on frontier models and which work belongs on cheaper ones.
The price curve is not the only thing compounding. Learning compounds. Operating-model changes compound. Agent-maintainable code compounds. I wrote about that in Your Codebase Is Not Agent-Maintainable because the same model behaves very differently inside a system designed for it than inside a system that fights it at every boundary.
If you wait for cheaper tokens but do nothing to make the codebase, tests, permissions, deployment path, and product flow more agent-friendly, you will not be ready when the price falls. You will just be cheaper at being stuck.
What will be cheaper about being late?
Labor Is the Fallback
Under all of those objections sits the fallback nobody wants to say plainly: if the model costs too much, humans can finish it.
That is the software version of saying, “We ran out of gas. Let’s use scissors to cut the grass.” It is activity. It is not progress.
Nobody says it that plainly in the meeting. It sounds rude when stated out loud. But the operating model says it all the time. If the agent budget gets capped, the team can absorb the difference. If the model runs out, the engineer can take over. If the machine path looks too expensive, the people path is already funded.
That sounds reasonable because payroll was already approved.
Payroll is not free. It is just the bill your company learned to stop reading.
It is also how visible token spend gets converted into invisible human drag.
Labor is not free because the monthly payroll number has rhythm. In most companies, the scarce thing is working capital. Labor is one of the ways you spend it, and it is usually the slowest, least reversible, most coordination-heavy way to buy software capacity. The scarce inputs inside that spend are judgment, attention, context, sequencing, review capacity, and the ability to hold a messy business problem in your head long enough to turn it into working software.
When you refuse to fund the machine and push the remainder back onto people, you do not avoid cost. The work still consumes somebody’s afternoon. It still delays another feature. It still adds review load. It still creates coordination. It still creates the managerial reflex to ask for more headcount because the organization starved the cheaper constraint and overloaded the expensive one.
Sometimes the human path is the right path. The work is sensitive. The model is not allowed near the data. The tests are not ready. The risk surface is too high. The organization needs judgment before acceleration. Good. Say that and price it accurately.
Do not call it savings.
You are choosing a different production method with a different cost profile. If the value case cannot survive either path, do not build it.
Where is the invoice for the human attention you just consumed?
The Fix
Before the next token-policy meeting, make it a portfolio review. Pick five active features. Not five hypotheticals. Five things already consuming engineering attention.
Ask what each one is worth if it ships this month instead of next quarter. Ask what cost it removes, what revenue it protects, what risk it reduces, what customer commitment it saves, or what strategic option it creates. Then ask what model path and token range give you the fastest safe path, what human attention is still required, what delay costs if you slow it down, and what rework or security risk you create if you underpower the model.
Then ask the question that makes everyone shift in their chair:
If this feature cannot support that investment, why is it on the roadmap?
The board does not need a theological debate about whether agents are expensive. The CFO does not need another model-picker argument. The CTO does not need a dashboard proving engineers used fewer tokens while cycle time stayed flat.
They need to know whether the company is placing the right software bets and buying completed work at a lower total cost than the old production system.
The executive job is not to make tokens smaller. It is to make bad bets die faster and good bets move faster.
That means value stream maps, accepted outcomes, human attention, delay, risk, and token spend in the same conversation. I wrote about this in Waste Density vs Value Density because most companies still cannot answer what a feature costs to build, let alone what an AI-assisted feature costs.
Tokens did not make that weakness dangerous. They made it measurable.
I am not arguing for unlimited token spend. Unlimited anything is not strategy. It is avoidance with a credit card.
I am arguing for economic consistency. If the feature is worth building, fund the production system that builds it most effectively. If the strong model changes the outcome, use it. If the small model is enough, use it. If the work needs human judgment, use humans. If the value is too small to justify any serious investment, stop dragging it through planning, design, engineering, QA, security, release, and the next steering committee.
Kill that work.
The discipline is not in spending fewer tokens. The discipline is in knowing which work deserves the cheapest safe production path.
This does not require a new governance ceremony. For a startup, it may be a one-page decision record and a pull request. For a Fortune 100, it may be a portfolio review across business units. For a public agency, hospital, bank, utility, university, or global platform, it may carry procurement, data residency, compliance, localization, accessibility, safety, and audit requirements. Fine. Make those constraints explicit. Constraints are manageable when they are named.
That is why just giving builders the best model is not a luxury argument. It is a production argument. If a senior engineer is moving work through the system faster with a stronger model, starving that workflow because the token line looks unfamiliar is not financial discipline. It is the operating model defending itself using cost-control language.
Your company can still decide the answer is no. No, this feature does not justify the agent budget. No, this migration is not worth doing now. No, this product idea should stay on the shelf until the value case improves. No, this codebase is too risky for autonomous work until the tests and deployment path are repaired.
Those are useful answers.
A mature software portfolio has losses. It just takes them early, in small denominations, before they become six-month projects defended by everyone who approved them.
What is not useful is pretending the token bill made a valuable thing unaffordable while quietly moving the same work back into payroll, QA passes, transformation-office updates, delay, review queues, and coordination.
The future of software is not a larger room full of people typing faster. The future is tokens and machines doing much of the mechanical production while humans decide what should exist, how it should be governed, and whether the result is good enough to accept.
That does not make people disposable. It makes unmanaged human attention indefensible. This is not a layoff argument. It is a redeployment argument: stop spending human judgment on mechanical production the machine can absorb, and put your people where judgment actually changes the outcome. Your best people should not spend the next decade doing cleanup work the production system could have absorbed, then get blamed for being slow when the company refused to fund the cheaper constraint.
You can decide that future is a fad. You can wait for it to disappear and hope the company gets to return to 2018, when the model bill was zero because the cost was hiding in payroll. That is a comforting story. It is also a strange thing to bet a software portfolio on.
You can build software as if frontier models never happened. You just need to be honest about how many people that old world requires, how slowly it moves, and why you are protecting the most expensive constraint by starving the cheapest one.
If you are doing this right, total cost of ownership should drop. Not the model line. The actual cost of getting accepted software into production and keeping it healthy: working capital, payroll drag, review load, QA passes, delay, rework, risk, and the next thing your best people did not build because they were cleaning up the old system. If that is not how your organization measures software yet, start with Stop Buying Software by the Hour. That is the spreadsheet this argument lives in.
Throwing money at the problem is not going to fix it. Starving the cheapest production input will not fix it either. The work has to earn the production system, and the production system has to lower TCO.
If the cheapest production constraint in software is the one you refuse to fund, what business are you really protecting?
Companion
