As the most active “triage member” of the General registry, vibe-coded packages are starting to become a bit of a problem: For most normal packages that I “triage” in the #new-packages-feed on Slack, I spend probably less than 10 seconds to check that there’s some amount of documentation, the package name seems reasonable, maybe a name-similarity override is needed. With LLM-generated packages, this doesn’t work. They look okay on the surface, but as soon as your read closer, things just don’t make sense. But then I have to really think about whether it just doesn’t make sense to me , and maybe there’s just a different perspective, or whether I can tell for sure that it’s LLM slop. That sort of thing really sucks time, and also leads to awkward conversations. I can probably still tell in 10 seconds is something smells like LLM, so it might be helpful to have a guideline to point to that says “no vibe-coding allowed”, without having to go into details. Then the author can still come back and say “but I really double checked everything, and I stand by the quality of the package”. I’m certainly not opposed to the appropriate use of LLMs along the lines of Chris’ Discourse post on the topic.
It is also important to note that the review process for the General registry basically doesn’t involve any really hard rules. We will still judge things on a case-by-case basis and always try to reach good-faith consensus. But I think an official “vibe-coded packages are not suitable for registration in the General registry” would be a helpful baseline.
I’d much prefer to do the “gut check” only. As soon as add something automated, people start “gaming” it in exactly the way you suggest (instructing Claude to avoid emojis). This already happens with the automated name checks. People rename their packages just to “make the bot happy”, even if the new name is worse than the original and they should have just asked for an overrride.