For thirty years, the business case for refactoring has been an argument about feelings. Developers said the code was getting harder to work with. Management heard a request for several weeks of engineering time that would ship no visible features. Both sides were right, and neither could produce a number. Refactoring stayed a faith-based investment, funded when there was slack and cut when there wasn’t.
That changed on 30 July 2026, when Giles Edwards-Alexander, Thoughtworks’ CTO for Europe, Middle East and India, published a controlled experiment that finally attached a price tag to code structure. The finding is straightforward: badly structured code costs more to change with AI agents, and the difference is large enough to measure, budget for, and justify.
TL;DR
- A Thoughtworks experiment on a 150,000-line AI-built application cut input tokens for a representative feature change from 159,564 to 27,360, an 83% reduction, purely by refactoring one oversized file.
- The refactored file shrank from 17,155 lines to 3,695, split across 19 files, while total lines in the data layer stayed roughly flat at 16,500. This was reorganisation, not deletion.
- GitClear’s 2026 data shows the industry moving in the opposite direction: refactoring fell from 21% of changed lines in 2022 to 3.8% in 2026, while copy-paste rose to 15.7% and block duplication hit an all-time high.
- Token cost is a proxy for comprehension cost. The structure that makes code cheap for an agent to change makes it cheap for a human to review, and review time is where the real money goes.
- Agents can execute refactorings competently but cannot reliably choose them. Architectural judgement remains a human responsibility.
The experiment that put a number on it
Edwards-Alexander built a 150,000-line application almost entirely through AI agents, mostly Claude Code and Cursor. Along the way he ended up with a familiar artefact: a single Rust data access file that had grown to 17,155 lines. Rather than simply tidying it and moving on, he designed a measurement.
First he established a baseline by asking an agent to implement a representative feature change against the unrefactored file, recording input tokens, output tokens, execution time and lines of code. Then he applied fifteen refactoring steps in sequence, planned according to Martin Fowler’s catalogue. After each step, a fresh agent with no prior context implemented the identical change, and the same metrics were captured.
Input tokens fell from 159,564 to 27,360. That is 132,204 tokens saved on every subsequent change to that module, roughly forty cents at current Sonnet 5 pricing. The largest file dropped to 3,695 lines and the data layer ended up spread across 19 files. Critically, the total line count barely moved. Nothing was deleted. The code was simply arranged so that a change to one concern no longer required reading everything else.
Why structure drives token cost
The mechanism is not mysterious. An agent working on a codebase reads before it writes. When the relevant logic sits in a 17,000-line file, the agent pulls the entire thing into context to make a twenty-line change, because it has no way to know in advance which two hundred lines matter. When the same logic lives in a focused 400-line module with clear boundaries, the agent reads three small files and stops.
This is the part worth sitting with: token consumption is a measurable proxy for comprehension cost. The property that makes a codebase expensive for an agent to navigate is precisely the property that makes it expensive for a human to navigate. We have spent decades asserting that connection without evidence. We now have a meter on it, and the meter produces a number in euros.
The industry is heading the wrong way
The timing is uncomfortable, because the aggregate data shows teams doing the opposite of what this experiment recommends. GitClear’s 2026 analysis of commit data found refactoring collapsed from 21% of changed lines in 2022 to just 3.8% year to date in 2026. Copy-paste rose from 9.4% to 15.7% over the same period, making developers roughly five times more likely to duplicate code than to restructure it.
The structural signals are worse. Block duplication climbed 81%, from 40.3 duplicated lines per million changed lines in 2023 to 73.0 in 2026, the highest level on record. Cross-file function calls fell 35%, from 343 to 223 per thousand changed lines, meaning new code increasingly ignores what already exists. Most telling of all, updates to code untouched for twelve months or more collapsed 74%, from 1.7% to 0.46%. Teams are building new rather than tending existing systems, at scale, everywhere.
Set those two findings side by side. Refactoring has never had a clearer economic justification, and it has never been practised less.
Doing the sum for your own codebase
Forty cents per change sounds like rounding error, and taken alone it is. A module touched two hundred times a year saves eighty euros. Nobody restructures a data layer for eighty euros.
The API invoice is not the point. Token cost scales in three directions that genuinely hurt. Latency: larger contexts mean slower runs and more retries on long-running agent tasks. Accuracy: agent reliability degrades as the context window fills, so oversized files produce more wrong answers, which produce more review cycles. And humans: every engineer who opens that file pays the same comprehension tax, in the one resource you actually cannot buy more of.
Edwards-Alexander estimated an upper bound of five million tokens for the refactoring work itself, spread across roughly eight hours that were mostly unattended. That gives you something the industry has never had: a payback period you can calculate before committing. Refactoring stops being a tax on delivery and becomes an investment with a break-even date.
A practical playbook
- Find your hotspots. Cross-reference change frequency from your git history against file size. The expensive files are not the ugliest ones, they are the large ones you touch every sprint.
- Measure a baseline. Give an agent a representative change against the current code and record the input token count. This takes twenty minutes and gives you a number to argue with.
- Plan the refactoring yourself. The experiment’s most important caveat is that Claude could not look at the code and determine which refactorings were appropriate. A human had to direct every step. Agents execute structural change well and choose it badly.
- Script the mechanical work. Edwards-Alexander used Python scripts with grep and sed for rote transformations. For predictable, repetitive moves this is cheaper and considerably more reliable than an agent.
- Re-measure after each step. If the token count for your representative change did not fall, that refactoring did not buy you anything. Stop and reconsider.
- Set structural guardrails in CI. Maximum file size, duplication thresholds and import fan-in limits turn a one-off cleanup into a standard that holds.
The honest caveats
This is one greenfield application, in one language, measured against one class of change. It does not tell you what happens to a twenty-year-old brownfield monolith, where the potential saving is probably larger and the cost of getting there certainly is. The author is explicit that broader research is needed across more complex changes and wider refactoring strategies.
Treat the 83% figure as directional rather than as a benchmark you should expect to hit. The genuinely valuable output here is not the number, it is the method. It is reproducible, it takes an afternoon, and you can run it against your own worst file this week.
What we take from this
The teams that will pull ahead over the next eighteen months are not the ones generating the most code. They are the ones whose codebases stay cheap to change as they grow. AI has made writing code close to free and made understanding it the binding constraint. Structure is how you buy down that constraint, and for the first time you can show finance the receipt.
At REPTILEHAUS we spend a lot of our time on exactly this problem: auditing codebases that grew faster than their architecture, restructuring them so that both agents and engineers can work efficiently, and putting the CI guardrails in place so the gains hold. If your team is shipping quickly but finding every change harder than the last, that is a measurable problem now, not a matter of opinion. Get in touch and we will help you put a number on it.
📷 Photo by Barn Images on Unsplash
