There's No Limit to How Bad Code Can Get

Post by ChrisMarshallNY » Sat, Sep 05, 2026, 5:31 PM UTC

bob1029 wrote: post #15

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…

I've seen "clean" codebases that conform to "best practices" which are even less decipherable than what you describe. 100KLoC sounds like paradise compared to the latest codebase I touched. Having the signal to noise ratio fluctuate wildly at every member & file is highly distracting. When the information is dense and consistent, you can drop into a flow state more easily. Four character variable names might sound aw…

Post by linuxrebe1 » Sat, Sep 05, 2026, 5:34 PM UTC

linuxrebe1 wrote: post #72

As I read this article, as a non-coder (for a living) I noticed that what is being assumed is that the code produces a desired result. To that I will agree. You can really produce some bad code that has a positive outcome. But as a counter proposal, I will submit that code can get so bad, that the product no longer produces a desirable result, no longer produces it in a manner that people want, or doesn't produce it…

Post by socalgal2 » Sat, Sep 05, 2026, 6:37 PM UTC

ryaniscool wrote: post #66

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.

Post by AnimalMuppet » Sat, Sep 05, 2026, 6:57 PM UTC

antonvs wrote: post #52

customguy wrote: post #44

Earlier quoted context omitted.

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

Post by tosti » Sat, Sep 05, 2026, 7:06 PM UTC

ModernMech wrote: post #67

EPWN3D wrote: post #65

Earlier quoted context omitted.

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 sens…