The exact rules on LLM generated code submission live here:<p><a href="https://forge.rust-lang.org/policies/llm-usage.html" rel="nofollow">https://forge.rust-lang.org/policies/llm-usage.html</a><p><a href="https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html" rel="nofollow">https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.h...</a><p>> Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.<p>They clearly put a lot of thought into this and it shows. Huge respect.<p>> New contributors cannot create a PR using an LLM unless they first talk with a reviewer.<p>New contributors do not have community connections. I don't know any rust-lang/rust reviewer.<p>What is the correct procedure for this?<p>> Harassment is not allowed.<p>> You may not harass people for using an LLM, regardless of whether or not their use is banned by the policy.<p>Refreshing take. Not a fan of heavy handed moderation, but I'm still very happy to see that they have this stance given the racism-tier insults I've gotten on forums without it.<p>I especially like this rule:<p>> Don’t try to be the police for whether someone has used an LLM. You are not required to “actively look” for whether an LLM was involved.
> New contributors do not have community connections. I don't know any rust-lang/rust reviewer.
> What is the correct procedure for this?<p>there's a #llm-mentoring [0] Zulip stream linked in the dev-guide [1].<p>[0]: <a href="https://rust-lang.zulipchat.com/join/rlfvpemsaacs3pfi6kwqnqjb/" rel="nofollow">https://rust-lang.zulipchat.com/join/rlfvpemsaacs3pfi6kwqnqj...</a>
[1]: <a href="https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.html#before-you-write-code" rel="nofollow">https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.h...</a>
> What is the correct procedure for this?<p>in general to work on something that will get "into the rust compiler" it needs at least an RFC and then a Major Change Proposal [0]<p>in practice it starts with asking on zulip [1]<p>[0] <a href="https://forge.rust-lang.org/compiler/proposals-and-stabilization.html" rel="nofollow">https://forge.rust-lang.org/compiler/proposals-and-stabiliza...</a><p>[1] <a href="https://forge.rust-lang.org/how-to-start-contributing.html" rel="nofollow">https://forge.rust-lang.org/how-to-start-contributing.html</a>
> What is the correct procedure for this?<p>Get involved with the project before submitting PRs, participate in discussions, etc. But if it's a change you want to contribute, don't use an LLM to write it.
> But if it's a change you want to contribute, don't use an LLM to write it.<p>The rules I quoted say LLM code generation is allowed should the developer contact a reviewer first and they agree to review it.<p>My question was about the exact procedure and etiquette for contacting these reviewers. For example, Linux has a get_maintainer.pl people can use to figure out who to email should they want to contribute something.
I <i>really</i> dislike every kind of rule that says something along the lines "if it's LLM generated you must self-disclose otherwise it is against the rules". Because this quickly leads to witch hunting and easy persecution of IC's under the pretense "it looks generated by an LLM" or they just investigate you and put you on cooldown from being able to contribute while they check for signs of "LLM-generated code". It's no different than laws giving any officer the right to violate your rights based on flaky probable cause "you have slurred speech therefore I will search your car to see any open containers". This can lead to a soft coup by anti-llm individuals which will make communities slowly drift towards a group of elitists that gatekeep any newcomer.
I don't disagree with you. I too hate disclosing LLM usage. I hate giving free advertising to trillion dollar corporations. There's also the fact people will probably look down on me for it and assume I'm incompetent because I used an LLM, and I've actually ended up sitting on reviewed and tested patches to open source projects because of this.<p>However, we should be polite and respect their house rules. They are being reasonable and even made an effort to preempt these exact objections:<p>> Harassment is not allowed.<p>> You may not harass people for using an LLM, regardless of whether or not their use is banned by the policy.<p>> Don’t try to be the police for whether someone has used an LLM. You are not required to “actively look” for whether an LLM was involved.
I don't understand this obsession with clear cut categorization. Systems always have a human component and while we like to collectively deny this fact from a tech-sphere, there are always humans that will make the final call and if anything we should encourage the use of human trust and judgement.<p>We have focused so much on technological advancement, but our understanding of human systems and building an environment of trust that is not eroded by perverse incentives atrophies.
imho disclosing use of LLMs is just being transparent and honest. is it that hard? deliberately hiding this should absolutely get you in trouble, because trust is the most important thing to have in open-source<p>as you probably have seen in TFA, the policy does not ban LLM usage. its just asking for disclosure so that maintainers know how much effort was put in a PR<p>and, please, open-source maintainers owe us nothing. refusing to merge a patch is not the same as cops searching your car. this is merely maintainers trying to evaluate how they should spend their precious time
I sort of agree, but sort of not. I do agree that any use of AI should be disclosed, but I have also seen some subreddits where the top comments of every post is either raging about the use of AI, or arguing about AI when AI wasn't used.<p>It's just so tiresome
> <i>Harassment is not allowed</i>. You may not harass people for using an LLM, regardless of whether or not their use is banned by the policy. You must follow the Code of Conduct at all times when interacting with the Rust project.<p>This policy I like.
In a nutshell: It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.
Yes, and I think the reasons set out in TFA are interesting, which on my reading are:<p>1) Code is the least interesting bit in some ways - they’re trying to build not only rust but a community of experts around rust which is able to maintain and improve it in the long term and the authors of prs need to understand the code deeply and show a willingness to be part of that long run. Llm-generated code even if it looks polished doesn’t indicate a human author who deeply understands it and is willing to be part of that long term maintenance.<p>2) They don’t have (and don’t want to enforce) a community consensus that llms are good or llms are bad. They just want some rules written down so everyone knows where they stand and people of either camp (and none) can get on with it.<p>Seems a pretty reasonable approach to me although I don’t really use rust much so don’t have a vested interest.
[flagged]
No codebase worth being deeply invested in is deeply understood by anyone, including the original authors. The eternal maintenance argument is tiresome. If there is a problem in need of fixing, you figure it out, you do not depend on some author being available, and LLMs are exceptionally helpful in this regard as well. Then, if the LLM has trouble figuring out, so will another human. It is a code smell.
There are all kinds of projects out there that have had significant impact on the world, which were written and maintained over the course of years by a single, highly capable developer. The way people talk about code nowadays, just because they have more powerful authoring tools, is frankly disgraceful. Imagine if modern construction techniques had become a reason to stop caring about the natural beauty of wood grain.
Creation is still allowed:<p>>Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.
It's technically an experiment, but it's definitely good to see they're keeping an open mind about this.<p>> Experiment: LLM-created code changes intended for review<p>> We leave space open to experiment with LLMs to inform future policies.<p>> This experiment is meant to inform future non-experimental policy, not to serve as the perpetual LLM usage policy.
Hmm, that doesn't sound too bad. So you basically get to use a tool to help with the tedious parts, without being allowed to use the same tool to pass off said tedium to others.<p>This closes the gap. A key insight. A load bearing difference.<p>Now, is writing code considered tedium, for a project like Rust?
Sounds like the beginning of the end of rust to me<p>AI is a jet engine - Banning is for creation is like saying "we require you to go by ship/car/propeller-plane"<p>Yes, a policy that says AI slop PRs will not be tolerated. But I've had AI track down real hard to find bugs in several projects and provide correct fixes. I've also had AI build new features and new products. The project that ignores this acceleration will eventually fall behind the ones that embrace it.
I love how your analogy actually works with the real world. You can't fly a jet plane until you've got all the various licenses and logged flying hours in prop planes first.
"AI is a jet engine "<p>and rust just wants to ensure you are a capable pilot that can actually steer a plane before stealing everyone else's attention
Why does a language need higher developer velocity? Why is acceleration needed?<p>Acceleration makes sense for end user applications, where you're allowed to break whatever you see fit, but I don't see how it helps with core infrastructure like a programming language, where every mistake is multiplied a million fold.
Exactly this. There's plenty of boring software out there where writing the actual code is a chore. That's where AI works pretty well, as long as the people at the controls understand and can explain the problem and non-functionals.<p>For projects like Rust, coding velocity is not the bottleneck, speed / productivity is not a priority.
you're free to fork and improve it with your favorite harness. Go get 'em tiger.
Good rules but Rust already has AI code in its codebase now.
The question is: is such policy even enforceable? If someone is "clever" enough to drop em-dashes and some bold highlights how one would know if something is AI generated or not?
> Some parts of the policy are unenforceable. This is not a bug. The goal is not to catch every violation, but to create a clear bright-line rule: Disclosure is required for all public LLM text, unless specifically exempted by the policy. This allows moderators to identify violations based on actions, not on intent, and only consider intent when deciding how to respond.