AI made code cheap. Rework is where the money goes.

The agent that wrote the bad pull request cost a few dollars. The senior engineer who spent Tuesday morning untangling it cost several hundred. Nobody puts those two numbers on the same spreadsheet, and that’s most of the problem.

When people work out what an AI coding programme costs, they look at the invoice from the model provider. It arrives every month, it’s easy to find, and it’s usually the smallest cost in the whole thing. I’ve built payments and trade-finance systems for long enough to recognise the pattern. The visible cost is the one you optimise. The expensive one sits in someone’s calendar, where finance never looks.

So this is my attempt to put the hidden costs on the page.

Three costs that don’t show up on the invoice

The first is rework. An agent writes code, a person reads it, and the person decides it’s wrong in a way that matters. It misunderstood a constraint. It introduced a pattern the team will spend months unpicking. It solved the problem in the ticket and broke something the ticket didn’t mention. So the person rewrites it. That isn’t really the model failing. It’s the system around the model failing to carry context: what “acceptable” means for this codebase, this team, this set of rules nobody wrote down.

The second is proving what happened. In any regulated setting, every change eventually has to be defensible. Someone has to be able to tell an auditor what changed, when, why, and who approved it. In most setups the raw material exists (logs, timestamps, commit messages), but a coherent record of what the agent decided and on what basis does not. So someone reconstructs it by hand. In a bank or a hospital that can take days for a single significant change. The inference that produced the change cost a dollar.

The third is integration. Agents mostly work at the level of a file or a function. They don’t know that changing this API signature breaks three downstream consumers, or that this data model change has a migration path someone in compliance cares about. The cost is the engineering time spent finding what broke, often weeks later.

Add those up and the inference spend starts to look like a rounding error. There’s plenty of commentary going round this year putting a precise figure on how much AI coding spend goes on fixing and redoing work. I haven’t seen a source I’d stake a number on, so I won’t quote one. The direction matches everything I’ve seen.

Why better models don’t fix this on their own

The comfortable answer is that models will improve, context windows will grow, and the agent will eventually just understand. Models are improving. I don’t think that closes the gap.

Most rework isn’t about capability. It’s about what the system knows and what it can prove. A stack assembled from a good orchestrator, a vector store, a Git integration and a monitoring dashboard has a structural limit, because none of those parts were built to know each other’s state. The memory store will happily return context that was true six months ago. The Git integration commits with a human’s token, so the record of which agent did what, under whose authority, is gone at the first step. When output fails review, the system has no general way to learn why. It produces more output. The cycle repeats.

None of that is a criticism of the individual tools. They’re good at what they were designed for. It’s what happens when you try to govern something built from parts that weren’t designed to be governed, which is the argument of the missing 80 percent.

Assistant economics and factory economics

There are two ways of using agents and they have very different cost structures.

In the assistant model, a developer works alongside an agent and reviews everything it produces. The developer is the quality gate, the audit record and the budget all at once. This works well and the productivity gains are real. The economics look great too, because the rework and checking are absorbed into the developer’s normal day and never appear as a separate line.

The trouble starts when you scale past one person’s attention. Once agents produce more than anyone can read line by line, the rework and checking don’t vanish. They land somewhere. Either the system around the agents handles them as part of how it works, or they turn up later as a large, surprising cost that someone has to explain.

That’s where I’d bet the money goes over the next few years. Writing software has become cheap. Shipping it, running it and being able to trust it is where the cost now sits.

Routing is an economics decision

One lever matters more than it looks: which model does each step.

The common pattern is to pick a model capable enough for the hardest task in the workflow and use it everywhere. It’s safe and simple, and it means paying frontier prices to draft a list of subtasks. The opposite mistake is running everything on something small and cheap and getting the security-sensitive step wrong.

The better pattern is to decide per step what’s good enough, and to let a budget set at the start constrain those choices. Most steps in a typical piece of work don’t need the most capable model. A few really do. I wrote more about setting the budget up front in declare the mission and the budget.

The failure mode this prevents is the interesting part. A team runs a careful, cost-aware pilot, then gradually moves everything to the biggest model because it’s less hassle, and discovers at scale that costs are no longer under control. A budget that’s enforced, rather than reported, stops that drift.

Where the regulated cost really sits

In regulated work, the checking often costs more than everything else put together.

Take a trade-finance evidence pack, one of the most document-heavy processes in banking. Someone works through a stack of documents, pulls out counterparty and transaction details, runs them against sanctions and policy rules, flags exceptions to an analyst, and assembles a pack that gets signed off. The audit trail is put together at the end, by hand.

Now add an agent that does the extraction quickly but doesn’t record where each fact came from or why it flagged what it flagged. The typing gets faster. The review doesn’t, because the analyst can’t trust anything they can’t trace and ends up checking every line. You’ve made the cheap part cheaper and the expensive part more expensive.

The version that actually saves money is one where the record of the work comes from doing the work. Every step attributable, every decision traceable, so the analyst spends their time on the exceptions that need judgement instead of re-reading everything to check provenance. That’s the outcome we’re designing Kizuna and Voxeltron around: agents build under your rules with a record of every change, and what they build is deployed and run in a way you can account for. We’re still in development, so read that as intent rather than evidence.

Questions worth asking any vendor

If you’re evaluating platforms, a few questions get to the cost structure quickly.

If a regulator asks for the reasoning behind a change made ninety days ago, how long does the answer take, and who does the work? If a person has to reconstruct anything, the cost has been deferred, not removed.

Can the system show which agent made which change, under what permission, from the record itself rather than by stitching together logs from several places?

Is the budget enforced before a step runs, or reported on a dashboard after it has? Those are very different things, and cost governance before the invoice goes into why.

And what does checking cost per unit of output at scale? Most teams can’t say, because the checking is spread across reviewers and nobody tracks it. If you can’t measure it, you can’t tell whether agents are saving you money or just moving the cost somewhere quieter.

Measuring it in a pilot

If you run a pilot, don’t measure whether the agent can do the work. It can. Measure whether the economics hold.

Pick one workflow where you know the current cost per unit. Run it with agents. Track the total cost per unit (inference, review time, compliance time and revision cycles together), the revision rate and the reasons behind it, and what happens when you deliberately set the budget too low. If revisions keep coming back as “couldn’t tell where this came from”, that’s a structural gap, not a model problem. If inference got cheaper and the reviewers are working twice as hard, you’ve found a faster way to make the same mess.

If you’re working through this in your own organisation, we’d like to hear from you.