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

There's No Limit to How Bad Code Can Get

zachkehs.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: There's No Limit to How Bad Code Can Get

#61

Post by EPWN3D »

edukite wrote: post #19
socalgal2 wrote: post #11

2 things 1. LLM can fix this in my experience. an LLM, especially the more modern ones, have way more short term memory than most humans (or at least way more than me). They can dig through this kind of code and figure out all the edge cases, write test, suggest various paths to make things better and then execute on those paths. On request they will happily setup dev systems, staging systems, whatever it takes to ma…

You are the very first person I encountered who claim LLM can fix technical debt. Usually I seem comments and articles saying LLM can only produce it. And I can agree with those articles and comments

Yes like any tool, LLMs can be used poorly. But they do enable large-scale rewrites or poor-quality code because they are capable of understanding it and enumerating its behaviors in a matter of minutes or hours. It's the kind of understanding that would take a human months or years to develop.

Add to that their ability to basically set up what is essentially a perfect testing environment when asked, and you've got a feedback loop that lets you just step back while the agent cranks out a new implementation in a memory-safe language with a full test suite and bug-for-bug compatibility. I'm not kidding or exaggerating. This stuff is possible now, people just need to look past their anxieties about being replaced.

Re: There's No Limit to How Bad Code Can Get

#62

Post by ModernMech »

edukite wrote: post #19
socalgal2 wrote: post #11

2 things 1. LLM can fix this in my experience. an LLM, especially the more modern ones, have way more short term memory than most humans (or at least way more than me). They can dig through this kind of code and figure out all the edge cases, write test, suggest various paths to make things better and then execute on those paths. On request they will happily setup dev systems, staging systems, whatever it takes to ma…

You are the very first person I encountered who claim LLM can fix technical debt. Usually I seem comments and articles saying LLM can only produce it. And I can agree with those articles and comments

I’ll be the second then. I’ve found it’s very good at creating debt but equally good at resolving it. The thing is the default mode is creating debt so you have to intentionally pay it down.

Refactors that used to take me a month now take a week, it’s very handy. You can instruct them to move functions around, change interfaces, add or remove abstractions, remove redundant authorities, untangle spaghetti, rename identifiers across a codebase, and it will return very good results.

Re: There's No Limit to How Bad Code Can Get

#63

Post by Isamu »

ChrisMarshallNY wrote: post #7

One of my first jobs, was as a maintenance engineer, on a 100KLoC+ codebase of 1979s-era FORTRAN IV. No comments. No subroutines (what we now call “functions”). No variable name longer than 4 characters. Fun. The most effective debug tool, was a Ouija board. It made me an expert WAGger. It was the main reason that I am so anal about code Quality, these days. I never want to subject anyone else to that. BTW: with toda…

Greetings fellow traveler, I did the same. FORTRAN IV, I was tasked with finding a way to introduce subroutines. But it was a tangled mess of gotos with loops inside loops and overlapping loops and spectacular jumps in and out. It was an obscure undocumented algorithm for calculating the thermodynamic properties of turbine stages or some such.

Good times.

Re: There's No Limit to How Bad Code Can Get

#64

Post by pir8life4me »

I recently got a thank you and a refund for towels I had returned from Amazon.

The towels were damp from bring used, I had never initiated a refund return, nor had I in fact returned them.

I reported this to amazon and had to find a human since the system had no "refund for nonexistent returns" option. The human didn't get it and pinged his team lead. After 20 minutes they told me to just keep my towels and refund.

Re: There's No Limit to How Bad Code Can Get

#65

Post by EPWN3D »

Arainach wrote: post #58
skybrian wrote: post #39

Earlier quoted context omitted.

There is a lot of noise out there from anti-AI types who never seriously tried to clean up messes with AI. If you just ask for new features and never look at the code, coding agents will make a mess. If you often ask questions about how to clean up messy code, coding agents are great help for that, too. But you have to ask.

Agents (and humans) don't know what cleanups are safe or a good idea. They can get stuck in loops when different goals (conciseness, performance, etc.) clash. Their "improvements" can break things unintentionally. Targeted improvements can be good. Giant lists of "fix everything" are bad and will break things. Tech debt comes with insufficient tests, so you won't know what you've broken until too late in many cases.

Yeah that's why step 0 is to tell the LLM to write a test suite for the thing you want to rewrite. It'll do that, but it does require adult supervision. Once you have that test suite, you can send the LLM into an inner dev loop. Like human programmers, LLMs are great when they have a fast inner loop.

The fact that LLMs exist doesn't mean you can just stop thinking. It mean the things you have to think about will be different. You have to treat them as savants with absolutely no ambition.

Re: There's No Limit to How Bad Code Can Get

#66

Post by ryaniscool »

socalgal2 wrote: post #11

2 things 1. LLM can fix this in my experience. an LLM, especially the more modern ones, have way more short term memory than most humans (or at least way more than me). They can dig through this kind of code and figure out all the edge cases, write test, suggest various paths to make things better and then execute on those paths. On request they will happily setup dev systems, staging systems, whatever it takes to ma…

For 1, effectiveness still depends on the size and complexity of the codebase.

From my experience, as complexity and size grow, each prompt takes longer, does less, and is prone to more mistakes and disruptions to other parts of the codebase.

Re: There's No Limit to How Bad Code Can Get

#67

Post by ModernMech »

EPWN3D wrote: post #65
Arainach wrote: post #58

Earlier quoted context omitted.

Agents (and humans) don't know what cleanups are safe or a good idea. They can get stuck in loops when different goals (conciseness, performance, etc.) clash. Their "improvements" can break things unintentionally. Targeted improvements can be good. Giant lists of "fix everything" are bad and will break things. Tech debt comes with insufficient tests, so you won't know what you've broken until too late in many cases.

Yeah that's why step 0 is to tell the LLM to write a test suite for the thing you want to rewrite. It'll do that, but it does require adult supervision. Once you have that test suite, you can send the LLM into an inner dev loop. Like human programmers, LLMs are great when they have a fast inner loop. The fact that LLMs exist doesn't mean you can just stop thinking. It mean the things you have to think about will be d…

There’s a trap here though: the LLMs if you let them will spend all their time maintaining that test suite, they can become quite rigid in the way they design them. So it’ll write some code, break a test, which breaks a contract so then it updates the test and the contract but updating the test also broke another contract… soon enough you’re spending all your tokens fixing contracts instead of writing code.

In a sense the LLM having a fast inner loop is its blessing and curse. A blessing because it gets feedback quickly, but a curse because it becomes naval gazing and cannot see the forest for the trees.

At least this is my experience with Sol maby other models behave differently.

Re: There's No Limit to How Bad Code Can Get

#68

Post by zer00eyz »

pixl97 wrote: post #59
zer00eyz wrote: post #33

Earlier quoted context omitted.

> we're now able to accumulate technical debt faster than ever LLM's just enable you to speed run your way into a legacy code base. > without even building the institutional knowable needed to keep it sane Does feature XXX move the needle? Did you gain more business or retain existing business because a feature exits? Has AI tooling helped your product team move the needle? No? Why not? How easy is it to remove the f…

Remove a feature no one uses: How do you properly measure this? Do you setup a database that monitors when every feature is used? Is the feature only used once a year for some reason? Is the feature only used on some rare data that is uncommon but still can occur? And that really applies to something fully in your control. In systems controlled by customers its far harder.

> How do you properly measure this?

The same way you measure utilization and cost at a customer level.

I can name at lest three companies where their biggest clients are also the bulk of their costs - they lift revenue but drag the margins. I can name another couple who spent years marking their products entirely wrong because they simply had no clue how their product was really being used.

> Is the feature only used on some rare data that is uncommon but still can occur?

This is where the competence of your product team comes into play. We're building features faster with AI but none of it is moving the needle. That has little to nothing to do with code quality, and everything to do with product teams.

Re: There's No Limit to How Bad Code Can Get

#69

Post by zkehs »

blevinstein wrote: post #60

> Technical debt has no bankruptcy, no clean reset There definitely is a technical debt bankruptcy option. You can stop using a particular piece of code or technology, e.g. by replacing it (with new code, or a third-party/vendor solution), or re-architecting a system or business process so that the code's function is no longer needed. This is exactly what the technical debt metaphor means. Short-lived systems can acc…

Yes, a rewrite or replacement is the software analogue of the debt metaphor.

Section 3 of the article elaborates more on the technical debt statement in the TL;DR, but the gist of the argument there is that for a lot of systems, the rewrite is not really an option. Pretending it is an option is a partial contributor to the attitudes that make the debt spiral (or so I argue).

Yes, sometimes a rewrite is possible but the success stories are uncommon and are far outnumbered by failures.

Re: There's No Limit to How Bad Code Can Get

#70

Post by gdulli »

tredre3 wrote: post #51
hombre_fatal wrote: post #18

This is a good example of what LLMs save us from. Everyone likes to pretend that LLMs are only capable of writing mudballs, but it's trivially debunked by using LLMs yourself to refactor code, pay back debt, and fan out agents to look for debt to repay. We're already at the point with sota models where I'm not even sure you can get the sort of mudballs OP is talking about; the LLM's inherent "taste" forbids it, and i…

I'm willing to keep an open mind but the only example you've shared of such a success story and debunk was a LLM clearing the technical debt of a codebase that was fully LLM-written from the very first commit? If LLMs are so good at fixing tech debts, why did it write so much to begin with? And why do you assume that now there's no more debt?

It's like trying to argue with someone saying they actually are going to build the whole plane out of the black box. At some point we should just cut our losses.
Post reply on HN