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

31–40 of 132 posts

Re: The Economic Benefit of Refactoring

#31

Post by zuzululu »

firasd wrote: post #29
zuzululu wrote: post #28

Earlier quoted context omitted.

Your take is outdated. Agents are excellent at refactoring now. If you told me what you wrote during an interview, that would be grounds to not continue. It's very important that you are using coding agents with the latest frontier models and know exactly what it can't and can't do if you want to be hired in this market.

Interesting that you said the word ‘using’. Why is that? If an agent could refactor excellently without a human who is the user

"Refactor this code spin up subagents" try that in codex to start your journey of improving your agentic coding skills but if you are too lazy to do even then there's just no hope for you.

I am currently working 3 remote jobs thanks to agentic coding and one of the jobs require me to interview and hire other devs. I find it amusing how many are irrationaly resistant and unwilling to use agentic coding. They are also the loudest in the room with opinions that are outdated. On the flip side, it's just as funny how to see how complicated engineers try to make agentic coding. It doesn't have to be and that's not its design. Don't get in its way as much as possible. The frontier models are good enough that adding complexity only wastes more tokens. We've come a long way from the summer you were fiddling with Sonnet 4.5 in Cursor or windsurf.

The job market isn't suddenly going to swoop in and save you by banning AI agents. Keep up or get left behind. Don't let other people's opinions about AI agents hinder your own progress, chances are they have no skin in the game.

Re: The Economic Benefit of Refactoring

#32

Post by danbruc »

stingraycharles wrote: post #13
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.

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 the code is actually bad - code duplication, bad abstractions, inefficient language use, ... - I would generally expect the lines of code to significantly drop. What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code? It is certainly possible but at moment I am having a hard time comming up with a good example.

Re: The Economic Benefit of Refactoring

#33

Post by pragmatic »

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. With LLMs it’s at last manageable or feasible to edit, refactor etc.

I honestly think LLMs are going to save us from ourselves as the codebases became too large and “messy” for humans to comprehend. (Mono repos of doom)

On a personal level these giant files are abhorrent but that’s just personal taste and I don’t think any of the Martin Fowler refactor/cleanup stuff is going to matter at all anymore. Kinda sad on some level.

Re: The Economic Benefit of Refactoring

#34

Post by Catloafdev »

NichoPaolucci wrote: post #17
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 don’t know. LOC to me is indispensable for certain refactoring goals in my opinion. Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future. Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this f…

That's LOC in a single file, that's a bit different from total LOC as a metric.

Total LOC is a garbage metric. Things like reducing line count in specific files or components is a big benefit, but those lines are often moved, not dropped.

Re: The Economic Benefit of Refactoring

#35

Post by Shish2k »

NichoPaolucci wrote: post #17
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 don’t know. LOC to me is indispensable for certain refactoring goals in my opinion. Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future. Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this f…

A couple of days ago I split a single class which did 5 barely-connected things, where each of the 5 entry points had another 5-10 private helper methods (none of which were shared between entry points), into 5 separate classes which each do one thing - total number of lines went up (because they all have the same boilerplate import statements at the top), but being able to focus on one entry point and it's helpers at a time has made things much easier to work with

Re: The Economic Benefit of Refactoring

#36

Post by [deleted] »

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…

[deleted]

Re: The Economic Benefit of Refactoring

#37

Post by JacesArchivist »

zuzululu wrote: post #31
firasd wrote: post #29

Earlier quoted context omitted.

Interesting that you said the word ‘using’. Why is that? If an agent could refactor excellently without a human who is the user

"Refactor this code spin up subagents" try that in codex to start your journey of improving your agentic coding skills but if you are too lazy to do even then there's just no hope for you. I am currently working 3 remote jobs thanks to agentic coding and one of the jobs require me to interview and hire other devs. I find it amusing how many are irrationaly resistant and unwilling to use agentic coding. They are also…

> "Refactor this code spin up subagents" try that in codex

The deferral of all agency as a product owner over to the stochastic-word-box-in-a-do-loop feels like the kind of thing that, if you mentioned you do that in an interview, would be grounds to not continue.

Re: your updated comment, I'm glad you've found success with this pattern of behavior, but I'd suggest that you might be extrapolating "I haven't been punished yet for this shortcut" to "This is the future of work and those who disagree are luddites".

Re: The Economic Benefit of Refactoring

#38

Post by apsurd »

zuzululu wrote: post #31
firasd wrote: post #29

Earlier quoted context omitted.

Interesting that you said the word ‘using’. Why is that? If an agent could refactor excellently without a human who is the user

"Refactor this code spin up subagents" try that in codex to start your journey of improving your agentic coding skills but if you are too lazy to do even then there's just no hope for you. I am currently working 3 remote jobs thanks to agentic coding and one of the jobs require me to interview and hire other devs. I find it amusing how many are irrationaly resistant and unwilling to use agentic coding. They are also…

lol - I guess, if I heard that in an interview that would be grounds not to continue.

    "enhance"
fwiw codex is very good. arguably better than the sonnet equivalent (value-wise). I use both daily, professionally. And "refactor this code spin up subagents" is hardly an expert-level "I wouldn't hire you" flex.

EDIT: agree with your comment updates. I'd just say it more positively leaning especially to people who are stressed financially. SOTA has advanced a lot so counter-intuitively being behind isn't really behind, it can almost be a way to leap-frog, lean on the Agents. But definitely you have to commit to putting in the reps and learning and not just mindlessly instructing AI to "fix it". Think that's where the discussion splits.

Re: The Economic Benefit of Refactoring

#40

Post by Catloafdev »

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.

Post reply on HN