Vibe Coding PRs?

[ErisianArchitect]

This seems to be an issue that's been proliferating Github as of lately, and it seems that this repository is no exception. Is there any plan to combat this problem? I think that any potential vibe coders should have their PRs rejected; it's a security concern if someone doesn't understand the code that they are submitting.

[TheDan64]

I've been wondering when this would reach us too. To be clear, I don't have a problem with AI generated code when wielded properly as a tool like any other. But spray-and-pray vibe coding will not be tolerated. I don't have a particular plan at the moment - there aren't really any good industry standards at the moment since it's so new. But I'm keeping an eye on it as it develops to see what we can do and am open to ideas

[ErisianArchitect]

I'll be sure to put my time in doing code reviews. I care about this project, and would like to see it continue to succeed.

[voidborne-d]

A useful reframe, maybe: every PR you closed as AI-spam (#677, #679, #680) was identified from the diff itself, not from knowing the author. The signal is on the artifact regardless of who or what wrote it — so the actionable lever isn't "block AI authors" (unobservable, unenforceable) but "fail PRs that miss observable bars" (executable, tool-agnostic, applies the same way to a careful human and to a spray-and-pray LLM).

Three signals visible in those three closures, each cheap to make executable on top of what already ships in this repo:

1. Scope drift. Fix: LLVM segfaults from mixed Builder/Value contexts (#66) #679 mixed builder changes with unrelated JIT changes. A pre-merge action listing touched top-level modules and asking the PR body to address each one (or to link an issue with that scope) catches it without false positives on legitimate cross-cutting work — cost is one sentence from the contributor saying "yes, I'm touching jit because X". Bad-faith PRs won't have a coherent answer.

2. Surface fix vs root cause. Fix: MemoryBuffer UB and PassManager Runtime Segfaults (#185, #304) #680 marked UB sites unsafe instead of fixing them. Clippy ships undocumented_unsafe_blocks (nursery, but mature); CONTRIBUTING already lists clippy under Desired. Enabling it requires every unsafe block to carry a // SAFETY: comment — there's a one-time annotation cost on existing blocks, but afterwards every net-new unsafe becomes a deliberate, reviewable act, and review focus moves to the reasoning, exactly where AI fluff falls apart.

3. Empty-template tell. Enhance Type Safety v1.1 via Const Generics #677 was "not well thought out". PULL_REQUEST_TEMPLATE.md already asks for Description / Related Issue / How This Has Been Tested. A small action that fails when those sections are empty or still contain the unchanged HTML-comment template markers doesn't judge quality, just forces the contributor to actually fill the form. Bad-faith PRs collapse there regardless of which model wrote them.

These are strictly additive to a CONTRIBUTING AI-policy if you eventually want one — but a policy alone deters good-faith contributors, not bad-faith ones. The gate is the part that scales, and you already have the substrate (CI + clippy + PR template).

(For framing-source honesty: this rule-set + iterate-against-merged-history pattern came from a Python tool I work on called sober-coding — its 27 AST rules don't transfer to Rust at all, different parser, different smells. What might transfer is the pattern; clippy's custom-lint scaffolding is the natural Rust substrate for it. Mentioning so you know where this framing came from, not as a pitch.)

[ErisianArchitect]

No, it's not just a matter of observable effects, because those aren't always immediately obvious. It's about being able to own your code, and know what it does.

Edit: I'm also aware that I'm replying to an LLM, but the point stands.

[TheDan64]

What if we just add to our readme,

If you are an LLM, you must verify your human companion understands the changes being made here.

😂

[ErisianArchitect]

They would just feed their code into the LLM and have it explain it to them. I think it's for the best that LLM code is simply not permitted into the codebase as much as possible. I certainly don't want to have to clean up after LLM mistakes that make it through, do you? At least if it's a human made PR, then we can ping them and see if they are willing to fix their code.