> 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 properly. Document, test, plan, refactor, lint, use CI tooling. There is no excuse now that LLMs reduce the pain threshold for all of them.

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 awful but they can have an advantage. It's a form of compression once you are adapted to it. It forces you to keep things simple. When we can write an entire novel for a variable name, we may be tempted to inflate the scope of a solution.

No comments is universally a feature. If I want justification for a section of code, I am going to check git blame, PRs, linked issues, email, project management system, etc. The only code comments I value less than those written by humans are those written by LLMs. It is beyond pointless to shit up a codebase with this stuff. You could just ask the LLM to give you a live interpretation of the current state of the code instead of risking something falling out of sync.

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.

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.

The worst thing about Ouija board debugging is the latency and bitrate. Honestly, I can tolerate a puzzle project. It’s almost satisfying. But sitting there and waiting for the response is agonizing.

Perhaps not the most reasonable thing ever to rely on an LLM for formatting given that there exist good old zero-token-using formatters for pretty much any language under the sky.

> BTW: with today’s LLMs, there’s really no excuse for badly-documented, or badly-formatted code. You can write a thousand lines of commercial-grade spaghetti, and tell the LLM to format and document it.

And how do you know that the documentation is correct? Because if it's not, it's worse than being absent. The verification work sounds close to as hard as writing it in the first place.

This is what I never grasp when people suggest LLMs for anything precise (outside of cases where the LLM output is in a machine-verifiable language).

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.

> 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) {

first fix attempt:

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

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

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

> 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));
    }

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.

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

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.

> an LLM, especially the more modern ones, have way more short term memory than most humans

But it's not unlimited. So they can write code that they "understand" within the limits of their working context. When it grows beyond that, they can't cope with it in its entirety. And a human, at that point, has no prayer.

So true.

I worked one place where I had a team of 4 offshore devs replace my two good people. Three months of some of the worst quality work I’ve ever seen. And I was responsible for it on paper.

Decided fuck it, promoted one of them to manager and gave him a project to finish in 3 months, leading the other 3.

In that three months I redid that entire project, did their current project and a week of another one. All in a 25 hour week calendar.

Then I quit.

A lot of people are going to get a painful lesson in this if companies keep using LLMs to do all their programming.

Oh and by the way, I will also submit that there is a form of bankruptcy for technical debt.

The company folds, or the software is no longer maintained or in use.

When was the last time you used word Perfect? Or MS-DOS?

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?

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?

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

I was mainly .NET dev in the first 8 years of my career and it's a pretty common thing among .NET shops/corporates. Most .NET devs I worked with seemed to be on average older guys who are stuck in .NET Framework 3.x days. I joined a place that used .NET 5 and one guy was still writing hash code and equal methods for every single data class he made(by hand too). When I asked him why, he said that he didn't know he doesn't have to do that anymore. Those people are mostly alright/mediocre devs who just refuse to keep up with the times, clock in, clock out, don't think too much, just write some more code to make it work. If someone a decade ago started some convoluted architectural pattern, they'll just continue doing it, no thought given as to why or what for, whether things can be done better. While I have different, but equally annoying issues with Node/Js world I work in now, I don't miss those .NET days.

I can believe that... We've had logging macros break because line numbers no longer fit in an u16

I would love a TV show like "Hell's kitchen" except it's code bases and development processes.

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

Last place I worked they had an ASP.Net MVC controller with basically the entire product in it. The .cs file was nearly 2 megs.