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

41–50 of 87 posts

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

#41

Post by gdulli »

MartinodF wrote: post #38
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…

While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions

People refuse to accept that there's more bad code/behavior/people that AI will empower and amplify than good.

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

#42

Post by mminer237 »

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…

Running code through a deterministic formatter definitely helps a lot, but I've generally found LLMs' comments to add no-to-negative value. They just say what code does, typically very verbosely that just inflates files more while also just stating the most obvious aspects of the code and not adding any meaning behind it because they obviously don't know that. Not to the mention all the cases where they make mistakes and then you have code you don't intuitively understand and also have comments telling you it does something it doesn't.

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

#43

Post by SoftTalker »

aDyslecticCrow wrote: post #26
jdw64 wrote: post #3

The worst I have experienced: A 30,000-line .cs file. A giant monolithic program tangled together by Singleton abuse, 6-deep nested if/else blocks, and the list goes on. There are too many to count. And this is a sight I see every single day. This is the exact landscape I encounter at many companies when I go in for maintenance work. Encapsulation completely shattered as a direct reflection of the subcontracting powe…

> 6-deep nested if/else blocks We found a 4000 Loc single-file single-function c program running a functional safety domain. With nesting so deep that you need to change the font-size or get a wider monitor. We're not allowed to touch or replace it because it's pre-certified.

Deeply nested if/else blocks are logically the same if you split them up into classes or functions that perform the same logic. They are harder to understand, harder to re-use, harder to work with in an editor... but should not be harder to test (you need to test all the possible use cases either way).

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

#44

Post by customguy »

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 throwaway experiment. Gemini wrote this for me:

      span.onclick = (e) => {
          e.stopPropagation();
          loadFolder(node.fullPath);
      };
      li.appendChild(span);
      if (node.children && node.children.length > 0) {
          node.children.forEach(child => li.appendChild(renderTree(child)));
      }
      ul.appendChild(li);
      return ul;
    }
    async function loadFolder(folderPath) {
Note the function name "loadFolder", and the short distance between the definition and where it gets called... So after a bunch of other changes, one change it made completely broke everything. I didn't check any of the code, but just described the symptoms etc.

first fix attempt:

    // Call your backend loader safely
    if (typeof loadFolderFiles === "function") {
        loadFolderFiles(nodePath);
    } else if (typeof loadFiles === "function") {
        loadFiles(nodePath);
    }
second fix attempt:

    // Call your app's existing folder loader
    if (typeof loadFolderFiles === "function") {
        loadFolderFiles(nodePath);
    } else if (typeof loadFiles === "function") {
        loadFiles(nodePath);
    }
third:

    // Call backend loader
    if (typeof loadFolderFiles === "function") {
        loadFolderFiles(nodePath);
    } else if (typeof loadFiles === "function") {
        loadFiles(nodePath);
    }
and finally:

> Most likely, your original code either passed childNode to a function like selectFolder(node) or sent a specific fetch() request. Here is the updated renderTree function [..]

    if (typeof selectFolder === "function") {
        selectFolder(childNode);
    } else if (typeof onFolderSelect === "function") {
        onFolderSelect(nodePath);
    } else if (typeof loadFolderFiles === "function") {
        loadFolderFiles(nodePath);
    } else if (typeof loadFiles === "function") {
        loadFiles(nodePath);
    } else {
        // Direct API fetch fallback if your backend uses a standard endpoint
        fetch(`/api/files?path=${encodeURIComponent(nodePath)}`)
            .then(res => res.json())
            .then(data => {
                if (typeof renderFileList === "function") renderFileList(data);
            })
            .catch(err => console.error("Error fetching folder files:", err));
    }
I can only imagine what is going on out there right now, but I fully assume most of it is not very good, lots of it horrifying crap that technically, kinda works.

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

#45

Post by efficax »

MartinodF wrote: post #38
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…

While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions

the models have gotten very good at doing what you ask. if you ask for changes that will accrue tech debt, you'll get it. if you ask for changes that pay down that debt, you'll get it.

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

#46

Post by meerita »

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 got the same process down to less than a minute. With AI, we probably would have done it in less than a day, and with a better programming language, probably even faster.

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

#47

Post by jvanderbot »

mminer237 wrote: post #42
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…

Running code through a deterministic formatter definitely helps a lot, but I've generally found LLMs' comments to add no-to-negative value. They just say what code does, typically very verbosely that just inflates files more while also just stating the most obvious aspects of the code and not adding any meaning behind it because they obviously don't know that. Not to the mention all the cases where they make mistakes…

Or worse, the comments are a tutorial through the changes for your review, referring to something that now doesn't exist because of the changes you're making. Less than informative, literally backwards facing.

But that's what stackoverflow looks like.

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

#48

Post by hombre_fatal »

MartinodF wrote: post #38
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…

While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions

Like real life, you want to accrue debt strategically.

When you're experimenting, vetting ideas, mapping out the requirements, exploring solutions, then technical debt keeps churn cheap.

e.g. You don't want to overly commit to static types that keep "impossible state unrepresentable" too early on since you aren't even sure yet what impossible state looks like in the system.

So we regard debt repayment as some sort of transformation we'll do in the future that never comes because it's hard and expensive, but not to LLMs.

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

#49

Post by hombre_fatal »

gdulli wrote: post #41
MartinodF wrote: post #38

Earlier quoted context omitted.

While I agree and I have done more than one rewrite / cleanup of messy codebases quite successfully with LLMs in the past few months, I can assure you plenty of people are still using the latest models to accrue technical debt faster than I thought was ever possible. The model "taste", assuming it has one, does not survive bad instructions

People refuse to accept that there's more bad code/behavior/people that AI will empower and amplify than good.

Because we have evidence otherwise, and even the worst code can be refactored by LLMs.

That a high velocity project might accumulate technical debt isn't interesting to me if LLMs can also pay it back or if you can decide to work at a different pace where you polish the architecture as you go instead of accumulating debt.

I'd make the opposite claim to you: people really don't want my claims to be true, probably because it robs us of our value and expertise as software engineers. But it's getting a bit late in the game to still be dancing around that pill to swallow.

Post reply on HN