Refactoring as a token-cost lever: an experiment in Fowler's gen-AI series

In Fowler's exploring-gen-ai series, Giles Edwards-Alexander runs a small experiment: decompose a large function, and watch what happens to the token cost of AI-assisted changes. The lever refactoring gives you is now measurable in dollars.

In plain terms. In a new instalment of Martin Fowler's exploring-gen-ai series, Giles Edwards-Alexander runs an experiment: decompose a large function, then measure whether the token cost of subsequent AI-assisted changes actually drops. The interesting move is not the result - it is the method. The economic case for refactoring becomes numerically visible for the first time in a way an accountant would recognise.

Where this connects

The hype-fatigue-2026 thread has, so far, been carried by voices flagging that LLMs don't remove the hard part of programming - they redistribute it. Edwards-Alexander's piece adds a specific, measurable frame to that argument: velocity gains without cleanup show up on the monthly token bill, not just the maintainer's morale.

The measurement, not the moral

What matters in the experiment is the unit. Historically, "refactoring pays" was defended with change-lead-time, defect rate, or team velocity - all real, all noisy, all resisted at budget time. Token cost is different. It's a line item on a cloud invoice. If a well-decomposed module costs meaningfully fewer tokens per AI-assisted change than a monolithic one - because the assistant needs less context per turn - refactoring translates into a number a CFO already tracks.

Whether Edwards-Alexander's specific numbers generalise is beside the point. The methodological contribution is that the debate can now be run in tokens per change, not in vibes per sprint.

The failure mode, named

Which brings me to the pattern I keep seeing on client work: assistant-driven ossification. An LLM adds a feature to a module it doesn't model well. The feature works but doesn't fit - duplicated helper, escape-hatch conditional, private inverse of an existing utility. Tests pass. Three days later, the same assistant models the mess as ground truth and extends it. Compound over a quarter, and the assistant becomes both cause and preserver of the debt.

The Edwards-Alexander framing is useful because it gives ossification a bill. A module that is progressively harder for the assistant to reason about is a module whose per-change token cost climbs. That is a monitorable signal.

Under the hood: two gauges

Numbers I'd instrument on any AI-heavy codebase, borrowing the experiment's framing:

• Tokens per AI-assisted change, per module, tracked monthly. If it climbs while assistant usage climbs, ossification is running.
• Duplication ratio in AI-authored diffs. Cheap to compute with a code-similarity tool; a leading indicator of the token curve.

Neither is a report-upward KPI. Both are early-warning gauges.

Where the piece stops short

The experiment doesn't address the next honest question: when the refactor itself is delegated to an assistant, what stops an LLM "cleanup" from deleting something load-bearing. That research gap is real - and it's the reason I'd read the token-cost frame as a diagnostic tool, not an autopilot.

So what

For a lead: 15-25% of any AI-heavy sprint on explicit refactoring, treated as cost of goods, not slack. For a decider: discount reported AI velocity by the token-cost trajectory. Velocity that raises per-change tokens isn't productivity - it's displacement onto next month's cloud bill.