How to filter out vibe-coded dependencies
wiz:
This smells strongly of “solving a social problem with tech”,
I think you’re hitting the hammer on the nail here. The elephant in this room I think is an emotional one: fear.
What if my software gets serious vulnerabilities or bugs because of ai slop dependencies? What if hackage becomes overloaded with slop and we can’t find the human programmed packages anymore? What if the quality of previously good packages goes down the drain because someone in the dependency tree doesn’t understand their code? What if library intent/cognitive/technical debt go through the roof and Haskell becomes a super buggy and unsafe language?
I honestly think that this desire to have a list, a detection method, a label is an attempt to get control over this fear. It’s an attempt to keep one’s own software safe from all of this stuff just a little bit longer.
To be very honest, I don’t share this fear. Sure, Haskell noobs will create vibe coded packages and pull requests, but the Haskell community is the most scientifically literate one I know of. I have enough trust in the maintainers of important packages to guard the quality of their direct dependencies and contributions. And if the quality is good, then it doesn’t matter whether was built with agents. After all, I have found that engineers can learn to use AI Augmented Engineering methods to both speed up development while also actually increasing the quality.
Discussion in the ATmosphere