Being a bit cheeky here -- the amount of comments on this post is a telltale sign of how common / desirable refactoring is for the majority of developers (xD). It isn't our fault though, maybe if those pesky managers read this article then they would understand..

It’s interesting that cyclomatic complexity or cognitive complexity scales with token usage. A codebase that enforces upper bounds on one of these two also (potentially) helps AI agents stay efficient.

Interesting take-away:

> Claude is unable to look at code, look at refactorings in general and work out which are suitable to apply: a human needs to actively guide it.

Claude is happy to produce a very large Rust file. But you need human guidance to make it smaller.

the punchline: "Refactoring reduces token consumption"

I appreciate the effort to quantify the benefit rather than pontificate. It's worth mentioning Martin Fowler wrote a whole book on refactoring [1], in which he states, "to refactor, the essential precondition is [...] solid tests", which I think is the real benefit here, AI or not. Good tests protect against regressions, whether human or robot. They also help encode the spec, which humans and robots can read.

[1] https://www.oreilly.com/library/view/refactoring-improving-t...

It's very interesting to have some data on this.

It matches my experience which is that LLMs greatly benefit from well factored code, but are not particularly adept at creating such code.

Much like most human developers I suppose!

Interesting that the amount of code essentially remained unchanged. In my experience it is not unusual that refactoring messy code cuts the number of lines in half.

I have been enforcing this myself through AGENTS files and other explicit instructions. What’s crazy is that none of the existing coding harnesses include such instructions by default. Two lines in Claude Code and Codex and the entire world would be writing better, more efficient code. Makes me believe in the conspiracy that these companies want more verbose code and longer files because it directly results in higher token usage.

Make it work, make it right, make it fast, in that order

Make it right is the refactoring

I think this is one of those things where a human in the loop is indispensable

An agentic refactoring pass does make sense cause one LLM reviewing work can spot things the ‘generator’ LLM missed while focused on the initial task output

But can the reviewer agent ever actually have in mind what this project actually is? And how the code all comes together to do the work involved? In other words what parts of the code are redundant or can be made more elegant

Asking coding agents to refactor your codebase is maybe like asking trauma surgeons to increase your exercise capacity. The agents are gonna need a really holistic POV to do this properly

I guess part of my point is that just splitting big files into multiple files is only refactoring in a superficial sense without having a theory of what code belongs together and what can be extracted into utility functions etc

Opus/Fable 5 (or really, any thinking model) do a better job of refactoring than Sonnet would. I think the takeaways are still valid, just not as valid when using a more expensive model at a higher effort level.

The benefits go beyond reducing token consumption. Compact contexts also foster better reasoning, enable intelligence across more layers if you can load them in a single context, and writing software to enable this, results in more correct software, software that _generalizes_, that has higher probability of being correct not just for tested cases, but for the interpolations and extrapolations of these cases.

Refactoring towards good abstractions is more powerful than people realize. There's information theoretic bayesian math to back this up.

It's a bit of a divine coincidence that software that is more economically and energy efficient to process and run tends to also be more correct.

It's all about reducing the entropy of your code. https://benoitessiambre.com/entropy.html