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

51–60 of 87 posts

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

#51

Post by tredre3 »

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?

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

#52

Post by antonvs »

customguy wrote: post #44
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…

> You can write a thousand lines of commercial-grade spaghetti, and tell the LLM to format and document it. Yes, you can tell the LLM to format and document it. You can also tell an effigy of Richard Nixon, or write it on a piece of paper and burn it. Of course you can do such things, but the important question is what that gains you. Yesterday I vibe slop coded something, being very lazy about it, it being a throwaw…

The problem with using LLMs to write Javascript is that they’re trained on Javascript written by humans. Which is not the training corpus I’d choose to teach a neural net to write code.

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

#53

Post by daveguy »

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…

Only problem is the LLM comments are the exact same quality as the code. In other words, LLM comments also have to be thoroughly reviewed.

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

#54

Post by hombre_fatal »

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?

Good questions.

> why did it write so much to begin with?

It's an incremental project covering a complex domain. At any time, the code has to stay balanced in a spot that addresses correctness and performance across things like pty parsing, a terminal grid, stateful pty behavior, rendering, scrollback history, font glyphs, and like all software there is a fractal of idiosyncrasies that sprout up. And that's just the terminal side.

Unless you can see the future, like most software, so much of the project is trying things and seeing what happens at the periphery, like how to represent "row damage" and apply it in a way that works with macOS Core Graphics and 1000 other things.

e.g. Can you tell me off the top of your head what the trade-offs are of representing the terminal contents/scrollback as a pre-wrapped grid vs. a list of logical lines that are soft-wrapped on the fly? Did you enumerate them all and correctly weigh them such that you can pick the ideal solution ahead of time? No. You just kinda make educated decisions and find out in practice what the exact weight of the trade-offs are.

You should see the amount of iterations a human needs on these kinds of projects. https://github.com/ghostty-org/ghostty has almost 18,000 commits. So does https://github.com/gnachman/iterm2. So does https://github.com/kovidgoyal/kitty.

> why do you assume that now there's no more debt?

I don't. Like all software, you try to ratchet into better and better positions, and you try to come up with metrics that can tell you "You are here" with regard to rather fuzzy goals like "it should be correct and performant and nice to use".

But I can look at individual findings and their solution to go "yes, this improves the code." And on principle I think that, e.g. correct/DRY/simple by-construction is superior to by-convention, and I assume it helps future agents reason about the system and make future edits, and it gives them singular places to make changes that impact multiple components just like it would a human. But how much did it actually matter?

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

#56

Post by chrismorgan »

meerita wrote: post #46

The worst experience I had was with a telecom company. They had an internal web app that allowed them to upload a gigantic CSV file with millions of records from new phone activations. The web app took 59 minutes to process it! The culprit: a single 30K .js file with one function, more and more recursive functions, and deeply nested if/else statements, up to 10 levels. We spent one month undoing that Gordian knot and…

If it only took 59 minutes to process millions of records, it was nowhere near as bad as it could have been. At around one millisecond per record, it sounds like you probably don’t even have any accidental quadratic time complexity on the number of records! What are you complaining about?

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

#57

Post by brazukadev »

skybrian wrote: post #39
edukite wrote: post #19

Earlier quoted context omitted.

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

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.

asking to clean up is not enough, it is needed to understand the code and fix the things the agents are getting wrong.

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

#58

Post by Arainach »

skybrian wrote: post #39
edukite wrote: post #19

Earlier quoted context omitted.

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

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.

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

#59

Post by pixl97 »

zer00eyz wrote: post #33
aDyslecticCrow wrote: post #17

Earlier quoted context omitted.

> LLMs, there’s really no excuse I'd phrase it differently; we're now able to accumulate technical debt faster than ever, without even building the institutional knowable needed to keep it sane. While the models writes novels about what it's doing that no human or LLM will find any use for. But at the same time; if the LLM makes coding 5-10x faster, there's plenty of left-over time we can now spend doing things prope…

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

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

#60

Post by blevinstein »

> 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 accumulate a lot of technical debt without as much concern, because you're planning to declare bankruptcy (deprecate and decommission) the code soon anyways; long-lived systems must plan to pay off their technical debt on the usual installment plan.

Post reply on HN