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

[dead]