The warning about AI coding token costs cuts through the hype around developer productivity. AI coding tools can be genuinely useful, but they are not free labor. Every prompt, context window, code review, agent run, retry, and generated test consumes tokens somewhere. If pricing shifts from simple subscriptions toward usage-based billing, engineering leaders will have to manage AI spend with the same seriousness they already apply to cloud costs.
This is especially important because developers are unlikely to reduce usage voluntarily once a tool becomes part of their workflow. If AI helps them ship faster, search codebases, summarize changes, and draft tests, asking them to use less can feel like asking them to become slower. Cost control therefore has to come from tooling, budgets, routing, caching, and policy, not guilt.
We covered the quality side of this shift in AI code review moving quality control earlier. Cost is the other half. A tool that catches defects earlier can save money even if the token bill rises. A tool that generates noisy code and burns through long-context prompts may do the opposite.
IT Home reported Gartner's prediction that by 2028, AI coding costs could exceed the average salary of a human developer as token consumption rises. The report also highlights concern that token accounting and billing methods remain hard for enterprise technology leaders to predict.
The prediction should not be read as a simple argument against AI coding tools. It is an argument for measurement. Teams need to know which tasks benefit most, which models are necessary, and where cheaper or local models are good enough. They also need guardrails around autonomous agents that can repeatedly call tools, inspect files, and regenerate work without a human noticing the bill until later.
Procurement teams will also have to become more technical. A monthly seat price is easy to approve. A variable token bill tied to model choice, context size, cache hit rate, and agent loops is much harder. Vendors that make cost visible and controllable may win enterprise trust faster than vendors that hide usage behind vague productivity promises.
The practical future is likely mixed. Developers will still use AI coding tools because the productivity gains are real. But companies will route tasks more carefully, reserve expensive models for hard work, and push routine completions to cheaper systems. The teams that learn this early will treat AI coding as an engineering system with a budget, not a magic assistant with unlimited patience.
The best engineering response is not to ban AI experimentation. It is to instrument it. Teams should track which repositories, task types, and model routes produce useful output for the money spent. They should also compare AI cost against review time, defect rates, and delivery speed. A high token bill may be acceptable if it prevents expensive bugs. A low token bill may still be wasteful if the generated work is ignored. Measurement is what separates useful automation from expensive theater.
Finance teams will eventually ask for the same clarity they demand from cloud bills. Engineering groups that can explain AI coding spend in plain operational terms will have an easier time defending the tools they genuinely need.
