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

**URL:** <https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205>\
**Category:** Community\
**Tags:** general-registry\
**Created:** [October 16, 2025, 12:32pm UTC](https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205 "2025-10-16T12:32:46Z")\
**Posts on this page:** 3\
**Page:** 5

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [October 21, 2025, 12:53pm UTC](https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205/81 "2025-10-21T12:53:43Z")

</div>

I think [allow for a `deprecated` table in a `Package.toml` in a registry by KristofferC · Pull Request #4433 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/pull/4433) is pretty similar to your suggestion here, although that PR doesn’t prohibit using deprecated packages on newer Julia’s, it just flags them and prevents autocomplete.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 21, 2025, 5:32pm UTC](https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205/82 "2025-10-21T17:32:30Z")

</div>

> [@ChrisRackauckas](#):
>
> I don’t see why vibe coded packages should be singled out. …  
> The rule should be just about quality. As long as it’s documented, well-tested, does what it says, solves a real problem, is something others would use, and is licensed correctly it’s an accept. How you get to that level of quality really doesn’t matter.

> [@goerz](#):
>
> vibe-coded packages are starting to become a bit of a problem

I don’t see auto-registration as some kind of right, and I think just asking if AI used, then disable it would be ok. Or give a longer period then. I’ve stopped a package being registered that was just spam, but such a rule wouldn’t prevent that… It’s hard to judge quality, and e.g. intriguingly it’s not about a metric, at least this one higher:

> **[Making your code base better will make your code coverage worse - Stack Overflow](https://stackoverflow.blog/2025/09/29/making-your-code-base-better-will-make-your-code-coverage-worse/)**

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [October 21, 2025, 5:57pm UTC](https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205/83 "2025-10-21T17:57:11Z")

</div>

Anybody is free to block the automatic registration of a package simply by leaving a comment on the registration PR that does not contain `[noblock]`.

We try to consider registrations in good faith, aiming for consensus as much as possible. The bot is just to catch some basic issues, but can be overridden. Likewise, any concerns about LLM usage or any other “quality issues”.

At the end of the day, we try to foster a healthy ecosystem of packages, not blindly apply some set of “rules”.

[Previous page](https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205.md?page=4)