Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI Agents and the Refactoring That Never Happens

rosenfeld.page

Post reply on HN
Print view View original

21–30 of 76 posts

Re: AI Agents and the Refactoring That Never Happens

#21

Post by joshka »

A lot of this feels like it comes down to the training of the agents to produce code that satisfies the various benchmarks combined with reactions to things which were previously maladaptive. I.e. things which were explicitly trained out of the model in post training. I think there's a lot of missing long term software engineering principles that don't seem to be baked into the way the models tend to write code by default.

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.

Re: AI Agents and the Refactoring That Never Happens

#22

Post by SoftTalker »

Kiro wrote: post #15
rafaelRiv wrote: post #7

Earlier quoted context omitted.

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.

If you were fortunate enough to be working in a project with very good test coverage, refactors were easier (maybe not easy) in the sense that you were at least fairly confident that nothing broke.

But I've personally never worked on code with test coverage that good. Refactors were always risky.

Re: AI Agents and the Refactoring That Never Happens

#23

Post by goldenarm »

_fat_santa wrote: post #18

I'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 o…

Reminds me of the "entreprise grade fizzbuzz"

https://github.com/enterprisequalitycoding/fizzbuzzenterpris...

Re: AI Agents and the Refactoring That Never Happens

#24

Post by odo1242 »

tunesmith wrote: post #20

Let'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…

I'd argue the things that make a codebase more human-readable is also what makes it more agent-readable though. Agents are trained on human data, after all.

The position in the article is reasonable because what would end up happening otherwise is:

- Agents increase complexity, humans can't read it anymore

- Agents increase complexity, agent can't read it's own code anymore

- Agent unable to keep making updates without looping forever (the complexity of the code exceeds the agent's context length). Human doesn't understand either so can't fix.

This isn't hypothetical either, it's basically what ends up happening to most vibe-coded software if the person doing the vibe coding doesn't know how to review the outputs being produced.

Re: AI Agents and the Refactoring That Never Happens

#25

Post by nijave »

joshstrange wrote: post #16

Meanwhile 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 _wan…

It's been fun reviving some abandoned personal/side projects and seeing them through. I have a bunch of random partially completed code that I never got around to finishing and it's fun seeing it work even if I have no use for it. Tons of "proof of concepts" left at "concept" that never reached "proof" ha

Re: AI Agents and the Refactoring That Never Happens

#26

Post by nottorp »

teaearlgraycold wrote: post #10
simonw wrote: post #5

I'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…

All sorts of efforts that used to be put off indefinitely can now be handled largely by LLMs. Yesterday I took a codebase (~50 source files) and spawned a sub-agent (GLM 5.3 Flash) for every single file. Each file was analyzed for test coverage issues, inconsistencies between comments and implementations, and all call sites against the implementation. Then issues were aggregated. I reviewed the list manually, had Opu…

> then had a commit made for every minor issue found

Interesting choice of words. Not a fix. Not a refactor. A commit.

Re: AI Agents and the Refactoring That Never Happens

#27

Post by nijave »

simonw wrote: post #13
rafaelRiv wrote: post #7

Earlier quoted context omitted.

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?

Gotta get IT to slip superpowers or at least the TDD skill into MDM/enterprise controls

Re: AI Agents and the Refactoring That Never Happens

#29

Post by nottorp »

moezd wrote: post #12

AI 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.

[dead]

Re: AI Agents and the Refactoring That Never Happens

#30

Post by TimTheTinker »

> The same modularity that keeps a system inside a human’s head keeps each change inside a well-defined boundary the agent can reason about reliably.

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?

Post reply on HN