Why Does the Engineering Bill Keep Going Up?

Falling model prices tell only part of the story. I asked Oxagile’s AI Innovation Lead what actually happens to the cost once AI starts working inside a serious engineering organization.

Nobody shops for cheaper fuel when the problem is the route. Yet that is roughly how most organizations approach the cost of AI-assisted engineering: they compare model pricing, watch the per-token rates fall quarter after quarter, and conclude that the economics are heading in a comfortable direction. Then the invoice arrives, and it is larger than the one before it, and the one before that.

The story that AI makes engineering cheaper is not wrong. It is true inside a fairly specific envelope. But it stops being true outside it, and almost nothing in the public conversation tells you where the boundary is.

Such a story is incomplete in a way that costs money. The variable that decides the bill (how the work around the model is designed) gets discussed far less than the model itself.

I took the question to Alexey Karankevich, AI Innovation Lead at Oxagile, who confirmed that a cheaper build starts with an honest bill.

Where “cheaper” holds

On a small codebase, agents are genuinely transformative, and it is worth being unambiguous about that before complicating it. When the whole relevant context fits comfortably in front of the model, the task is specified clearly, and correctness can be settled by a test instead of a conversation, the economics are not close.

My first question went straight to the point.

Where does AI really make engineering cheaper?

Alexey replied the following: “Scaffolding, rule-driven migrations, test generation, the boilerplate that senior engineers resent, this work got dramatically cheaper, and it is not going back. The boundary shows up somewhere else, and it has little to do with model capability.”

Where “cheaper” quietly stops

Large legacy systems that carry rules nobody wrote down are a common example. That could be a settlement path with an exception that exists because of a regulator's letter in 2019, a service that cannot be safely retried for reasons that live in one person's memory, or a schema that looks redundant and is in fact load-bearing.

I asked Alexey what changes once an agent starts working inside a system like that.

He explained: “An agent will produce confident, well-structured, entirely plausible code against all of it. But someone still has to know whether that code is right. And on systems of consequence, that someone is a domain expert whose time was expensive before any of this existed.”

Legacy complexity is only one reason the “cheaper” equation breaks down. High-scale and distributed systems put a different kind of pressure on the same economics. Code can be functionally correct and still fail under production traffic, introduce latency in a critical path, create concurrency problems, or make an already expensive workload harder to operate. Here, the value of agents may come from increasing engineering capacity or compressing delivery time.

The senior engineer is still in the bill

What changes is not the price of that expertise but the shape of their day. Less typing, more specifying, reviewing, and correcting. Often that is a good trade, and teams that make it deliberately do well. But teams that budgeted as though the expert had been removed from the equation are the ones who end up explaining an invoice.

It got me thinking.

Does AI truly reduce the amount of senior engineering work, or does it just move that work somewhere else?

The expert told me: “On a small project, the agent is doing the work. On a large one, it is producing candidates and some senior engineer is deciding whether they are right.

That second job never got cheaper. People look at the volume of output and assume the engineer has less work to do. What actually happened is that all of the reviewing moved to the front of their day.”

What lands on the invoice, and what doesn't

Hard numbers on the actual cost of AI software engineering are scarce in this conversation, mostly because organizations treat their consumption as commercially sensitive.

For teams that have made AI agents part of everyday engineering work, the working band runs from a few hundred to several thousand dollars per engineer per month (reaching hundreds of thousands in rare cases).

What explains such a huge difference in spend?

Alexey pointed to the gap itself: “The endpoints matter less than the distance between them. Two engineers can end the month with wildly different bills, and the difference is rarely explained by seniority or how enthusiastic they are about the tooling.”

The task and the workflow around it explain much of that difference. Contained feature work in a well-organized repository is near the bottom of that band. Multi-step agentic work against a large, thinly documented legacy system is near the top, and gets there without anyone doing anything wrong.

Why AI budgets need quotas

That variance is why internal quotas, typically a monthly AI spend or consumption allowance assigned to each engineer, appeared as quickly as they did.

It is tempting to read a quota as cost-cutting, and occasionally it is. So should an AI quota be treated as a spending cap, or as instrumentation?

Alexey commented on this: “A monthly organizational total tells you nothing you can act on. It cannot be traced back to a decision, so it cannot be improved, only worried about.”

Breaking consumption down by engineer puts the number closer to work someone can look at. That is, where the spending happens, where a heavy month can be traced to the tasks and workflows that caused it. Organizations do not bother metering things that are cheap.

My question, therefore, is: are quotas really there to control spending?

Alexey was straightforward: “A quota is not there to stop anyone from spending. It is there so that when a month looks strange, you can ask one person what they were working on and actually get an answer. Before quotas, we had a total and no way to explain it. That is not a budget problem, it is a blindness problem.”

What does “expensive” mean then?

“Cheaper” is bounded when discussing the cost of AI software engineering. Agents collapse the cost of contained, well-specified work with mechanically verifiable output. On systems where a domain expert has to own the result, the cost moves from writing code to specifying and reviewing it. It does not disappear.

The workflow sets the bill, with model choice playing a significant part too. Context engineering, task decomposition, development practices, and infrastructure decisions such as caching policy separate comparable runs on the same model by an order of magnitude.

And there is a much bigger number behind this conversation. In May 2026, one company spent about $165,000 in inference to rewrite half a million lines of code in eleven days. Was that expensive, or an extraordinarily good deal?

That was one of the questions Alexey answered in one more interview, along with what the API bill leaves out, why two agents using the same model can differ significantly in cost, what happens when an agent hits its budget, and why cost per successful outcome tells you more than cost per token.

Built With

• ai