We spent months watching engineers use AI coding agents on real engineering work. Not demos. Not benchmarks. Actual teams, actual code, actual deadlines.
This is not a post about a product. It is a post about patterns. Here is what showed up, and here is what surprised us.
The scene that started it
I was in a working session with a customer’s engineering team, watching how our agentic loop fits into theirs. Two of their engineers picked up the same task at the same time. Both had Cursor. Both knew the codebase.
The first one started right away. He had access set up already. He picked the token-free model, the one that costs nothing in Cursor, and got to work. No cost. He was moving inside a minute.
The second engineer couldn’t start. She needed tooling access, which meant a ticket to IT, which meant waiting. Twenty minutes later she had it installed and opened Cursor with Opus 4.6.
You know how this is supposed to go. The first engineer has a twenty minute head start and spends nothing. The second one burned time on process and is paying for a premium model. Easy call.
It was not the call.
The first engineer spent his lead correcting the agent. Reprompting. Fixing what it got wrong. Explaining again. The token-free model was cheap by the token and expensive by the engineer hour.
The second engineer caught up in ten minutes. Then she passed him. Same task, worse starting position, better model, and she finished first.
That is the whole argument in one scene. Your engineer’s time is the expensive resource. Next to a corrected hour of it, the token cost on the task is small. Not nothing. Small.
The spectrum
Once you start watching for it, teams sort onto a spectrum of how they use AI.
At one end are the orgs that refuse it. They have opted out of the game entirely. We don’t need to spend time here. After all, they are losing to everyone who didn’t opt out, and they mostly know it.
At the other end is fully autonomous work. Agents running agents, humans barely in the loop. We are not going to comment on that end. We haven’t watched it closely enough to say anything useful, and guessing would be the opposite of the point of this post.
Everyone reading this lives in the middle. Humans still in the loop. Engineers driving agents, reviewing output, deciding what ships. And in that middle, the single biggest variable we observed was not talent or tooling. It was model choice, and the failure modes that grow out of it.
Here are the ones we saw most.
Anti-Pattern: the token-free default
The most common one. An engineer, given a choice, picks the free model. Not out of analysis. Out of habit, or because a dashboard nudged them there, or because nobody told them it mattered.
The cost never shows up on the bill. It shows up in their afternoon.
Anti-Pattern: the correction spiral
The free model gets you eighty percent of the way and leaves the last twenty as your problem. Reprompt. Clarify. Fix. Explain the thing you already explained.
Nobody notices this cost because it is diffuse. After all, there is no line item for “spent forty minutes arguing with the agent.” So it just feels like work. It looks like the engineer being busy. But it is the most expensive kind of busy there is.
Anti-Pattern: the cost-dashboard trap
This is the one that catches leaders. You get a per-token cost view. It is clean, it is visible, it goes up and to the right when people use better models. So you optimize it down.
The metric you can see goes green. Meanwhile the metric you can’t see, engineer hours, goes red. As a result, you have made the dashboard happy and the team slower.
Anti-Pattern: the personal-economics workaround
The subtle one. When you force cheap models, your best engineers don’t comply. They route around you. They use their own accounts, their own keys, whatever gets them the good model, because they can feel the difference even if they can’t chart it.
So now your policy isn’t saving money. Instead, it is just producing shadow usage you can’t see and can’t govern.
The mistake underneath all four
Look at those four and you see one mistake wearing four coats.
Somewhere along the way, model choice got pushed down to the individual engineer as a cost decision. Pick the cheap one, save the company money, be a good citizen. But the engineer can only see the number in front of them, the token cost on their task. They cannot see the corrected hour, the diffuse afternoon, the shadow usage across the team. So they optimize the one number they can see, and it is the wrong number.
Cost economics do not belong at the keystroke. A single engineer deciding, task by task, whether a better model is worth a few cents is optimizing a rounding error while the real cost, their time, runs unmeasured. That is not a decision that should live with the person under deadline pressure. It is an org-level call, and the org keeps handing it down.
The part that surprises people
Here is the objection we hear next. Fine, but if we let everyone use the best model all the time, the bill explodes.
It does not, and the reason is the shape of the market. At the top of the range, the good models cost roughly the same as each other. The gap between the strongest options is cents, not dollars. The real cliff is at the bottom, between the token-free tier and the good tier.
Name the tiers
To make that concrete, here is the landscape as we write this, mid-2026. The names will age. The shape will not.
Token-free. The free-plan model, the local one on your laptop, whatever costs nothing per call. Haiku, a GPT mini, an Ollama build. Good at what they are for: autocomplete, a one-file edit, a small change you can describe in a sentence. Point them at a real task that spans files and context and they start guessing, and you start correcting.
Workhorse. Sonnet-class, the paid default. This is where most real work belongs. Strong enough to hold a multi-file task in its head, cheap enough to run all day without thinking about it.
Frontier. Opus-class and the strongest GPT reasoning models. The adviser slot, the one you reach for when being wrong is expensive.
Where the money actually is
The paid tools cluster within a few dollars of each other. Workhorse plans land around twenty a month, heavy tiers near a hundred. The spread across the good options is small. The spread between free and good is the whole story.
This is not a lonely observation. Others measuring real spend are landing in the same place: The Register reported an inflection point around 35 to 40 percent of spend where burning more tokens stops improving output, and that higher spend does not reliably mean higher productivity. The shape is the same whether you get there from token math or from watching people work.
So the decision was never “cheapest model versus most expensive.” It was “escape the bottom or don’t.” Once you are in the paid band, which model you pick barely moves the bill, and it moves the outcome a lot. The expensive mistake is staying at the bottom to save money that was never the constraint.
Why this lands on your desk
Two reasons a leader should care beyond the arithmetic.
Talent. Your best engineers know the difference between a model that fights them and one that doesn’t. So when you hand them the weak one to save money, they feel it every hour. Meanwhile, the teams they could leave for are not handicapping their people this way. In effect, you are training your strongest engineers to resent their tools, and resentment is portable.
Speed to market. Every correction cycle is a feature that shipped later. However, the friction does not show up as a missed deadline. Instead, it shows up as a quarter that produced a little less than it should have, with no single cause you can point to. Multiply the corrected hour across a team across a year, and you have handed your competitors a head start you chose to give them.
What we actually do
One tactic, offered as a data point, not a prescription.
You don’t have to run the most expensive model on everything to avoid the trap. We work in a mid-tier model for routine coding and pull in a stronger model as an adviser for the hard calls, the security-sensitive changes, the architecture decisions, the places where being wrong is expensive. Cheap tier for volume, strong tier for judgment. You stay in the high-end band where the costs are close and the outcomes matter, and you stop asking engineers to price their own keystrokes.
We are not alone in landing here. Teams optimizing coding spend from the cost side arrive at the same rule: start with the cheapest route that clears your quality bar, then escalate based on difficulty and the cost of failure. A frontier model that avoids a few failed attempts or one production incident can be cheaper in practice than the cheap one that didn’t. It is the same principle we watched play out in the room, arrived at from the opposite direction.
The same logic drives where security work should happen. We have written elsewhere about resolving findings with the actor that has the most context, at the cheapest possible moment, instead of queuing them for later. Model choice and workflow are two faces of one idea: put the decision where the context and the leverage actually are.
That is the whole thing. Stop pushing model economics down to the person under deadline. Get your people off the bottom tier. Then measure whether you are shipping faster, because that is the only number that was ever real.
