Man wearing a black cap, round glasses, and a dark green t-shirt standing with hands on hips against a wall with vertical black slats illuminated by teal and purple lights.

Your AI bill is a flow problem, not a finance problem

Many teams now have a number they can't explain. It shows up on the cloud invoice or in the AI vendor portal. It is bigger than they planned for, and it moves around in ways nobody quite predicted.

The instinct is to send the number to finance. Finance asks for a forecast. Engineering builds a dashboard. A FinOps lead gets hired. The dashboard is correct. The number keeps moving.

That gap, between "we can now see the spend" and "we can now control it", is practical work for Delivery Managers in 2026. The reason it sits with delivery, not only with finance, is structural. AI cost is not just a budget line. It is a flow variable. And once you see it that way, the levers you already use for cycle time and WIP start working on the bill.

What the numbers actually say

The 2025 State of AI Cost Management report from Benchmarkit and Mavvrik surveyed 372 enterprises. Eighty percent miss their AI cost forecasts by more than 25 percent. Twenty-four percent miss by more than 50 percent. Only fifteen percent land within ten percent. Eighty-four percent report gross-margin erosion of six percent or more from AI infrastructure; for a quarter of respondents that erosion is sixteen percent or higher. Token costs rank fifth among the surprises. Data platforms and network access top the list.

Two caveats up front. Mavvrik sells cost-governance tooling, so the framing serves the sponsor. And these are self-reports, not audited financials. Read the numbers as "the market admits it can't forecast its own AI bill", not as a precise causal claim. Even with that discount, the spread is real.

The DORA 2025 State of AI-Assisted Software Development report adds the structural reason. Drawing on around five thousand survey responses and over a hundred hours of interviews, DORA's central finding is that AI is an amplifier: throughput and product performance improve where engineering systems are mature, and delivery stability deteriorates where they are not. Roughly nine in ten developers use AI; about two-thirds rely on it heavily. The result is that the same code review queue, the same scope discipline, and the same platform now sit underneath much higher volume.

Put the two findings next to each other. You get an environment where:

  • spend is variable and undermeasured,
  • volume is higher than the system was designed for,
  • and the people closest to the spend decisions don't always know they are making them.

That makes it a delivery problem before it becomes a finance problem.

Why the standard answers stall

The standard answers are useful and incomplete. Token budgets at the runtime layer stop the worst loops, such as an agent that keeps regenerating until the bill is visible. Observability dashboards make spend visible. Both work. Neither tells you whether the work that consumed the spend was worth doing.

Donald Reinertsen has been making the underlying point since 2009. In Principles of Product Development Flow, he argues that variability, queues, and batch size dominate the economics of product development, and that "cost" is not a single number on a budget line but a distribution that compounds along the queue. A recent arXiv preprint on the economics of LLM inference arrives, from a completely different direction, at the same shape: there is an optimal cost-effectiveness zone, not a direction. Bigger model, longer context, more agents. Past a point, each makes the bill grow faster than the value.

The Delivery Manager's job is to push the cost decision upstream, where the work is shaped, instead of catching it at the bottom of the invoice.

Four things to add to a flow audit

If you already run a Reinertsen-style flow audit, AI cost slots in cleanly. Four additions are enough to start.

1. Tag cost to the change. Log token spend per merged pull request. Pair it with PR size, rework rate, and review queue age. The point isn't a precise unit-economic model. The point is that "cost per outcome" stops being a quarterly conversation and becomes a weekly signal. The useful pattern to look for is skew: a median PR that looks fine while the top five percent eat the budget.

2. Set stopping rules for agentic work. The runaway-loop pattern documented across multiple practitioner write-ups is a queueing pathology with no natural stopping rule. Per-task step and token ceilings, with automatic escalation rather than automatic retry, are the operational analogue of a WIP limit. They aren't governance theatre. They are a flow constraint with a price tag attached.

3. Tighten intake. Scope creep multiplies AI spend the way it multiplies dev time, only faster, because each unclear acceptance criterion now buys more attempts. The cheapest cost control is a one-sentence acceptance criterion that an engineer and a product owner agreed to before the agent started.

4. Run one "expensive change" review per week. Pull the five highest-cost-to-value PRs from the previous week. Read them as flow data, not as performance review. Where did the cost come from: agent retries, oversized batches, missing context in the prompt, missing tests so the model regenerated, scope creep? Each cause maps to an existing flow lever.

Do not throttle the wrong thing

The DORA data suggests teams with mature systems convert AI into real throughput, so blanket throttling would miss the point. The better move is to stop treating the bill as a separate IT line item that finance owns. Margin erosion of six to sixteen percent is not only an infrastructure story. It is a delivery story showing up on the wrong report.

A Delivery Manager who can move the AI cost signal up to PR-level, set stopping rules at the agent layer, tighten intake, and run a weekly review of the costly changes already has the core of a practical AI cost strategy. It is the flow practice they were already running, with one new variable wired into it.

The number will still move. It will move less, and you will know why.

Sources