Should General have a guideline or rule preventing registration of vibe-coded packages?

ericphanson
Thu, 16 Oct 2025 12:32:46 +0000
Community

Note: here vibe-coding means “building software with an LLM without reviewing the code it writes”.

Background: General is moderately but not totally permissive

Package registries across programming language communities come in various flavors of permissiveness. Some, like npm/pypi/cargo, automatically & immediately register a package once a few automated checks pass. Others, like R’s CRAN, or TeX’s CTAN, perform a manual review which can take a few days up to weeks. As an example of the stricter flavor, CRAN’s policies say:

CRAN packages should use only the public API. Hence they should not use entry points not declared as API in installed headers nor .Internal() nor .Call() etc calls to base packages. Also, ::: should not be used to access undocumented/internal objects in base packages (nor should other means of access be employed). Such usages can cause packages to break at any time, even in patched versions of R.

General falls in-between these two camps; like npm/pypi/cargo, new packages and new versions can be automatically registered, but unlike those, registration is not immediate. There is a 3 day waiting period for new packages, allowing community comment and review on the registration pull request (15 minutes for new versions). Additionally, anyone can prevent auto-registration by leaving a comment without [noblock], so review has “teeth” in some sense. However, General does not prohibit packages from using internals.

I think the more permissive registries (npm/pypi/cargo) do not necessarily need a policy on vibecoded packages, as they already tend to serve as purely infrastructure without curation (so they allow them), and the stricter registries already have strict policies and manual review (so they have strong mechanisms to push back or reject). That’s not to say neither group will adopt some policies in this area, but I think General is in a bit of a unique place where by being in-between on the permissiveness scale, we need to decide which way to lean in different situations.

Problems with low-effort / unreviewed LLM-written packages

They tend to have a bus factor of 0 where no human actually thought-through and understands the code.

tend to get “looks plausible but difficult to check if it’s actually correct”

complicated structure, unnecessary and verbose code, lengthy documentation

bugs can be more subtle or more hidden compared to equally-buggy code written by a novice human

they can be very quick to produce, which amplifies the other issues

Problems with writing policy or guidance

hard to clearly define what is “vibecoded”

needs to be manually checked

ambiguous rules tend to be applied unevenly

incentivizes authors to hide markers of vide-coding without necessarily solving the problem of lack-of-understanding

Community feedback

What do folks think? Should General be home to vibecoded packages or should it try to prevent them from being registered? What mechanisms/guidance/policies might be effective?

83 posts - 31 participants