For as long as refactoring has existed, its return on investment was an argument you made on trust. Cleaner code pays off, eventually, in ways the budget spreadsheet never quite captures. Every senior engineer believed it. Almost nobody could price it. That just changed, because coding agents pay by the token to read your code, and how much they have to read is set by how the code is structured.
We watch this line item on real work. Convective runs agentic delivery on production client estates, and token spend now shows up in the cost of every change the way compute bills showed up a decade ago.
Someone finally measured it
A Thoughtworks CTO ran a controlled experiment on the economic benefit of refactoring in an agent-built application. The target was a 17,155-line Rust file holding an entire data access layer. The method was tidy: prompt a fresh agent to make exactly the same change after each refactoring step, record the tokens the attempt consumed, throw the change away, and refactor again. Agents never learn between runs, so every attempt started cold.
Input tokens for the identical change fell from 159,564 at baseline to 27,360 after the final step, an 83 percent drop. The saving repeats on every future change that touches the layer. And random file-splitting was not what did it. The tokens fell because the new structure let the agent find the smallest set of files it needed to read. Structure, not size, set the price.
Why the number matters more than the amount
At current model pricing the saving on that one change was about 40 cents, which sounds like a rounding error. Wrong lens. What matters is not the size of the number but that the number exists. The cost of working in badly factored code was always real when humans paid it; it hid inside salaries as comprehension time nobody itemized. Tokens itemize it. Every change now produces a receipt, and the receipt is legible to the same budget owners who used to wave refactoring off as engineering perfectionism.
The receipt also understates a second cost. Everything an agent reads competes for its attention, and as a Thoughtworks engineer argues in a piece on orchestration costs, polluted context keeps charging rent for the rest of the session. A bloated read set does not just cost tokens. It degrades the work.
One caveat, which the experiment's author makes himself: this is a single experiment, on a greenfield application, by one developer. Treat the 83 percent as an existence proof, not a benchmark for your estate.
What this changes for a legacy estate
- Refactoring gets a business case denominated in dollars. Pick a representative change, measure the input tokens it costs today, and measure again after cleanup. That number, multiplied across a year of changes, is a return figure a CFO can read. No trust required.
- Structure becomes a readiness question. An estate that forces an agent to read the equivalent of a novel to change one query is not ready for economical agentic delivery, whatever the pilot demo suggested. We treat read-set size as an input when we scope this work, alongside tests and access.
- Cost engineering joins the delivery discipline. Token budgets per change are worth tracking the way response times are: continuously, with a threshold that triggers investigation. A creeping read set is the new creeping latency.
The uncomfortable part for older estates is that the meter finds every structural shortcut ever taken, and it finds them on every single change. The good news runs the other way too. Cleanup that was impossible to justify for years now pays a measurable dividend each time an agent touches the code. If you are planning agentic delivery on a system with history, pricing that structure work belongs in the plan, not in the surprise column. It is one of the first things we look at in our AI implementation framework.