For as long as teams have refactored code, the return was an argument made on trust. Cleaner code pays off eventually, in ways the budget never itemizes. Every senior engineer believed it. Almost nobody could put a number on it.
Coding agents changed that. You can now measure the ROI of refactoring directly: have a coding agent make the same change before and after the cleanup, and compare the input tokens it consumes. In one published experiment, that number fell 83 percent.
We watch this line item on client work. Convective runs agentic delivery on production systems, including ColdFusion and Rails applications with years of history, and token spend now shows up in the cost of every change.
How one experiment measured refactoring ROI
The clearest measurement so far compares the tokens one identical change costs before and after each refactoring step. On July 30, 2026, Giles Edwards-Alexander, Thoughtworks' CTO for Europe, Middle East and India, published a controlled experiment on the economic benefit of refactoring. His target was a 17,155-line Rust file that held the entire data access layer of an agent-built application.
Input tokens are the text a model reads and bills for, as distinct from output tokens, the text it writes. They are the number to watch here, because reading is most of what an agent does before it edits. The code it has to load to make one change safely is its read set.
The method is the part worth copying. After each refactoring step, he prompted a fresh agent to make exactly the same change, recorded the tokens, discarded the change, and refactored again. Agents do not 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.
The drop did not come from splitting files at random. It came from a structure that let the agent identify the smallest set of files it needed to read. Structure, not size, set the price.
Why a 40-cent saving is the number that matters
The dollar amount is small; the fact that it can be measured is what changes the refactoring argument. At the $3-per-million-token rate the author used, the saving on that one change was about 40 cents. It repeats on every future change that touches the layer.
The cost of working in badly structured code was always real when people paid it. It hid inside salaries, as time spent understanding code that nobody itemized. Tokens itemize it, on every change, in a unit the budget owner already reads.
The receipt also understates the cost. Thoughtworks principal engineer Rahul Garg argues that context an agent pulls in stays in its working memory and is carried into every later turn of the session. A bloated read set does not just cost tokens. It degrades the work.
One caveat, which the author makes himself: this is one experiment, on a greenfield application built and maintained by a single developer. Treat 83 percent as proof the effect exists, not a forecast for your codebase.
How to build the business case for refactoring legacy code
The business case is now a measurement your team can run, not an opinion it has to defend. This is how we set it up with clients:
Baseline one representative change. Choose a change your team makes often. Have an agent make it, record the input tokens, and discard the change.
Refactor the area, then rerun the same change. Use a fresh agent session each time. The difference is your saving per change.
Multiply by a year of changes. The result is a return figure a CFO can read without trusting anyone's instincts about code quality.
Track it like response time. Set a token budget per change and investigate when it creeps. A growing read set is the new creeping latency.
What the meter finds in older codebases
The meter finds every structural shortcut a codebase ever took, and it finds them on every change. In older ColdFusion and Rails applications, the file that does everything is a pattern we see often, and it is the same shape as the file in the experiment. We treat read-set size as a readiness input when we scope agent work, alongside test coverage and access.
The good news runs the other way. Cleanup that was hard to justify for years now pays back each time an agent touches the code. For the specific patterns that drive the cost, see five ways sloppy code inflates your AI coding bill. For the pipeline decisions around it, see why your AI bill is an architecture problem. Pricing that structure work belongs in the plan, and it is part of every AI readiness assessment we run.