How to filter out vibe-coded dependencies

arybczak:

Exactly. What’s the difference between a package that was badly coded by an LLM and a package that was badly coded by a human? I don’t see any.

The main difference is intent. I can’t really go talk to the LLM and ask about specific intentions regarding specific pieces of code. The “prompt engineer” might never have seen that piece of code and might only vaguely remember the instructions that led to that piece of code.

There might be no particular reason why something is the way it is. It may just be the model weights, the training set, the prompt input, the context. Whatever.

If it was written by a human (even if the quality is sub-par), there’s a high chance I can go talk to them and they might be able to enlighten me.

Even if that’s not possible, I find slop code more alienating. It’s a wild combination of mosaic, unless the prompt was super specific and the context very narrow.

But fair enough… let’s take the prime example of badly written Haskell code, which is in my opinion Cabal. It is the way it is not because the contributors were sloppy coders, but because it had too many generations of maintainers that passed by with huge contributions and then moved on without ever having:

• socialized for an extended period of time
• allowed other maintainers to absorb their ideas, coding style and visions
• taught the next generation and conveyed the intent and caveats of the current codebase

I don’t want to sound too romantic… like programmers gathering around a lake, drinking beer and sharing ideas… oh wait, that was ZuriHac, nevermind.

I mean that we can now witness in Cabal how hard it is to maintain institutional knowledge and visions amongst humans. If you remove the human element, you create that type of legacy nightmare in an instant , where interacting with said code becomes an archeological exercise and causes psychological damage.