You can't save your way out of the triangle
Somewhere in leadership meetings at companies big and small, somebody is saying "let's be careful with model costs." Everybody nods, and the meeting moves on. I want to talk about that half-second of nodding, because I think it's one of the most expensive half-seconds in software right now. A smaller token bill can leave a bigger bill for the humans.
I've seen a lot in my years as an engineer (some of them leading engineering), and I've watched this move more than once. So I've developed a specific allergy. I get twitchy when a room calls something a saving without looking at who got the work.
"Be careful with model costs" leaves plenty of room for that. The bill is visible. The work it bought is harder to see.
Martin Barnes described the triangle's beginnings in his own 2006 account. In 1969 he developed a course on time and money in contract control, drew a triangle on one of those courses, and moved a coin around it on an overhead projector to show the tensions competing.
The drawing above is the one I use. The constraints are time, cost and scope, with quality in the middle. You don't set quality, it's what falls out of the three you do set. Keep the deadline and the feature list, cut spending in a way that creates more work, and that work has to land somewhere.
The team can take longer. It can deliver less. If both promises stay fixed, it can also rush the checking and ship something worse.
AI can improve the work and lower the cost together. The trouble starts when a cheaper model needs more help, and the budget decision has made no room for the help.
"Code is no longer the bottleneck"
That's from Anthropic's AI-Native SDLC Playbook. It lays out six stages, from planning through maintenance, connected by committed artifacts: intent, spec, plan, code, tests, review findings.
The constraint moves to the stages that "still run at human speed." Plan, review, deploy. "Human attention concentrates at the gates."
So the people reading and deciding still matter. Speeding up the build can put more work in front of them. The playbook describes checks around that work: continuous evals gating configuration changes, agent review, feedback before human review, and governance enforced through hooks. Those checks take work too.
I read it twice looking for the model-cost policy. It names a budget for eval runs and a spend limit for security scans. It also says to evaluate model changes. What it doesn't supply is a per-task policy for choosing cheaper models across the workflow while preserving the checks.
My reading is that the capable gate layer, and the money to run it, are assumed. That leaves a decision for the people adopting it: what stays funded when someone says to be careful?
The spiral
Here's the version of that meeting that worries me. The team changes its default to a cheaper model without checking how it performs on the work. Nobody decides which tasks still need the more capable one. The same pressure reaches the reviewing model.
The roadmap stays put. Same date, same features. The token bill falls, and that is the only part of the change anybody measured.
Then a reviewer starts getting plausible output she can't trust. Maybe it misses a constraint the previous model caught. Maybe the review agent waves through something she finds herself. The price didn't cause those misses. But if the replacement makes them more often on this work, somebody now has to cover the difference.
She reads the whole diff again. Checks the assumptions. Goes back to the spec. The review that was supposed to bring her the questionable parts now requires her to find them.
That costs time. If she takes it, other work waits. If the deadline wins and she skims, more of the unchecked work can get through. The plan can still look unchanged while the thing being delivered changes underneath it.
I've priced the human side elsewhere: at a sustained working maximum, a human produces tokens about a thousand times more expensively than a model does, under the assumptions in Human Tokens. That's a per-token comparison. It gives no thousand-to-one price for reviewing a feature. The actual bill depends on the minutes spent, the retries, and the work that has to be done again.
Which is exactly the comparison the meeting skipped.
So now the engineer starts taking work back. She still lets the agent handle the small edits. After enough wrong turns, she keeps the migration for herself. With no reliable route to a more capable model, doing it by hand becomes the sensible choice.
The feature list hasn't shrunk. The part of it the team will trust to agents has. And the engineer doing that migration has fewer hours left to check everyone else's output.
Meanwhile somebody else is in a hurry. The cheap model is still the default, nothing blocks the risky task, and it gets handed a billing change. If the checks miss the error, the customer becomes the next person to test it.
That failure can make the team trust agents even less. More work comes back to the humans, review gets squeezed again, and the default still hasn't changed. (It was only supposed to be a cheaper model.)
That's the spiral. Each response makes sense from the desk where it happens. Read more carefully, take the difficult work back, somehow still finish before the deadline. Together they can eat the saving and leave a tired team wondering why the agents aren't helping anymore.
What does it cost to be wrong?
I'm not saying use the biggest model for everything. The useful question is smaller than that: can this model do this task, with these checks, at a lower total cost?
A commit message is easy to inspect and cheap to replace. A migration or a change to the code that handles a customer's card needs a different answer. The cost of a mistake changes how much checking is worth buying. A capable model still makes mistakes, so buying one doesn't settle the question either.
The break-even belongs to the task. A cheaper call is a saving when the difference survives the review and rework. If it takes enough extra checking to eat that difference, the saving is gone. Both outcomes are possible, and a model's price tag can't choose between them.
So somebody has to read what was asked, decide where the task belongs, and check what comes back. Doing all of that by hand spends the attention the agents were supposed to free.
A capable model can do much of that management work. Its job is to read the intent, route the task, check the result against the request, and escalate what it can't settle. It needs written instructions and a way to stop the work. "Please be careful" is just as incomplete when addressed to a model.
The mechanical rules still set the floor. Tests still run. A human still reviews anything red. I've written that review matrix up: the agent can propose a risk tier, but it can't talk its way around the rules or grant itself permission.
That matters when the cheaper default meets the billing change. The route to human review needs to survive somebody being in a hurry. Otherwise the policy lasts until the first deadline.
And that manager has to stay on. Every task that relies on its judgment needs that judgment funded. The calls can be triggered as work arrives, the checking can't become optional because the monthly bill looks uncomfortable. If the workflow needs the more capable model there, that is part of what it costs to use the cheaper ones.
"We mostly use small models" can be true by volume and false by bill. A lot of little jobs can still depend on expensive judgment around them. Count that judgment before announcing what the little jobs saved.
The corner on the dashboard
It's the tile move. A house can have less expensive tile laid well. But cut the budget by rushing the laying and skipping the checks, and the saving can end up in a crooked shower. The house absorbed a decision that looked finished on an invoice.
The same distinction matters here. Some model savings are real. Some are unfinished work handed to a person whose time doesn't appear beside the token bill.
Cost per accepted unit of work makes that handoff visible. Count the model calls, including the manager and the attempts that went nowhere. Add the human time spent specifying, reviewing, and fixing. Keep escaped defects next to that number, because accepting more work through a weaker gate can make the number look better while the result gets worse.
Compare the same kind of work against the same acceptance standard. If the cheaper model gets there with less total spending, use it. If the reviewer is doing the saving for it, count her time.
And fund the gate layer before treating the cheaper model as a saving. The checks are part of the purchase. Without them, the team is betting that whatever the model misses will be cheap for somebody else to catch.
The triangle doesn't care which corner you're watching. It only cares which one you're not.