I don't know, our backlog of refactoring, before AI, never really happened either.
I've yet to work at a place that bothered with much refactoring over adding the thirtieth conditional to new feature....
AI Agents and the Refactoring That Never Happens
11–20 of 76 posts
Re: AI Agents and the Refactoring That Never Happens
#12AI agents get lost all the time, particularly if the codebase is already sprawling out of control.
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.
Re: AI Agents and the Refactoring That Never Happens
#13I've found that access to coding agents has helped me be far less tolerant of bad code patterns that can be refactored. 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 ei…
And for me, it has created a giant pile of unmaintainable code from my coworkers because of stupid management people that think they can code. Refactoring was never a substantial amounts of time for me before llms. Before I could spot a potential refactor and refactor it in 20 minutes and less. Never abandon it. Just constant improvement to the point the previous tech startup that I was working for just drive from it…
Does that code at least come with tests?
Re: AI Agents and the Refactoring That Never Happens
#14[deleted]
Re: AI Agents and the Refactoring That Never Happens
#15I've found that access to coding agents has helped me be far less tolerant of bad code patterns that can be refactored. 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 ei…
And for me, it has created a giant pile of unmaintainable code from my coworkers because of stupid management people that think they can code. Refactoring was never a substantial amounts of time for me before llms. Before I could spot a potential refactor and refactor it in 20 minutes and less. Never abandon it. Just constant improvement to the point the previous tech startup that I was working for just drive from it…
I've never met a single developer saying refactors are easy. It's always a minefield.
In the only scenario where that could actually be true you wouldn't have coworkers creating unmaintainable code with LLMs now.
Re: AI Agents and the Refactoring That Never Happens
#16Meanwhile I'm over here refactoring as much as I can from years (or decades) of human-slung code. Turning the mess I either inherited, helped create, or built on top of into something clean and pristine might be my favorite LLM use. Same for personal projects, codebases that evolved over many years when I happened to have time that weren't kept quite as "clean" as I wish that finally been cleaned up.
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.
Re: AI Agents and the Refactoring That Never Happens
#17> Here’s the problem. AI agents are not bound by human context limits in the same way. An agent can read the tangled function, trace every caller, and make sense of the mess that would have stopped a human cold. It can add the next branch correctly, and the one after that, working confidently inside code that no human on the team fully understands anymore. They're not bound by the same limits but they're still bound…
They also very often do not actually read the fucking files! Even after specifying to „read in full the fucking files“. LLMs are so lazy, they take any shortcut they can.
Sorry, just thinking about it is reviving my frustration…
Re: AI Agents and the Refactoring That Never Happens
#18I've personally adopted doing multiple refactoring passes after any large code implementation done by AI. In pretty much any scenario where I'm adding code using AI, it's 1 turn to add the feature and and then another 4-5 turns to refactor and clean everything up.
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.
Re: AI Agents and the Refactoring That Never Happens
#19I've found that access to coding agents has helped me be far less tolerant of bad code patterns that can be refactored. 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 ei…
Do you work with other, potentially unmotivated devs/managers a lot? I wonder how much of this is an incentive issue. I don’t think refactoring itself is as much of an issue than working with 2-3 other engineers that DGAF and a manager who is only looking at LOC to determine who to promote.
But it also doesn’t mean these things aren’t problems, they’re obviously huge problems.
Re: AI Agents and the Refactoring That Never Happens
#20Let's say that tomorrow, due to an improved model or whatever, we realize that the most efficient form of code of an app - for an llm to understand and work with - is for it to be in one long spaghetti file.
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?