AI coding costs are on pace to top developer salaries by 2028

Gartner predicts that AI coding token costs will surpass average developer salaries by 2028. That forecast, published June 24, 2026, frames a problem that is already visible in enterprise budgets: agentic coding multiplies token consumption, and per-token pricing turns the most valuable workflows into the most expensive ones.

The numbers behind the shift are stark. When a developer gives an AI agent a coding task, the agent plans, generates code, runs tests, and repeats the process to correct errors. A single task can use 10 to 50 times more tokens than a basic chat prompt. The more useful the agent becomes, the more calls it makes.

The financial pressure has concrete cases. Uber reportedly exhausted its entire 2026 AI budget by April after expanding its use of Claude Code, Anthropic's command-line coding agent. GitHub Copilot moved from flat-rate pricing to metered credits. Both shifts point in the same direction: metered consumption is becoming the dominant cost model for AI-assisted development.

The analysis below comes from sponsored content produced by HPE and published by MIT Technology Review. It was not written by MIT Technology Review's editorial staff. The argument, and the internal HPE data supporting it, remain newsworthy on their own terms for any enterprise weighing AI infrastructure decisions.

Why do spending caps fail?

The natural response to rising token bills is rationing: usage caps, seat limits, and approvals before developers launch agents. HPE's argument is that blanket limits restrict exactly the workflows delivering value. They also optimize the wrong number.

Cost per token measures consumption, not results. Some spending reflects waste, including retries and runaway loops. Some represents the actual work of shipping software. A meter cannot distinguish between the two. Neither can a spending cap.

What should enterprises measure instead?

HPE proposes cost per merged pull request: total AI-assisted development cost divided by the number of changes that pass review and are merged. The company recommends tracking rework and defects alongside it, so cheaper changes do not conceal lower quality.

The logic is straightforward. If cost per merged pull request falls as AI usage rises, without quality degrading, developers are converting more consumption into useful software. The question is not how many tokens teams use. It is how much finished work the investment produces.

Improving that equation, HPE argues, requires two changes:

• Reserve expensive inference for tasks that genuinely need it.
• Lower the cost of routine, repeated work.

How does model routing work in practice?

Agentic coding does not require the most powerful model at every step. HPE's recommended split: use a frontier model, or an on-premises flagship when policy requires it, for difficult planning and novel reasoning. Route suitable work, including code generation, test creation, and repeated refactoring, to open-weight models the enterprise operates itself.

A gateway, an intermediary layer that dispatches requests between models, can route requests according to task complexity, data sensitivity, cost, and latency. This reserves premium inference for the moments that justify it, rather than applying premium pricing to an entire workflow. HPE's formulation: "Meter the exception, not the workload."

Open-weight models make this division increasingly practical. Software-engineering benchmarks show that leading open-weight models can approach frontier performance on some tasks. HPE cautions that benchmark results do not establish equivalence across every repository or workflow. The company advises evaluating candidate models against an organization's own code, tests, and acceptance criteria before assigning production work.

Who should own the inference capacity?

The second structural decision is ownership. With rented inference, every call adds to the bill. With owned capacity, most of the cost is committed upfront, so each additional call gets cheaper as usage grows.

The economics are simple: per-token pricing makes heavy use more expensive, while owned capacity becomes more efficient as teams use it more. Ownership is not free. Power, operations, maintenance, and depreciation all enter the calculation. HPE's position is that the number that matters is the fully loaded cost per merged pull request.

Owned capacity also delivers a type of value that never appears on an invoice: control over sensitive code. When code generation and testing run on-premises, proprietary code stays inside the enterprise. Only approved planning prompts and governed exceptions go to external models, through a gateway the organization controls. That, HPE argues, opens the sensitive repositories where security concerns usually stall adoption, and where the biggest gains are waiting.

What did HPE's own deployment show?

HPE provides its internal deployment as evidence. A hybrid AI platform routes routine workloads from more than 150 internal applications to open-weight models running on premises, including on HPE Private Cloud AI. The result: token costs down 30 to 50%.

That is the point of hybrid architecture, the company argues. Owning inference does not mean giving up frontier models. Enterprises run the volume on capacity they own, and a gateway sends the hardest work to external premium models.

HPE's data also shows that usage, not licensed headcount, drives spend. The top 5% of users generated most of the consumption. The heaviest user consumed roughly 450 times more than the lightest on the same license. If power users grow from a small minority to half the workforce, monthly spend can rise about 4.4 times with flat headcount. HPE notes that every organization's mix will differ, which is exactly why it needs to be measured.

HPE tracks two metrics and recommends customers do the same:

• Cost per active developer, because averaging across all licenses hides the power users driving spend.
• Cost per merged pull request, because it connects AI spending to software that ships.

The recommended sequence: baseline both costs before changing infrastructure, then run a complete development cycle on owned capacity. If both metrics do not improve as usage grows, the current model may still be the better choice.

Ration or build?

Owned capacity is not for everyone, HPE concedes. Low or unpredictable usage favors APIs, with no capital tied up in idle infrastructure. Ownership pays off when sustained demand keeps the hardware busy. Most enterprises, the company predicts, will run hybrid: frontier APIs for demanding or intermittent work, owned capacity for repeatable volume, with a governed gateway deciding what leaves the building.

The stakes extend beyond a single procurement decision. As developers lean harder on coding agents, usage will keep rising. The real choice, in HPE's framing, is whether that growth shows up as a bigger variable-cost bill or as more software shipped on capacity the enterprise owns. The companies that lead AI-assisted development will not ration adoption to control costs. They will build an operating model where more AI use improves the economics instead of undermining them.