When teams price an AI coding agent, they look at the bill: tokens consumed, dollars per month, cost per run. That number is real, and it is also the smaller half of what the agent actually costs. The larger half is invisible on any invoice. It is the engineer time spent unwinding output that looked finished and was not, redoing work the agent got subtly wrong, and cleaning up changes that passed a glance and failed in practice. Call it the rework tax. It is the difference between what an agent costs to run and what it costs to get a correct result, and ignoring it is how teams conclude an agent is cheap while their velocity quietly gets worse.
The rework tax is not a reason to avoid agents. It is a reason to measure them honestly, because a tool that is cheap per run and expensive per correct outcome is not a cheap tool. It is an expensive tool with a flattering invoice.
Cost per run is the wrong denominator
The instinct to measure an agent by what it spends per task is understandable and misleading. The thing you actually want is a working feature, and the token cost of producing a diff is only the cost of the first attempt at it. If that attempt is right, the token cost is the whole cost. If it is plausible but wrong, the token cost is a rounding error next to what comes after.
The right denominator is cost per correct, shipped outcome, not cost per generation. Under that measure, an agent that produces cheap diffs you have to redo is not saving money, and an agent that costs more per run but produces outcomes you can actually ship may be far cheaper in the only currency that matters, which is engineer time. We work through the full accounting in what an AI coding agent actually costs per feature, and the go-or-no-go version of the question in is an AI coding agent worth it.
Where the rework hides
The rework tax is easy to underpay attention to because it does not arrive as a line item, it arrives as scattered friction that never gets attributed to the tool.
Debugging plausible-but-wrong output. The costliest rework comes from the failure mode where code looks correct, passes review, and is wrong in one specific place. Finding that place is expensive, and it is expense the agent created but the engineer absorbs, uncounted. This is the direct downstream cost of plausible but wrong.
Re-specifying work the agent misread. When an agent builds the wrong thing from an ambiguous ticket, the fix is not just new code, it is the human time to notice, diagnose, re-explain, and re-run. That loop can cost more than writing the feature by hand would have, and it repeats every time the specification was thinner than the agent needed.
Unwinding changes that reached too far. A change that broke something elsewhere, across a boundary or out of dependency order, generates rework that includes the incident, the investigation, and the revert, none of which shows up as agent cost even though the agent caused it.
Reviewing more than you ship. Every diff that gets generated and then rejected or redone consumed review attention, and review attention is one of the scarcest resources a team has. Generation that outruns useful output taxes the reviewers even when nothing ships.
Why cheap generation can make rework worse
There is a perverse dynamic worth naming: making generation cheaper can increase the rework tax rather than reduce it. When a diff costs almost nothing to produce, the temptation is to produce more of them, accept them more readily, and check them less carefully, which is exactly the recipe for more plausible-but-wrong output reaching further before anyone catches it. Cheap generation without proportional investment in verification does not lower the cost of a correct outcome, it lowers the cost of an incorrect one and lets more of them through.
This is why the teams that get good economics out of agents are usually the ones that spend on checking. Cheap deterministic checks and real evaluation cost something up front and pay for themselves by moving errors from expensive-and-late to cheap-and-early. The rework tax and the verification investment are two sides of one ledger.
Reducing the tax
Lowering the rework tax is the same work as improving reliability, viewed through the cost lens.
Ground the agent so it makes fewer wrong assumptions. Verify output for truth and not just shape so wrong answers surface at a checkpoint instead of in production. Write specifications concrete enough that the agent builds the right thing the first time. Keep humans at the decisions where a wrong call is expensive. Every one of these reduces the volume of work that has to be redone, which is to say every reliability practice is also a cost-reduction practice, because rework is where the money actually goes.
The point is that you cannot buy your way out of the rework tax with a cheaper model. You reduce it by making the first attempt more likely to be correct and by catching the wrong ones early, and both of those are engineering, not procurement.
The honest limitation
Reducing the rework tax does not zero it, because some rework is intrinsic to building software with an imperfect tool, human or machine. Even a well-grounded, well-checked agent will occasionally produce something that has to be redone, just as human engineers do, and the investment in verification has its own cost that has to be weighed against what it saves. There is a point of diminishing returns where checking more costs more than the rework it prevents, and finding that point is a judgment call, not a formula.
The tax is also genuinely hard to measure, which is part of why it gets ignored. Token bills are precise and rework time is diffuse, so the honest comparison requires effort that the flattering comparison does not. That asymmetry is exactly why teams under-count it, and why deciding to count it at all is most of the battle.
Where this leaves you
The rework tax is the hidden majority of what an AI coding agent costs: not the tokens on the invoice, but the engineer time spent unwinding output that looked done and was not. Measuring an agent by cost per run instead of cost per correct outcome makes an expensive tool look cheap, and cheap generation without verification can make the tax worse rather than better.
This is why the economics we care about at Loopsfinity are the economics of a correct, shipped outcome rather than a cheap generation, and why verification is treated as part of the loop rather than an optional extra: the goal is a feature you can trust, because a feature you have to redo was never the bargain it looked like. The unpredictability side of cost is in cost surprise, the brownfield-fit side in greenfield bias, and the full failure map in why AI coding agents fail in production.