LLM Policy for Rust Compiler
github.com
github.com
> These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly.
This section is an extremely useful reference
edit: Wow people did not read the policy. It's literally just "if you use an LLM you are responsible for it, we will reject low quality PRs, please disclose that you have used an LLM". This is bog standard.
> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.
> We carve out a space for "experimentation" to inform future revisions to this policy.
Importantly, the LLM contributions must be solicited, i.e., the people responsible for reviewing the final implementation have to opt in explicitly beforehand.
TBH I think that makes no sense ("I have an LLM written PR ready, can I open it?") but yeah the policy is also in draft and has actually already changed since my first comment.
Are you sure? It says:
"It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to *create*."
That exception is experimental and somewhat limited; Only allows "well tested, high-quality" PRs on parts of the codebase that have a low probability of causing soundness issues, and it has a seperate review process with much higher standards.
And it requires the reviewer to agree to the use of LLMs ahead of time, before the PR is opened.
IMO, it has a high likelihood of degrading to a closed system, where some programmers with a good track record have little issue merging LLM generated PRs, while anyone without a reputation will struggle to even open an ai-assisted PR.
I'm not gonna say no to some system that validates my code before I present it as a PR, and if said system (it being static checking, dynamic checking, or LLM), gives me a 'comment', I will interpret the output, validate, and decide whether to take action, and how.
And maybe there I disagree a little with the proposal. It's me, it's my code. I stand behind it. But I get where the authors come from, and I believe it's a fine compromise.
I think more importantly in the world of Software Engineering we're seeing a split.
On one hand, people who go all-in on AI and take the output as 100% correct, copy-paste it as theirs without reviewing, prompt it to create PRs and submit them as-is, and worse, as their own.
Then there is the other side, people who use AI as a tool to validate and go deeper.
The problem with the first group that everywhere they feel entitled to shift the validation onus from themselves to the receipient of what they're sending, it being PR or review comment or message or whatever.
In PRs now the repo maintainer has to do a lot more work, as they cannot rely on the social construct of "OptionOfT wrote this, they have 10+ years of experience in these and these systems, so we can look at the PR through that lens".
Equally, I've been on the receiving end of AI PR comments (the PR was human-authored), but copy-pasted by humans, presenting the comment as their own, without properly (if anything) validating the correctness of the comment, or whether it actually makes sense for the PR. Lots of derailment there. This now increases the workload of the PR author, as above. We need to validate and cannot rely on the social construct. Is the comment even correct? What's the context? Why? Is it a hallucination?
And the downside is that it looks like the first group is now going faster, but the second group is actually slowing down due to the increased burden.
https://github.com/jyn514/rust-forge/blob/llm-policy/src/pol...
It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways:
> The following are allowed. > Asking an LLM questions about an existing codebase. > Asking an LLM to summarize comments on an issue, PR, or RFC...
Like seriously, what's the point of explicitly allowing this? Imagine the opposite were true, you weren't allowed to do this - what would they do? Revert an update because the person later claimed they checked it with an LLM?
The Linux policy on this is much superior and more sensible.
Explicit permission can be useful to preemptively cut off some questions from well meaning people who, acting in good faith, might otherwise pester for clarification (no matter how silly / "obvious" it might otherwise be), or get agitated by misconstruing an all-banned list as being an overly verbose "no LLMs ever" overreach.
> It's in-line with the 'nanny' stereotype of the Rust community that they give you permission to act in a way they would never be able to verify anyways: [...]
Many of us work or have worked in corporate settings where IT takes great pains to help detect and prevent data exfiltration, and have absolutely installed the corporate spyware to detect those kinds of actions when performed on their own closed source codebases. Others rely on the honor system - at least as far as you know - but still ban such actions out of copyright/trade secret concerns. If you're steeped deeply enough in that NDA-preserving culture, a reminder that you've switched contexts might help when common sense proves uncommon.
While nannying can be obnoxious, I'm not sure that having a document one can point to/link/cite, to allay any raised concerns, counts.
What?
If you've throroughly absorbed a culture of honoring non disclosure agreements (NDAs), which are legal contracts demanding you keep secrets and avoid sharing sensitive data or code...
> a reminder that you've switched contexts might help
A reminder that rust-lang is a transparent, open source project, with no non-disclosure agreements or trade secrets to keep private unto itself might help [1].
> when common sense proves uncommon.
Because everyone misses the "obvious" sometimes. And because "obvious" is a subjective value judgement, meaning people will disagree what is or is not obvious.
-------
1. That said, if you've got a private, corporate-internal, closed source fork, you might still be bound by such concerns. For example, various people have ported rust's stdlib to work on various consoles (xbox, playstation, etc.) - and one of the reasons you don't see that upstreamed is because doing so would require violating console vendor NDAs, as well as possibly their company's NDAs - possibly for such banal reasons as not wanting to leak a hint of a console port or new title before their marketing plans are ready to go to capitilize on any hype.
I would have LOVED if the university course I took last winter had this. I had to take a very paranoid attitude to what was allowed.
What they're trying to avoid is a lot of unnecessary conflict with zealous anti-AI people calling for your exclusion for admitting to doing these things. There are people who would ban this too.
Imagine if they just say "LLMs are banned" then there's a lot of ambiguity. So they specifically outlined that generative uses of LLMs are banned, and that non-generative ones are not banned (i.e. "allowed").
I think it's a poor choice of words on their part, but it makes sense (considering what their policy is). It's more of a "we're not disallowing use in these particular scenarios, so you can still use LLMs for these if you want". Remember: it's a big project, and if they don't explicitly state something then people will ask and waste everyone's time.
But they aren't? Nowhere in the document it says this; in fact, it says the opposite - that they don't want to make a moral judgement.
> It's already bad enough a programming language wants to play politics (doesn't matter what my politics are if I want to code in the c "community")
It also doesn't matter what your politics are in the Rust community. My personal politics don't agree with the majority of prominent Rust contributors either, and that's fine. It doesn't (and hasn't) stopped me from being able to use Rust for over a decade now. Ignore politics and just engage on a purely technical level, and you'll be fine.
Largely true, apart from the trans issue. Refuse to agree a man is a woman because he says it's true, and you're a bigot
A dissenting view.
This is not very different from the Linux kernel's policy so it's an odd comparison. It's actually almost identical in practical terms.
edit: lol proof that this doc needs to be stupidly explicit is in the pudding with the HN comments going out of their way to radically misread it
Will it fix a related but different problem? Likely.
The birth of vibe coding has seen interactions on public FOSS projects increasingly reminiscent of the flame wars and moderator hammers of the old forum days. A lot of projects have been behind the curve on preparing and codifying the hammers, probably because no maintainer really wants to be a moderator, but thats where its naturally landed unfortunately.
Yeah this is autistic bunk. If you run an open source project, dealing with people is part and parcel of it, disagreements as well.
Before you knee jerk hate on the team for being luddites, consider:
1. For a language like rust there’s too few eyes and too many mouths. Reviewing is a job, and is extremely taxing. 2. The code base needs to be highly hermetic because it’s load bearing across the global economy 3. Most changes are only relevant if they’ve followed extensive process, including community feedback.
> Using an LLM to discover bugs, as long as you personally verify the bug, write it up yourself, and disclose that an LLM was used.
What are they going to do go back and reject a bug if someone later admits they found it with an LLM? Honestly they and most other project would probably be better off just ignoring the situation until norms start developing.
If they get swamped with 100 bugs that turned out, after they investigate them to be hallucinations then it's likely they will ignore or lose in the noise a real bug.
A llm generated bug that pretends it was a human created bug would be trying to abuse that presumption of validity, and therefore considered a dick move.
But theyre saying if they're 100 correct bug reports it's still banned.
That's hysterical
That's the baby out with the bathwater.
If you want to interact with their project, follow their rules on their terms, otherwise just grab the binaries and don't stir things up.
That's in the "allowed with caveats" section. It's just saying to not open bug reports without first reading them yourself or your bug may be closed. No one is saying "by policy we will have to add the bug back in" jesus christ
The policy is insanely straightforward, idk how you can be misinterpreting it this badly. It's just "Disclose that you use a model, you are on the hook for reviewing model output as a human" and then some clear cut examples.
At this point they will probably just fork yet again and maintain some vibe compiler.
[0]: https://x.com/jarredsumner/status/2051600118886138262
This policy does not seem to forbid vibe coding?
> Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure.
Vibe coding (in its original meaning) would have hard time arguing it's of high quality.
> People must be vouched for before interacting with certain parts of a project (the exact parts are configurable to the project to enforce).
https://github.com/mitchellh/vouch
I think many projects will adopt this instead of allowing everyone / blocking everyone
Many projects have "ai slop" check in place to directly close and ban user if it is "ai slop". Else, it will be hard to handle the velocity of PRs
I don't know if having your name/ face a secret is still acceptable? Maybe tiers of devs (anon vs other) on that one?