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

41–50 of 132 posts

Re: The Economic Benefit of Refactoring

#41

Post by apsurd »

pragmatic wrote: post #33

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. W…

There was always bad code. Extend that to the general challenge of a bad hire doing net-negative things for the company. AI is a new problem because it 1000x a bad hire's blast radius. Personally, I'd even state that AI tends to turn an average and sometimes-but-not-always-good hire into bad hires because finally they get to do the thing they've always wanted at lightning speed in a way that previously the company red-tape wouldn't allow.

Re: The Economic Benefit of Refactoring

#42

Post by antonvs »

pragmatic wrote: post #33

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. W…

> These giant files of doom were being generated by humans anyway

Right, I've never seen an agent produce code anywhere near as bad as some of the human-generated code that I've worked on.

And, if your agent is producing huge files or functions, you can just tell it not to and it'll comply.

Re: The Economic Benefit of Refactoring

#43

Post by whats_a_quasar »

This is such a nice piece, this is how people should write about AI. Specific, grounded to how the tools are actually being used, and quantitative. There is so much bad AI commentary that is incredibly vague, divorced from any actual use cases, or written by people who don't actually use the tools. It is good to see a critique that is "here is a thing AI is bad at and measurements to show it" rather than gesturing "here is why I think AI is problematic for society."

It is rather different but another piece of research I liked for the same reason was this report that interviewed Boko Haram members about how they used AI to assist terrorism. You get these interminable online debates that are so unproductive and reporting that is specific is such a breath of fresh air.

https://casp.ac/reports/ai-enabled-terrorism

Re: The Economic Benefit of Refactoring

#44

Post by zahlman »

firasd wrote: post #14

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…

> 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

If you ask it to implement a specific kind of refactoring over a specific section of code it seems that current LLMs can do just fine. Even things as complex as "use `functools.partial` to implement the Command pattern here, rather than dataclasses".

> Is splitting files actually like decomposing factors or is it like splitting a larger number into smaller numbers that still eventually get added together

The file boundaries represent logical subsystem boundaries in the code, making it easier to reason about. The training data abundantly represents the idea of treating the contents of another file as opaque by default while other functionality in the same file can be used freely. I think it's reasonable to assume that there's something objective about the benefits that humans get from this, and it isn't just a consequence of how human cognition works.

Re: The Economic Benefit of Refactoring

#45

Post by tengbretson »

jerf wrote: post #21
pmg101 wrote: post #7

It's very interesting to have some data on this. 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'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…

It's totally worth doing. Especially since it only takes one or two manual improvements before you can just say "ok, replicate this new pattern throughout the codebase. Go."

Re: The Economic Benefit of Refactoring

#46

Post by whats_a_quasar »

danbruc wrote: post #10

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.

Yeah, I sorta expected the punchline to be "this 17,000 lines of code became 2,000" but it is still about the same quantity. Kinda interesting. Also interesting that the last change has by far the largest effect (4x reduction in tokens) and that also corresponded to the biggest reduction in single file LOC

Re: The Economic Benefit of Refactoring

#47

Post by Viliam1234 »

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 developers the big picture of the project, not just micromanage them using Jira tasks.

Exciting: You should give your AI the big picture of the project in CLAUDE.md, not just micromanage it using prompts.

Boring: Refactoring makes your developers more productive in long term.

Exciting: Refactoring makes your AI more productive in long term.

Re: The Economic Benefit of Refactoring

#48

Post by ahalay-mahalay »

Catloafdev wrote: post #40
pragmatic wrote: post #33

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. W…

> Agent code can only be read and understood by agents. This just fundamentally isn't true and if this is your perspective then you're using LLMs wrong.

Fundamentally, the code can be understood by humans, but the volume of the generated code outpaces human capacity to understand it.

Re: The Economic Benefit of Refactoring

#49

Post by zahlman »

danbruc wrote: post #32
stingraycharles wrote: post #13

Earlier quoted context omitted.

It can go both ways. Lines of code is a terrible metric for pretty much any goal that refactorings are meant to tackle.

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…

> What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code?

IMX: the scenarios where people hold higher standards than what you describe :) (i.e. such that "the function does five things" is deemed "actually bad". Of course, that does depend on the refactoring not causing an unacceptable performance hit, which can happen depending on the environment.)

Re: The Economic Benefit of Refactoring

#50

Post by Ericson2314 »

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…

No this isn't mindless reinventing --- this is finally having clear empiric evidence for something that we knew the entire time. This is a huge relief!

Next up is demonstrating the AI is more productive with better programming languages.

Post reply on HN