{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreic4up26q4h663uc5leqs2hts7q352ukdjyptjy4wfhfowrtutnwpa",
"uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjc35lglvlt2"
},
"path": "/t/how-to-filter-out-vibe-coded-dependencies/13918?page=2#post_36",
"publishedAt": "2026-04-12T09:33:10.000Z",
"site": "https://discourse.haskell.org",
"tags": [
"Insights from 2025 GenAI Code Security Report",
"Study finds AI-generated code far buggier than human work",
"LiteLLM Supply Chain Attack: What Happened and How to Respond",
"Claude’s code: Anthropic leaks source code for AI software engineering tool | Technology | The Guardian",
"https://medium.com/@somanathtv/the-lovable-supabase-stack-when-ai-driven-speed-becomes-your-biggest-liability-e94aad6f0102"
],
"textContent": "FPtje:\n\n> 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?\n\nI’m a bit confused. I agree with all of what you say here, but then you label that as emotional fear.\n\nAll of what you described are technical fears. And there’s **overwhelming evidence** that LLM use for code generation is horrendous when it comes to security and trust:\n\n * Insights from 2025 GenAI Code Security Report\n * Study finds AI-generated code far buggier than human work\n\n\n\nAnd all sorts of specific incidents, to name only a few:\n\n * LiteLLM Supply Chain Attack: What Happened and How to Respond\n * Claude’s code: Anthropic leaks source code for AI software engineering tool | Technology | The Guardian\n * https://medium.com/@somanathtv/the-lovable-supabase-stack-when-ai-driven-speed-becomes-your-biggest-liability-e94aad6f0102\n\n\n\nWe have everything here: supply chain attacks, total lack of QA, agents in prod deleting databases, glaring security holes, operational failures causing financial damage, …\n\nSure, this is a multi-faceted issue and I don’t want to derail into general problems of LLM use. I’m only concerned about LLM generated code here. But I mean the evidence is overwhelming that these things cause gigantic f**k ups, especially when vibe coding.\n\nHow does that not make us pause for a moment and say: yeah, we need an inventory. And we need an incentive for maintainers to have good LLM contribution policies.\n\nI also don’t see why a list of vibe-coded hackage packages would cause social issues. I think that’s a bit far-fetched. This is not about hackage admins starting to shut down projects. This is just about a list maintained by some people that can be happily ignored by anyone, if they deem it useless.",
"title": "How to filter out vibe-coded dependencies"
}