• Having a shared vocabulary of concepts is essential for all programming, in no way limited to AI. (It’s the key feature of Domain Driven Design, for example.) But LLMs tend to invent new confusing names even more freely than humans, and the names tend to be worse! So anything you can do to rein in the naming conventions is helpful. I just use a glossary section of the design overview document.


    score 1 · canonical

    • AIs are kind of a mishmash of every codebase out there. I think their terms are lifted from somewhere far away rather than made up. It’s like working with someone who just started at the company. Every day, and their last job was every job.


      score 1 · canonical

      • I guess we can’t put 100% of the blame on the LLM…humans came up with “cookies”, after all. Somehow it’s less charming when the computer does it.

        I never in my life heard of “minting” a unique ID until Claude started saying it. (Of course, I am old…no one’s ever said “no cap” to me either and I’m pretty sure that’s real.)


        score 1 · canonical

      • I made the mistake of approving a function name I didn’t like once. It described something as a “leaf” which, whatever it was a helper function. Later other agents picked up on that name and LOVED it and it started showing up in comments and even a suggested changelog.

        I think this is the kind of thing people think of when they say “slop” it’s sloppy. And it bleeds into the codebase and replicates.

        Humans have decades of experience of what cause each other common mistakes and how to guard against them (best practices etc.). It’s unclear in LLM generated code when I’m being pedantic because it’s not exactly how I would have done it and when it’s the start of slop that should be nipped in the bud. I think naming is one area we need to take care or it can unexpectedly bleed into other areas.


        score 1 · canonical

        • It’s unclear in LLM generated code when I’m being pedantic because it’s not exactly how I would have done it and when it’s the start of slop that should be nipped in the bud

          IMO always the second one. They don’t get frusterated by pedantic reviews and they love running with anything they can see, so its extra important to audit anything that could be a pattern.


          score 1 · canonical

          • I think there’s also an argument for “when it starts to be a problem” rather than “we must be hyper vigilant at all times.” Also depends on the blast radius. If it’s just me on the project, a refactor is easier. If there are lots of devs I don’t want to break their rebases and inflight work all the time (though LLMs make this cheaper).

            I get the sense that I edit and prune my LLM generated garden MUCH more than most. And it’s already a lot of time and work. And being pedantic takes time away from other coding tasks and is exhausting. Especially since the iteration seems to follow Zeno’s paradox. It gets closer and closer but rarely is “perfect” and often I don’t even know what “perfect is” so it diverges back and forth between a few similar solutions and I shout (to no one) I’m tired it is “good enough”.

            I also use these tools at work where we have a compliance requirement that a second human must approve and review all code. (It existed before we used LLMs). In the before times I had a healthy respect for “they did it differently than I would have but I respect their decisions” I.e. don’t bikeshed.

            Okay, sorry that’s the word I needed. How do we do better and demand higher quality while also avoiding bike shedding?


            score 1 · canonical