AI Agents and the Refactoring That Never Happens

This summer I spent quite a while using a coding agent to help me untangle a deep and complicated data processing pipeline. It had itself been built by agents, in a remarkably short amount of time. But it had also become clear that it was riddled with errors and was producing lots of bad data.

What I quickly discovered was that upwards of half of my questions would receive very confidently wrong answers. And even once I had finally diagnosed whatever problem I was currently working on, it was difficult to trust the agent with any bug fixes. Since it was having an even harder time tracing data flows than I was (I'll take this chance to submit for your consideration that faster is not necessarily better), it was proving to be a bit of a monkey's paw. Yes, it would fix the exact bug I asked it to fix, but typically introduce new defects in the process. And yes, I was having this struggle with all of the latest & greatest models.

I ultimately concluded that, in this codebase, the agent was indeed deeply, hopelessly lost. (edit: And probably this code got so bad in the first place because the agents that were used to build it had been lost for a while, but unable to recognize this problem and call their operators' attention to it.)

I've always _wanted_ my code to be clean and easy to follow but life, deadlines, shifting-priorities, etc have stood in the way of that. Now I can finally realize my personal nirvana.

That said, I've had to steer models away from too-heavy of abstraction or similar because it made the code too hard to follow.

Refactoring used to have a very real cost - it was substantial amounts of time that would have to be carved away from working on new features.

Now I can spot a potential refactor, fire off a prompt in an asynchronous coding agent (or on a worktree or whatever), then come back 20 minutes later and either accept it, poke it a bit, or abandon it. Costs me almost nothing.

I have some speculation that maybe the people doing the model post-training tend to be younger researchers that haven't worked on large complex software systems, so their taste isn't as developed in this regard about what things are important here.

But this is an area that can be steered with appropriate early instructions ("When choosing tradeoffs of implementation, build for long term maintainability and understandability of code over implementing just the exact code necessary to solve the issues. etc. chain of thought often includes information that would have to be repeated in a future agent session, make sure to persist it to code or external docs so that future sessions and user understanding is respected.")

It can also be done as a post-change step with similar effects. And you can use your agents to build this layer into your general modus operandi for dealing with the crimes of generated code. But one of the things that all AI labs should be doing is looking at AGENTS.md on real project as being hard expressions of what failure modes real projects have noticed in models generally. Don't wait fo the bugs to be raised on these things, use express preferences that show that there's a problem. Go trawl github for these in bulk to use for future post-training.

Not only that. Good modularity also:

- improves code reusability, reduces unnecessary code duplication

- helps agents and engineers make better data model, data structure, design pattern, naming, and algorithm choices

- surfaces incorrect irregularities or outdated exceptions to a rule

- enables clean, independent upgrades of parts of a system to improve performance

- reduces stale references in code and comments (and the confusion that results, both from agents and humans)

Bad modularity is basically a summary of what usually constitutes pathological code in general, but AI systems seem particularly disposed to sling lots of it (at least humans are constrained in their output rate). How often have you tried to grok an AI-built project and found trivially unreusable code, unnecessary duplication (everywhere!), bad data structure and algorithm choices, and stale references?

Your discipline only pays off if you already understand your code and/or established clear baseline for your standards before launching into a feature development mania. And it needs to be enforced every turn, or the firehose of code generation knocks the front door down easily.

Thats… not my experience. Like, not at all. They very regularly get lost

They're not bound by the same limits but they're still bound by some limits, yeah?

I'm not an AI expert, so I don't honestly understand why LLM driven agents are as good as they are. But my impression is "trace every caller", most of the time, is still an approximation. Once the code has gotten convoluted enough, cases are going to get dropped.

I find it hard to read articles where the agentic writing is this obvious. It's a distraction from the message of the text, which I'm sure is worth my time. Is there no way to stop generated writing from sounding like this?

As ever, no one is willing to allocate time for this, but (with unlimited work tokens) I can parallel path massive cleanup refactors all the time now.

Often times it's not even that the code is bad but rather that it's overengineered. I see it happen so much that I'm tempted to actually go the other way on a toy project. Like what would Claude or Codex come up with if I told it I wanted an enterprise grade, globally scalable, compliant and auditable tic-tac-toe game.

Why wouldn't we do that? I think there's a point where this comes down to values instead of facts. If you want it to be human readable, that's fine and there are a bunch of therefores from that point. But if you don't necessarily want that for a particular codebase, why refactor if the LLMs can handle it?

I've yet to work at a place that bothered with much refactoring over adding the thirtieth conditional to new feature....

That's a bit of a straw man. State of the art agents are limited to ~3.8Mi (1M tokens). That's usually where I run into issues--an LLM can't possibly hold as much context as a human and it's more of an art than a science getting the most important things squeezed in. It's especially prudent for complex codebases/systems.

An agent only knows what it can see. It doesn't know oldCruftyFunction is still critical to Bob's Excel macro that generates financial reports and yanks the codebase in as a bastardised dependency. A lot of times agents give a fall sense of security by making it seem like something complicated and unsafe is actually safe.

They were trained to do what you ask, but unlike with humans, you need to ask for the refactoring yourself. -- They won't necessarily come up with it on their own.

(They also tend to not be around for long enough to live through the consequences of their tech debt actions.)