Agent code can only be read and understood by agents. We’ve reached the point where people just can’t comprehend these giant code blobs.
Feature, bug or emergent property?
I don’t think the distinction matters as much as the reality.
We’re being locked into using the AI tooling bc the code was generated with AI tooling.
These giant files of doom were being generated by humans anyway and were very hard to work with. With LLMs it’s at last manageable or feasible to edit, refactor etc.
I honestly think LLMs are going to save us from ourselves as the codebases became too large and “messy” for humans to comprehend. (Mono repos of doom)
On a personal level these giant files are abhorrent but that’s just personal taste and I don’t think any of the Martin Fowler refactor/cleanup stuff is going to matter at all anymore. Kinda sad on some level.
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. Is splitting files actually like decomposing factors or is it like splitting a larger number into smaller numbers that still eventually get added together
I was able to largely refactor something that was going to take months in a week or so by being the narrating human in the loop.
It was helped by having refactoring experience and approaches to codebases by others, and in my case, being the original architect and being able to speak to the original and current intents, where needed.
This was using a less common, but capable and easy language for the LLM without a ton of dependancy brittleness to manage.. once the effort to remove javascript/python bias was in place, it became so powerful that once the lightbulb went on, it really got cruising.
The project was playing in the world of JSR-223 languages, where you could script in many popular languages, but it all got to run in the JVM, which was an environmental requirement.
Your take is outdated. Agents are excellent at refactoring now. If you told me what you wrote during an interview, that would be grounds to not continue.
It's very important that you are using coding agents with the latest frontier models and know exactly what it can't and can't do if you want to be hired in this market.
"Refactor this code spin up subagents" try that in codex.
I am currently working 3 remote jobs and one of the jobs require me to interview and hire other devs. I find it amusing how many are resistant and unwilling to use agentic coding.
The one's that don't use agentic coding seems to have the loudest opinions in the room but are not aware that they are being largely made redundant by engineers who do use agents.
lol - I guess, if I heard that in an interview that would be grounds not to continue.
"enhance"
fwiw codex is very good. arguably better than the sonnet equivalent (value-wise). I use both daily, professionally. And "refactor this code spin up subagents" is hardly an expert-level "I wouldn't hire you" flex.
The deferral of all agency as a product owner over to the stochastic-word-box-in-a-do-loop feels like the kind of thing that, if you mentioned you do that in an interview, would be grounds to not continue.
I've been budgeting myself explicit "slop removal" time. In fact I'm in it right now one window to my right here.
I still get a big win from AI on the net, but you do need to budget some time to clean up. I'm still on team "read every line".
In fact this is a case where I deliberately deferred some review because I was a blocker for another team. Now that I've got something to them I'm going back and I'm going to eat a bigger chunk of debt than I normally would, but it's worth it for unblocking the other team sooner. AI has made tech debt easier to take out, in all senses of that term.
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.
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.
Interesting that the amount of code remained essentially unchanged. In my experience it is not unusual that refactoring messy code cuts the number of lines in half.
I did not mean it as a metric but as an indicator what was wrong with the code.
- the code is essentially good but all is in one file, you split it up, lines of code stay the same
- the code is essentially good but lacks some structure, for a function that does five things directly, you extract the functionality into five functions and call them from the original function, lines of code goes very slightly up
But once the code is actually bad - code duplication, bad abstractions, inefficient language use, ... - I would generally expect the lines of code to significantly drop. What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code? It is certainly possible but at moment I am having a hard time comming up with a good example.
I don’t know. LOC to me is indispensable for certain refactoring goals in my opinion.
Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future.
Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this function needs to be refactored into something more robust.
But lines of code is a pretty decent metric of success for “trimming down and cleaning up” style refactoring, to me at least. It’s not everything of course, but it’s definitely an indicator.
A couple of days ago I split a single class which did 5 barely-connected things, where each of the 5 entry points had another 5-10 private helper methods (none of which were shared between entry points), into 5 separate classes which each do one thing - total number of lines went up (because they all have the same boilerplate import statements at the top), but being able to focus on one entry point and it's helpers at a time has made things much easier to work with
That's LOC in a single file, that's a bit different from total LOC as a metric.
Total LOC is a garbage metric. Things like reducing line count in specific files or components is a big benefit, but those lines are often moved, not dropped.
LOC can be one measure, but not always the sole or best ones.
Since LLMs are word generators, and have a propensity to generating words, they need to be shaped to understand simplest is best, more isn't more, and less isn't more always.
Trimming down and cleaning up could be formatting, standardization, commenting, or even some basic re-architecting that was overdue.
One of the biggest benefits of llms for refactoring I'm finding is reducing technical debt.
Can't agree more. Feels like LLMs are not able to understand your requirements at a high level and always add complexity by default. Really need a handbook to guide them to do those cleanups. Obviously they know the knowledge in their weights but they just don't know how to apply it.
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.
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.
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..
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.
Feature, bug or emergent property?
I don’t think the distinction matters as much as the reality.
We’re being locked into using the AI tooling bc the code was generated with AI tooling.
These giant files of doom were being generated by humans anyway and were very hard to work with. With LLMs it’s at last manageable or feasible to edit, refactor etc.
I honestly think LLMs are going to save us from ourselves as the codebases became too large and “messy” for humans to comprehend. (Mono repos of doom)
On a personal level these giant files are abhorrent but that’s just personal taste and I don’t think any of the Martin Fowler refactor/cleanup stuff is going to matter at all anymore. Kinda sad on some level.
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. Is splitting files actually like decomposing factors or is it like splitting a larger number into smaller numbers that still eventually get added together
It was helped by having refactoring experience and approaches to codebases by others, and in my case, being the original architect and being able to speak to the original and current intents, where needed.
This was using a less common, but capable and easy language for the LLM without a ton of dependancy brittleness to manage.. once the effort to remove javascript/python bias was in place, it became so powerful that once the lightbulb went on, it really got cruising.
The project was playing in the world of JSR-223 languages, where you could script in many popular languages, but it all got to run in the JVM, which was an environmental requirement.
https://en.wikipedia.org/wiki/Scripting_for_the_Java_Platfor...
It's very important that you are using coding agents with the latest frontier models and know exactly what it can't and can't do if you want to be hired in this market.
I am currently working 3 remote jobs and one of the jobs require me to interview and hire other devs. I find it amusing how many are resistant and unwilling to use agentic coding.
The one's that don't use agentic coding seems to have the loudest opinions in the room but are not aware that they are being largely made redundant by engineers who do use agents.
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!
I still get a big win from AI on the net, but you do need to budget some time to clean up. I'm still on team "read every line".
In fact this is a case where I deliberately deferred some review because I was a blocker for another team. Now that I've got something to them I'm going back and I'm going to eat a bigger chunk of debt than I normally would, but it's worth it for unblocking the other team sooner. AI has made tech debt easier to take out, in all senses of that term.
It is also pretty decent, in my experience, at being guided into how to fix tech debt. Some other people's experience varies: https://news.ycombinator.com/item?id=49035455 YMMV.
I've had some luck while refactoring by helping it shape how to refactor, which can improve how well factored code should look like.
Providing examples of well factored code can go a long way, even if it's an open source repo of what to do / not to do.
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
In all corners of our world and the universe at large, reducing entropy in anything can be thought of as “building.”
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...
- the code is essentially good but all is in one file, you split it up, lines of code stay the same
- the code is essentially good but lacks some structure, for a function that does five things directly, you extract the functionality into five functions and call them from the original function, lines of code goes very slightly up
But once the code is actually bad - code duplication, bad abstractions, inefficient language use, ... - I would generally expect the lines of code to significantly drop. What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code? It is certainly possible but at moment I am having a hard time comming up with a good example.
Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future.
Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this function needs to be refactored into something more robust.
But lines of code is a pretty decent metric of success for “trimming down and cleaning up” style refactoring, to me at least. It’s not everything of course, but it’s definitely an indicator.
Total LOC is a garbage metric. Things like reducing line count in specific files or components is a big benefit, but those lines are often moved, not dropped.
Since LLMs are word generators, and have a propensity to generating words, they need to be shaped to understand simplest is best, more isn't more, and less isn't more always.
Trimming down and cleaning up could be formatting, standardization, commenting, or even some basic re-architecting that was overdue.
One of the biggest benefits of llms for refactoring I'm finding is reducing technical debt.
In some projects, the code might not have much, or enough testing, or documentation/commenting.
Code is largely for others and the future if the creators of it want to move onto other projects.
Make it right is the refactoring
> 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.