You still haven’t defined what vibecoding even is. It seems like what you really want to say is “was touched by an LLM”, but you haven’t justified that, except vague “the quality must be bad claims”. I guess you don’t have to justify that, though. If you really want an answer to your question you need to be more specific as to where you actually want to draw the line.
It’s the same as StackOverflow copy-paste programming, just scaled to an entire different level.
All the same caveats apply.
Sure, there are some nuances (e.g. someone could vibecode an entire app and then read every single line of code with the intent of understanding it or someone could just use it for certain parts, etc. etc.). But this was also the case before.
I don’t think there’s much point in having a discussion about an exact definition. That’s why I said it’s an indicator. Most of the time it’s instant legacy code. There’s a large spectrum in between, but LLMs have turned out to be less useful for that spectrum anyway.
It’s fine if a blocklist has false-positives. I’m not looking for an exact solution.
It’s the same as StackOverflow copy-paste programming, just scaled to an entire different level.
“The same as X but scaled to another level” is entirely meaningless. Are you trying to make a constructive point, or just trying to bait a flame war? Please specifically say what you mean, or what or we even trying to talk about?
Quite the contrary.
StackOverflow copy-paste programming is characterized by people…
- re-using code snippets they have not written
- that they don’t understand
- and have no intention of understanding
That means they created three types of debts:
- intent debt (the code may not be intended for what they actually wanted to do, but there’s an accidential overlap of functionality that seems it is what they need/want)
- cognitive debt (lack of understanding, no agency and responsibility)
- technical debt (code quality, lack of abstraction, etc.)
LLMs indeed scale this to another level, because you can now compose code snippets you haven’t written, don’t understand and don’t know the intention of.
My topic has a very specific question. If you don’t want to contribute to solving the problem, then you don’t have to engage in this discussion.
Ok, but you know the answer - you can’t tell if a dependency is “StackOverflow” programmed, so how are you going to determine if they are vibe-coded, which by your definition is a more sophisticated variant?
I have created all three of these types of debts by hand as well. I’ve also done “StackOverflow programming” and used LLMs without any of them. This seems like a poor correlation at best.
Your question is specifically “how to avoid vibe-coded deps” but you won’t say what vibe-coding even is, with enough details for us to answer the question. I am trying to contribute a solution, but you’re being too vague.
Well, there have already been suggestions:
- look for
Claude.mdand similar files in the repo - check the git history for agent commits
- run the project through an LLM (funny) to determine whether it has been vibe coded
I also had some more expressive solutions in mind, where e.g. hackage could have a label that authors themselves can add as a declaration, such as vibe-coded. Some projects do that for PRs already, so that everyone knows what they’re signing up for. Of course authors can lie about it, but that’s fine.
Yes, I have too. But that doesn’t nullify the point. There is already academic discussions about LLMs accelerating these debts: [2603.22106] From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI
And I think it’s not very hard to imagine why that might be the case. It’s because of the amount of code that’s being generated/used. It surpasses anything that has existed before (lazy coding, SO copy-pasting, etc.).
I don’t know an exact answer myself. It’s fine to start with “any project that has used an LLM” and then we can see if it’s possible to refine it.
I’m quite sure the list starts with GHC.
GHC has a rather strict contribution policy wrt AI: AI · Wiki · Glasgow Haskell Compiler / GHC · GitLab
This looks like a sane approach, let’s adopt it widely.
But it admits llm-generated snippets into the codebase, so your simple “has llm-generated snippets in the codebase” will flag GHC for inclusion into your naughty list.
Right. So you could have two lists:
- one autogenerated that just checks for LLM code
- one curated that retroactively whitelists projects with strict AI contribution policies
Maybe the majority of hackage will have LLM assisted code at some point, but until that happens, I think such an approach can be beneficial.
I think basically you can’t be satisfied unless you skim through the code of your dependencies – like you probably already would anyway. And have a mental whitelist of things that you accept are a vast trove of somewhat treacherous spaghetti, that you trust anyway, like a GCC or GHC or Cabal.
Personally, I share the sentiment somewhat and indeed want to set a boundary like that.
Alas,
- This smells strongly of “solving a social problem with tech”, and I’m worried this wouldn’t work (or at least be a net positive all things considered).
- This seems to punish cooperation and promote goodharting. Being honest and open results in having to deal with being flagged. Go dark to avoid dealing with more stuff in your life.
- The criteria, the lists, and the whole endeavor seem to induce even more fragmentation (on the code level) and tribalism (on the social level).
(Not to derail the thread or induce scope creep (sorry, I’m about to do just that).)
I’d like to have some place where I can annotate (privately, and this is critical IMO) packages and their authors with labels for maintainership, correctness, perf, vibecodededness etc.
Then run estimations on that annotated graph like “Would I regret adding this package to my dependencies?”
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.
I have long wanted a simple way to make a “maintainer graph” out of my dependency graph.
I think Haskell won’t really have this problem. And that’s a good and bad thing. Good because it means the ecosystem will stay relatively manageable bad because it’s indicative of low/waning interest in the language/ecosystem. I’ve been keeping a pulse on the Google summer of code mentors discussions and organizations are receiving record numbers of PRs and record numbers of applicants clearly fueled by AI contributions. There’s been pretty long discussions about how maintainers feel overwhelmed in other ecosystems. Meanwhile Haskell had roughly the same number of applicants (in fact less than last year) and the ones who contributed code to as part of their applications seemed thoughtful and honest in their use of AI. So we don’t attract that many people but the people we do attract tend to be the “right” kind of people for now.
I think the AI discussion is important to have because if the community grows at any point in the future it’s better if our stance is clear. That said, I’ve said this in other threads too, getting people to adopt Haskell is hard enough because of its perceived elitism so name and shame lists might not be great if attracting new developers in the goal. Maybe softer ways to nudge people to focus on high quality contributions might be a better strategic and political investment. Idk what that looks like.
I’m a bit confused. I agree with all of what you say here, but then you label that as emotional fear.
All 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:
- Insights from 2025 GenAI Code Security Report
- Study finds AI-generated code far buggier than human work
And all sorts of specific incidents, to name only a few:
- LiteLLM Supply Chain Attack: How to Respond | Cycode
- 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
We have everything here: supply chain attacks, total lack of QA, agents in prod deleting databases, glaring security holes, operational failures causing financial damage, …
Sure, 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.
How 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.
I 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.
Those are all great questions, and I’d rather have the answers.
I just don’t care if another spike of this negligent attitude and sloppy maintainership comes from the Eternal September, Stack Overflow, or AIs. We are our own supply-chain attackers 
Hello!
That looks like a relevant question. And it does sounds quite different from filtering out vibe-coded dependencies. Isn’t it?
It starts to look similar to demanding good practices like documenting the implementation, or providing unit tests.
How about asking for code contributions to be peer reviewed? (like in pull requests) Does that help ensuring LLM generated code gets the same amount of attention as other contributions?
If the PRs are too large or too many, they can be rejected due to lack of resources to review them 
I’m happy to learn about the objections, though. 
Cheers!
Sorry for off topic, but I am curious how good Claude at expanding promoting macros from Singletons package to type families. Have you had a chance to try?
I have no idea, sorry.