Last week Fortune ran a piece with a headline that I’ve watched come true in real time: coders are refusing to work without AI, and that could come back to bite them. A day later, on May 30, GitHub Copilot rolled out token-based billing and the developer backlash was immediate. Then on June 10 came the number that ties it together: the “AI-pilled” firms are now spending around $7,500 per employee per month on AI tooling.
Read those three stories in sequence and a pattern shows up. AI coding assistance has become load-bearing for how teams ship, and at the same time the people selling it have figured out how to meter it by the token. Those two facts arrived together, and most engineering orgs haven’t priced in either one.
I’m not writing this as a skeptic. I use Claude Code every day. I built a /implement command that takes a spec and drives most of a feature end to end, and I wrote a whole post about how it changed my own workflow. I am very much on the pro-tooling side of this. Which is exactly why the dependency and the billing model worry me, we adopted them faster than we built the organizational muscle to absorb the risk, and that gap is what worries me rather than anything wrong with the tools.
Load-bearing is a specific word
In structural engineering, “load-bearing” means you can’t remove it without the thing falling down. That’s roughly where a lot of teams now are with AI assistance, and it happened in under two years.
I’ve seen this shape of dependency before, on the operational side. At Zipcar we automated enough of fleet ops that the manual fallback procedures rotted. Nobody had run them in a year, so when an automated system hiccuped, the humans who were supposed to take over had forgotten how. The automation was never really the problem; what hurt was that the backup path had atrophied while no one was watching.
The same thing is happening now with code. A junior engineer who has only ever written software with an assistant alongside them has a different relationship to the work than one who learned to read a stack trace cold. That’s not a moral failing and it’s not a reason to ban the tools. But if the assistant is down, rate-limited, or hallucinating confidently, you find out fast who can still operate without it. The Fortune piece is right that this comes back to bite you, and it tends to happen at the worst possible moment, in the middle of an incident, when the tool you lean on is the thing that’s struggling.
The cost model flipped under us
The second story matters more than the backlash suggests. For years, developer tooling was priced per seat. You hired an engineer, you bought a license, the cost was flat and predictable and it lived in a spreadsheet cell that nobody touched.
Token-based billing breaks that. Now the cost scales with how much your team actually uses the thing, which means your most productive engineers, the ones running long agentic sessions and adopting /implement-style workflows, are also your most expensive. $7,500 per employee per month is real money. At a 400-person company, if even a third of the org is engineering and tooling-heavy, you’re talking about a line item that rivals a meaningful chunk of cloud spend.
We already live with this dynamic in another form. At Vestmark, building features on top of LLMs through RubyLLM, I watch token costs move with usage the same way I watch our ECS Fargate bill move with load. We forecast it, we set budgets, we alert on anomalies, and we treat a sudden spike as a signal worth investigating rather than a surprise on the invoice. The new thing in 2026 is that this same metered, usage-driven cost structure now sits underneath the developers themselves, not just the product.
What I’m telling my own org
A few concrete moves, because abstract worrying doesn’t ship anything.
Treat AI tooling as a tracked budget line rather than something people expense to a card. If your spend scales with tokens, it needs the same treatment as infrastructure: per-team attribution, forecasts, and an alert when a team’s usage doubles in a week. You want to know why it doubled. Maybe someone built something great, maybe an agent is stuck in a loop burning money.
Protect the fallback path on purpose. I am not asking anyone to code with one hand tied behind their back. I am asking that the skill of working without the assistant doesn’t quietly rot the way our manual fleet procedures did. That can be as light as periodic “no-assistant” debugging in code review, or making sure on-call engineers have practiced reading production failures without leaning on a tool that might itself be degraded during an outage.
Hire and promote for judgment, not output. The thing an assistant can’t yet do is decide whether the feature should exist, whether the architecture will survive the next two years, or whether the generated code is subtly wrong in a way that passes the tests. Drift taught me this in the conversational AI days — the model could produce a fluent answer instantly, and the entire job was knowing when fluent and correct had diverged. That judgment is now the scarce, durable skill.
Embrace it, then de-risk it
The teams that win the next few years will use these tools aggressively. I’m not backing off Claude Code or the /implement workflow; they make my engineers measurably faster and the work more interesting. The mistake would be treating “load-bearing” and “metered” as someone else’s problem.
If you run engineering, do two things this quarter. Put a real number on your AI tooling spend, attribute it per team, and set an alert before the invoice does it for you. And pick one practice — a recurring no-assistant debugging session, a fallback runbook drill, anything — that keeps the underlying skill alive on your team. The dependency itself is fine. It’s the one nobody planned for that catches you out.