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

The Economic Benefit of Refactoring

martinfowler.com

Post reply on HN
Print view View original

111–120 of 132 posts

Re: The Economic Benefit of Refactoring

#111

Post by pydry »

seanmcdirmid wrote: post #87
Viliam1234 wrote: post #47

I find it funny how the best practices for programmers, ignored in most IT companies, get reinvented as the best practices for AIs. Boring: The documentation should be in code, not in external Word documents uploaded to the company SharePoint server. Exciting: The documentation for the AI should be in code, not in external Word documents uploaded to the company SharePoint server. Boring: You should give your develope…

It’s much easier to get your AI agents to do something consistently than it is to get your human colleagues to do it. Heck, personally we know these things are the right things to do, but we are just too busy and our minds wander to what we think our more productive uses of our time. That completely changes when it’s agents being instructed to do the work instead. The crazy thing is that it s looking like AI might be…

They'd be 10x better than us already if task tedium was the problem. It's design sense that they're missing.

I find that in the areas where people think that LLMs excel at coding and don't like doing manually it's usually because the human was inclined to slop out repetitive boilerplate and thought that was the only way. Tests are usually like this, sadly.

LLMs are definitely good at providing reams of duct tape (which is drudge work) to patch up those bits of the code base where the code sucks. The problem is that duct tape is not the most architecturally sound construction material.

Re: The Economic Benefit of Refactoring

#112

Post by friendzis »

Viliam1234 wrote: post #47

I find it funny how the best practices for programmers, ignored in most IT companies, get reinvented as the best practices for AIs. Boring: The documentation should be in code, not in external Word documents uploaded to the company SharePoint server. Exciting: The documentation for the AI should be in code, not in external Word documents uploaded to the company SharePoint server. Boring: You should give your develope…

The thing is, humans make do. Given lacking, outdated documentation somewhere on sharepoint, big picture revealed somewhere in passing at some meetings or water cooler talks, underprioritizing refactoring humans still deliver something even if at reduced quality and timelines.

AIs either execute extremely poorly or don't work at all without these. Decent engineering practices are suddenly a hard prerequisite with AIs, not just some longer term improvement.

On a related note, this is unironically good argument to integrate AIs into the workflow even if there's zero net benefit in your use case. It's a perfect excuse to bring the proper engineering practices in.

Re: The Economic Benefit of Refactoring

#113

Post by whazor »

Viliam1234 wrote: post #47

I find it funny how the best practices for programmers, ignored in most IT companies, get reinvented as the best practices for AIs. Boring: The documentation should be in code, not in external Word documents uploaded to the company SharePoint server. Exciting: The documentation for the AI should be in code, not in external Word documents uploaded to the company SharePoint server. Boring: You should give your develope…

There is a big difference pre and post AI, namely that humans have quite good long term context management.

But now that everyone is coding with AI, all agents need to acquire context every session. Thus the value of doing best practices is much higher and benefits are there immediately.

Re: The Economic Benefit of Refactoring

#114

Post by disgruntledphd2 »

dash2 wrote: post #102
sltr wrote: post #5

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 enc…

I think the real punchline was that the value saved was on the order of cents! > Every single change that touches the data access layer from this point forward now costs significantly less. > How much of a saving? Assuming Sonnet 5 pricing at the time of writing of $3/MTok, 39.7 cents. Now consider OpenAI's price drop, and open models, and consider that in the long run tokens will get cheaper. And think that the refa…

> I think the real punchline was that the value saved was on the order of cents!

If the agents can read less tokens in the future, and make changes more effectively then this would add up over time.

Re: The Economic Benefit of Refactoring

#115

Post by Garlef »

whazor wrote: post #113
Viliam1234 wrote: post #47

I find it funny how the best practices for programmers, ignored in most IT companies, get reinvented as the best practices for AIs. Boring: The documentation should be in code, not in external Word documents uploaded to the company SharePoint server. Exciting: The documentation for the AI should be in code, not in external Word documents uploaded to the company SharePoint server. Boring: You should give your develope…

There is a big difference pre and post AI, namely that humans have quite good long term context management. But now that everyone is coding with AI, all agents need to acquire context every session. Thus the value of doing best practices is much higher and benefits are there immediately.

and furthermore, codebases can reach a size where good patterns matter much much faster

(so through this mechanism, the pain of not refactoring becomes apparent more often)

Re: The Economic Benefit of Refactoring

#117

Post by the__alchemist »

jmartrican wrote: post #71

The author said that Claude was not good at refactoring. But the author was using Sonnet 5. I supect Opus 5 would have done a lot better at refactoring. It would have come up with a multstep approach, i suspect.

Opus 5 is old news and has lots of problems. Minuet 6.9 is the one to use, and fixes all the problems people have with LLMs.

Re: The Economic Benefit of Refactoring

#118

Post by CuriouslyC »

seanmcdirmid wrote: post #92
CuriouslyC wrote: post #90

Earlier quoted context omitted.

Not true. Python performance is actually pretty low, and Elixir, Kotlin and C# trounce it handily.

Do you have citations? Everything I’ve read have said they have an overwhelming bias to Python; eg https://arxiv.org/html/2503.17181v1 and https://arxiv.org/html/2505.13004v1

Agents love writing Python, but it turns out they're not amazing at it. https://autocodebench.github.io/

Re: The Economic Benefit of Refactoring

#119

Post by ukoki »

I have a blanket, unignorable 'files must be <= 1000 lines' lint for my Rust projects for exactly this reason. Exploring large files is _costly_ for agents, so it's much better to lean into the filesystem hierarchy to a greater extent than you would normally with a team of human developers.

Re: The Economic Benefit of Refactoring

#120

Post by weiliddat »

pydry wrote: post #111
seanmcdirmid wrote: post #87

Earlier quoted context omitted.

It’s much easier to get your AI agents to do something consistently than it is to get your human colleagues to do it. Heck, personally we know these things are the right things to do, but we are just too busy and our minds wander to what we think our more productive uses of our time. That completely changes when it’s agents being instructed to do the work instead. The crazy thing is that it s looking like AI might be…

They'd be 10x better than us already if task tedium was the problem. It's design sense that they're missing. I find that in the areas where people think that LLMs excel at coding and don't like doing manually it's usually because the human was inclined to slop out repetitive boilerplate and thought that was the only way. Tests are usually like this, sadly. LLMs are definitely good at providing reams of duct tape (whi…

> They'd be 10x better than us already if task tedium was the problem... the areas where people think that LLMs excel at coding and don't like doing manually it's usually because the human was inclined to slop out repetitive boilerplate and thought that was the only way.

There is so much work out there that is repetitive / boilerplate / tedium. If you get to personally work on interesting work more than 50% of the time (pre-LLM) I'd say your job is #blessed.

Post reply on HN