- Notifications You must be signed in to change notification settings
- Fork 233
- Star 538
- Code
- Issues 15
- Pull requests 14
- Actions
- Projects
- Security and quality 0
- Insights
Add an LLM policy for rust-lang/rust#1040
Conversation
jyn514
commented
Apr 17, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
FCP link
this comment
Summary
This document establishes a policy for how LLMs can be used when contributing to rust-lang/rust. Subtrees, submodules, and dependencies from crates.io are not in scope. Other repositories in the rust-lang organization are not in scope.
This policy is intended to live in Forge as a living document, not as a dead RFC. It will be linked from CONTRIBUTING.md in rust-lang/rust as well as from the rustc- and std-dev-guides.
Moderation guidelines
This PR is preceded by an enormous amount of discussion on Zulip. Almost every conceivable angle has been discussed to death; there have been upwards of 3000 messages, not even counting discussion on GitHub. We initially doubted whether we could reach consensus at all.
Therefore, we ask to bound the scope of this PR specifically to the policy itself. In particular, we mark several topics as out of scope below. We still consider these topics to be important, we simply do not believe this is the right place to discuss them.
No comment on this PR may mention the following topics:
- Long-term social or economic impact of LLMs
- The environmental impact of LLMs
- Anything to do with the copyright status of LLM output
- Moral judgements about people who use LLMs
We have asked the moderation team to help us enforce these rules.
Feedback guidelines
We are aware that parts of this policy will make some people very unhappy. As you are reading, we ask you to consider the following.
- Can you think of a concrete improvement to the policy that addresses your concern? Consider:
- Whether your change will make the policy harder to moderate
- Whether your change will make it harder to come to a consensus
- Does your concern need to be addressed before merging or can it be addressed in a follow-up?
- Keep in mind the cost of not creating a policy.
If your concern is for yourself or for your team
- What are the specific parts of your workflow that will be disrupted?
- In particular we are only interested in workflows involving
rust-lang/rust. Other repositories are not affected by this policy and are therefore not in scope.
- In particular we are only interested in workflows involving
- Can you live with the disruption? Is it worth blocking the policy over?
Previous versions of this document were discussed on Zulip, and we have made edits in responses to suggestions there.
Motivation
- Many people find LLM-generated code and writing deeply unpleasant to read or review.
- Many people find LLMs to be a significant aid to learning and discovery.
rust-lang/rustis currently dealing with a deluge of low-effort "slop" PRs primarily authored by LLMs.- Having a policy makes these easier to moderate, without having to take every single instance on a case-by-case basis.
This policy is not intended as a debate over whether LLMs are a good or bad idea, nor over the long-term impact of LLMs. It is only intended to set out the future policy of rust-lang/rust itself.
Drawbacks
- This bans some valid usages of LLMs. We intentionally err on the side of banning too much rather than too little in order to make the policy easy to understand and moderate.
- This intentionally does not address the moral, social, and environmental impacts of LLMs. These topics have been extensively discussed on Zulip without reaching consensus, but this policy is relevant regardless of the outcome of these discussions.
- This intentionally does not attempt to set a project-wide policy. We have attempted to come to a consensus for upwards of a month without significant progress. We are cutting our losses so we can have something rather than adhoc moderation decisions.
- This intentionally does not apply to subtrees of rust-lang/rust. We don't have the same moderation issues there, so we don't have time pressure to set a policy in the same way.
Rationale and alternatives
- We could create a project-wide policy, rather than scoping it to
rust-lang/rust. This has the advantage that everyone knows what the policy is everywhere, and that it's easy to make things part of the mono-repo at a later date. It has the disadvantage that we think it is nigh-impossible to get everyone to agree. There are also reasons for teams to have different policies; for example, the standard for correctness is much higher within the compiler than within Clippy. - We could have different standards for people in the Rust project than for new contributors. That would make moderation much easier, and allow us to experiment with additional LLM use. However, it reinforces existing power structures, creates more of a gap between authors and reviewers, and feels "unfriendly" to new contributors.
- We could have a more lenient policy that allows "responsible and appropriate" use of LLMs. This raises the question of what "responsible and appropriate" means. The usual suggestion is "self-review, and judging the change by the same standard as any other change"; but this neglects the reputational and social harm of work that "feels" LLM generated. It also makes our moderation policy much harder to understand, and increases the likelihood of re-litigating each moderation decision.
- We could have a more strict policy that removes the threshold of originality condition. This has the advantage that our policy becomes easier to moderate and understand. It has the disadvantage that it becomes easy for people to intend to follow the policy, but be put in a position where their only choices are to either discard the PR altogether, rewrite it from scratch, or tell "white lies" about whether an LLM was involved.
- We could have a more strict policy that bans LLMs altogether. It seems unlikely we will be able to agree on this, and we believe attempting it will cause many people to leave the project.
Prior art
This prior art section is taken almost entirely from Jane Lusby's summary of her research, although we have taken the liberty of moving the Rust project's prior art to the top. We thank her for her help.
Rust
- Moderation team's spam policy
- Compiler team's "burdensome PRs" policy
Other organizations
These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly.
- full ban
- postmarketOS - also explicitly bans encouraging others to use AI for solving problems related to postmarketOS - multi point ethics based rational with citations included
- zig
- philosophical, cites Profession (novella)
- rooted in concerns around the construction and origins of original thought
- servo
- more pragmatic, directly lists concerns around ai, fairly concise
- qemu
- pragmatic, focuses on copyright and licensing concerns
- explicitly allows AI for exploring api, debugging, and other non generative assistance, other policies do not explicitly ban this or mention it in any way
- allowed with supervision, human is ultimately responsible
- scipy
- strict attribution policy including name of model
- llvm
- blender
- linux kernel
- quite concise but otherwise seems the same as many in this category
- mesa
- framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors.
Understand the code you write at least well enough to be able to explain why your changes are beneficial to the project.
- framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors.
- forgejo
- bans AI for review, does not explicitly require contributors to understand code generated by ai. One could interpret the "accountability for contribution lies with contributor even if AI is used" line as implying this requirement, though their version seems poorly worded imo.
- firefox
- ghostty
- pro-AI but views "bad users" as the source of issues with it and the only reason for what ghostty considers a "strict AI policy"
- fedora
- clearly inspired and is cited by many of the above, but is definitely framed more pro-ai than the derived policies tend to be
- scipy
- curl
- does not explicitly require humans understand contributions, otherwise policy is similar to above policies
- linux foundation
- encourages usage, focuses on legal liability, mentions that tooling exists to help automate managing legal liability, does not mention specific tools
- In progress
- NixOS
- How do we deal with AI-generated issues? NixOS/nixpkgs#410741
- NixOS
Unresolved questions
See the "Moderation guidelines" and "Drawbacks" section for a list of topics that are out of scope.
Rendered
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👍 20 jdonszelmann, aDotInTheVoid, nnethercote, jieyouxu, Kobzol, oli-obk, thomcc, cyrgani, alice-i-cecile, HactarCE, and 10 more reacted with thumbs up emoji ❤️ 20 jdonszelmann, jieyouxu, nnethercote, scrabsha, Kobzol, oli-obk, thomcc, alice-i-cecile, HactarCE, TheElectronWill, and 10 more reacted with heart emoji All reactions- 👍 20 reactions
- ❤️ 20 reactions
rustbot commented Apr 17, 2026
|
r? @jieyouxu rustbot has assigned @jieyouxu. Use The reviewer was selected based on:
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
jyn514 commented Apr 17, 2026
|
@rustbot label T-libs T-compiler T-rustdoc T-bootstrap |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Apr 17, 2026 [blocked] Link to proposed LLM policy rust-lang/rustc-dev-guide#2835 Draft [blocked] Link to the proposed LLM policy rust-lang/std-dev-guide#75 Draft
Add an LLM policy for rust-lang/rust
…
772edeb
## Summary
[summary]: #summary
This document establishes a policy for how LLMs can be used when contributing to `rust-lang/rust`.
Subtrees, submodules, and dependencies from crates.io are not in scope.
Other repositories in the `rust-lang` organization are not in scope.
This policy is intended to live in [Forge](https://forge.rust-lang.org/) as a living document, not as a dead RFC.
It will be linked from `CONTRIBUTING.md` in rust-lang/rust as well as from the rustc- and std-dev-guides.
## Moderation guidelines
This PR is preceded by [an enormous amount of discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/588130-project-llm-policy).
Almost every conceivable angle has been discussed to death;
there have been upwards of 3000 messages, not even counting discussion on GitHub.
We initially doubted whether we could reach consensus at all.
Therefore, we ask to bound the scope of this PR specifically to the policy itself.
In particular, we mark several topics as out of scope below.
We still consider these topics to be important, we simply do not believe this is the right place to discuss them.
No comment on this PR may mention the following topics:
- Long-term social or economic impact of LLMs
- The environmental impact of LLMs
- Anything to do with the copyright status of LLM output
- Moral judgements about people who use LLMs
We have asked the moderation team to help us enforce these rules.
## Feedback guidelines
We are aware that parts of this policy will make some people very unhappy.
As you are reading, we ask you to consider the following.
- Can you think of a *concrete* improvement to the policy that addresses your concern? Consider:
- Whether your change will make the policy harder to moderate
- Whether your change will make it harder to come to a consensus
- Does your concern need to be addressed before merging or can it be addressed in a follow-up?
- Keep in mind the cost of *not* creating a policy.
### If your concern is for yourself or for your team
- What are the *specific* parts of your workflow that will be disrupted?
- In particular we are *only* interested in workflows involving `rust-lang/rust`.
Other repositories are not affected by this policy and are therefore not in scope.
- Can you live with the disruption? Is it worth blocking the policy over?
---
Previous versions of this document were discussed on Zulip, and we have made edits in responses to suggestions there.
## Motivation
[motivation]: #motivation
- Many people find LLM-generated code and writing deeply unpleasant to read or review.
- Many people find LLMs to be a significant aid to learning and discovery.
- `rust-lang/rust` is currently dealing with a deluge of low-effort "slop" PRs primarily authored by LLMs.
- Having *a* policy makes these easier to moderate, without having to take every single instance on a case-by-case basis.
This policy is *not* intended as a debate over whether LLMs are a good or bad idea, nor over the long-term impact of LLMs.
It is only intended to set out the future policy of `rust-lang/rust` itself.
## Drawbacks
[drawbacks]: #drawbacks
- This bans some valid usages of LLMs.
We intentionally err on the side of banning too much rather than too little in order to make the policy easy to understand and moderate.
- This intentionally does not address the moral, social, and environmental impacts of LLMs.
These topics have been extensively discussed on Zulip without reaching consensus, but this policy is relevant regardless of the outcome of these discussions.
- This intentionally does not attempt to set a project-wide policy.
We have attempted to come to a consensus for upwards of a month without significant process.
We are cutting our losses so we can have *something* rather than adhoc moderation decisions.
- This intentionally does not apply to subtrees of rust-lang/rust.
We don't have the same moderation issues there, so we don't have time pressure to set a policy in the same way.
## Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives
- We could create a project-wide policy, rather than scoping it to `rust-lang/rust`.
This has the advantage that everyone knows what the policy is everywhere, and that it's easy to make things part of the mono-repo at a later date.
It has the disadvantage that we think it is nigh-impossible to get everyone to agree.
There are also reasons for teams to have different policies; for example, the standard for correctness is much higher within the compiler than within Clippy.
- We could have a more strict policy that removes the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html) condition.
This has the advantage that our policy becomes easier to moderate and understand.
It has the disadvantage that it becomes easy for people to intend to
follow the policy, but be put in a position where their only choices
are to either discard the PR altogether, rewrite it from scratch, or
tell "white lies" about whether an LLM was involved.
- We could have a more strict policy that bans LLMs altogether.
It seems unlikely we will be able to agree on this, and we believe attempting it will cause many people to leave the project.
## Prior art
[prior-art]: #prior-art
This prior art section is taken almost entirely from [Jane Lusby's summary of her research](rust-lang/leadership-council#273 (comment)),
although we have taken the liberty of moving the Rust project's prior art to the top.
We thank her for her help.
### Rust
- [Moderation team's spam policy](https://github.com/rust-lang/moderation-team/blob/main/policies/spam.md/#fully-or-partially-automated-contribs)
- [Compiler team's "burdensome PRs" policy](rust-lang/compiler-team#893)
### Other organizations
These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly.
- full ban
- [postmarketOS](https://docs.postmarketos.org/policies-and-processes/development/ai-policy.html)
- also explicitly bans encouraging others to use AI for solving problems related to postmarketOS
- multi point ethics based rational with citations included
- [zig](https://ziglang.org/code-of-conduct/)
- philosophical, cites [Profession (novella)](https://en.wikipedia.org/wiki/Profession_(novella))
- rooted in concerns around the construction and origins of original thought
- [servo](https://book.servo.org/contributing/getting-started.html#ai-contributions)
- more pragmatic, directly lists concerns around ai, fairly concise
- [qemu](https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators)
- pragmatic, focuses on copyright and licensing concerns
- explicitly allows AI for exploring api, debugging, and other non generative assistance, other policies do not explicitly ban this or mention it in any way
- allowed with supervision, human is ultimately responsible
- [scipy](https://github.com/scipy/scipy/pull/24583/changes)
- strict attribution policy including name of model
- [llvm](https://llvm.org/docs/AIToolPolicy.html)
- [blender](https://devtalk.blender.org/t/ai-contributions-policy/44202)
- [linux kernel](https://kernel.org/doc/html/next/process/coding-assistants.html)
- quite concise but otherwise seems the same as many in this category
- [mesa](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/submittingpatches.rst)
- framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors.
> Understand the code you write at least well enough to be able to explain why your changes are beneficial to the project.
- [forgejo](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md)
- bans AI for review, does not explicitly require contributors to understand code generated by ai.
One could interpret the "accountability for contribution lies with contributor even if AI is used" line as implying this requirement, though their version seems poorly worded imo.
- [firefox](https://firefox-source-docs.mozilla.org/contributing/ai-coding.html)
- [ghostty](https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md)
- pro-AI but views "bad users" as the source of issues with it and the only reason for what ghostty considers a "strict AI policy"
- [fedora](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/)
- clearly inspired and is cited by many of the above, but is definitely framed more pro-ai than the derived policies tend to be
- [curl](https://curl.se/dev/contribute.html#on-ai-use-in-curl)
- does not explicitly require humans understand contributions, otherwise policy is similar to above policies
- [linux foundation](https://www.linuxfoundation.org/legal/generative-ai)
- encourages usage, focuses on legal liability, mentions that tooling exists to help automate managing legal liability, does not mention specific tools
- In progress
- NixOS
- NixOS/nixpkgs#410741
## Unresolved questions
[unresolved-questions]: #unresolved-questions
See the "Moderation guidelines" and "Drawbacks" section for a list of topics that are out of scope.
1c6c4ed to
772edeb
Compare
April 17, 2026 09:23
jieyouxu
left a comment
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI really like this version, and thanks a ton for working on it. Specifically:
- It doesn't try to dump entire walls of text, which is unfortunately a good way to be sure nobody reads it. Instead, it gives you concrete examples, and a guiding rule-of-thumb for uncovered scenarios, and acknowledges upfront that it surely cannot be exhaustive.
- I also like where it points out the nuance and recognizes the uncertainties.
- I like that it covers both "producers" and "consumers" (with nuance that reviewers can also technically use LLMs in ways that are frustrating to the PR authors!)
I left a few suggestions / nits, but even without them this is still a very good start IMO.
(Will not leave an explicit approval until we establish wider consensus, which likely will take the form of 4-team joint FCP.)
View changes since this review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
❤️ 3 jyn514, joshtriplett, and lumi-me-not reacted with heart emoji All reactions- ❤️ 3 reactions
Uh oh!
There was an error while loading. Please reload this page.
Comment thread src/policies/llm-usage.md Outdated Show resolved Hide resolvedUh oh!
There was an error while loading. Please reload this page.
Comment thread src/policies/llm-usage.md Show resolved Hide resolvedUh oh!
There was an error while loading. Please reload this page.
Comment thread src/policies/llm-usage.md Outdated Show resolved Hide resolvedUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ChayimFriedman2 commented Apr 17, 2026
|
The links to Zulip are project-private, FWIW. |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
address some of jieyouxu's comments
815da6e
jyn514 commented Apr 17, 2026
I'm aware. This PR is targeted towards Rust project members moreso than the broad community. |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
davidtwco
left a comment
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI'm happy with this as an initial policy for the rust-lang/rust repository.
View changes since this review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
❤️ 6 jdonszelmann, jyn514, Urgau, Kobzol, ShoyuVanilla, and lumi-me-not reacted with heart emoji All reactions- ❤️ 6 reactions
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
revert extraneous change
17a35f4
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Manishearth
commented
May 13, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
|
@rust-rfcbot concern clearly-marked-ai-generated-reports More details in #1040 (comment) . I think explicitly allowing clearly marked, vetted, AI-generated reports be attached to PRs/issues is something we will have to do in order to not impede security work. |
- 👍 3 reactions
- 👎 1 reaction
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
jyn514 and others added 5 commits May 13, 2026 21:25
Note that explicitly marking LLM content is ok
69b6dc1
Exempt t-security-response from a few requirements
d682475
Make "solicited" even stricter
ea4e504
Carve out a space for experimentation
7eeecbb
Revert "Exempt t-security-response from a few requirements"
…
cd9aecd
They don't actually need the exemption, being able to post the security report is enough for their needs. This reverts commit d682475.
Manishearth commented May 13, 2026
|
@rust-rfcbot resolve clearly-marked-ai-generated-reports This is addressed by:
AI-generated reports are supplemental material, so that's fine. We still expect issues/PRs to be readable without needing to go through the report. Regarding the reverted change about T-security-response; overall security-response doesn't write much code. There is a small chance that we will end up in a situation where Mythos/etc file piles and piles of low grade issues and the libs team needs to rely on LLMs to fix them faster, and if that's the case then that exemption can be explicitly requested (it would be a nontrivial conversation; LLM use to fix security issues is a complex topic). security-response's needs are sufficiently handled by being able to quote reports in issues/PRs. |
- ❤️ 1 reaction
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Kobzol commented May 13, 2026
I don't think that this is the same as Symposium. That was accepting an AI-related initiative as a Project Goal, which is something that IMO clearly reflects on the Project as a whole just by its name, and exposes us to it ("our Goal is to change Rust to be better for AI", or something along those lines). Eventually, you pushed Symposium to be in RIL, which certainly also counts as a non-trivial endorsement, but this decision has received no official support from any Rust teams at all, I agree that having a policy for I have to say that I also share jyn's dissatisfaction about the way you presented the procedural concern. Jack has presented a specific concern about things in the policy that he finds are too limiting. That is a good approach; we can do targeted text changes to resolve that specific concern, and move on. But I don't understand why you file a procedural concern at this point. This policy was specifically designed to not be Project-wide, to target the repository where AI currently hurts us the most, and to be FCPed by the teams that actually do most of their work in this repository. Going to LC subverts the original motivation of the policy, which was explicitly created to NOT be Project-wide, and to not have to go through the LC, in order to have any chance of landing in a reasonable timeframe (where reasonable would IMO be something like a few months ago, but things got complicated, so at the very least we should try to move forward with the best policy that we have at the moment). Why haven't you filed this concern a month ago? If we knew that such a concern would exist, we might as well just not try at all, because this is exactly the same filibuster that already stopped several previous policies in their tracks. The pattern repeats all over again:
I specifically asked you about this literally a month ago, just to avoid this situation (a policy being taken over to be converted to Project-wide and thus blocked) from happening yet again. |
- ❤️ 8 reactions
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
| - "Trivial" code changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html). | ||
| - ℹ️ Be cautious about PRs that consist solely of trivial changes. | ||
| See also [the compiler team's typo fix policy](https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation:~:text=Please%20notice%20that%20we%20don%E2%80%99t%20accept%20typography%2Fspellcheck%20fixes%20to%20internal%20documentation). | ||
| - Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM. |
jackh726
May 13, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentCan talk more about this elsewhere but this doesn't resolve the concern for me. Thoughts:
-
I would try to be a bit stronger with "solicited" - using the word "discouraged from using an LLM unless they first talk with a reviewer" kind of weakens general point. In my mind, someone coming and making a PR that has LLM-generated code in it, without having first talked to a reviewer, is grounds for an instant-reject. Along these lines, I want to be clear that it's not just any reviewer that can say "yes you can make a PR with LLM-generated code" but that they have to do the review.
-
It is not okay to have to ping an entire team to merge any LLM-generated code. This falls under "well-reviewed" and "high-quality" to me: if the reviewer is not confident in the changes, they shouldn't be merging it. We trust our reviewers, and this is not trust.
-
I don't completely agree with the examples of "changes that occasionally affect soundness", and I also am not sure I like the word "discourage". Ultimately, I think the two prior lines cover enough. If anything, you could say something like "Changes that can be tricky if done improperly should undergo additional scrutiny by both the reviewer and author"
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactionsDarksonn commented May 13, 2026
The policy bans the number one most important use-case of LLMs in the programming space (writing code), so of course it can be seen as an anti-AI policy. Allowing some other use-cases of LLMs doesn't change that. Reading it that way requires no bad faith. |
- ❤️ 1 reaction
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Kobzol commented May 13, 2026
|
I personally consider writing code to be one of the less interesting use-cases of LLMs in the programming space, so it is definitely not the most important use-case to me; it depends. The policy also does not actually completely ban writing code with LLMs either, in its current form. In the end, potentially any action done by any Project member can be seen as speaking for the Project. If I (or anyone else) tweet that I vibe-code 95% of my software, people may interpret it as Rust going all-in on AI. If I share that I don't like LLMs and would never use them, some people may interpret that as Rust being anti-AI. All the comments in this public GitHub PR thread can be interpreted positively or negatively by either side. My point was that this policy is very (almost painfully) nuanced, and it clearly discusses the motivation for why it is being created (which is not simply "LLMs BAD"), and also explicitly says that there likely never will be consensus on this topic across the whole Project. Together with an accompanying blog post, I think that is more than enough to explain that this is a policy to stop certain kinds of contributor behavior in |
- 👍 1 reaction
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
nikomatsakis
commented
May 13, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
|
So for starters, let me acknowledge the frustration I caused in my comment. I get it. I can't blame y'all for being frustrated. I've given your comments a lot of thought. Here are my conclusions. First, the TL;DR: I will back off from my procedural concern. I agree it's within the rights of the teams that review code on rust-lang/rust to set the policy, what I wrote earlier was too strong in this respect. I disagree with that it's the best way to set rust-lang/rust policy, but I don't think it's improper. Feel free to stop reading now if you don't want to understand my thinking. Otherwise, here's a lot of words. =)It seems to be a common assumption that I was trying to block or stall this RFC by saying that I felt it ought to be decided by the Leadership Council. This is not, in fact, the case. It's not obvious to me that a 40+-person list of checkboxes will be resolved more quickly than the LC. My concerns were not about the content. I hadn't read the latest changes at the time--I've since skimmed them--but I had seen that Jack was engaging and I know he and I see eye to eye. What I was concerned about is the fact that we are, de facto, setting what will be seen as the AI policy for the project without going through the existing project-wide decision making body. I recall somebody saying, in the whole Symposium goal conversation, that if we accepted the Symposium goal they were going to have to explain things to their friends. Well, I feel the same way: when we set this policy, it is going to be seen as the Rust project setting a policy. People are going to ask me about it. Quite possibly, reporters are going to call the Foundation and ask questions, etc. That's not a bad thing: it seems like this policy might indeed be one that I would be happy to defend! However, it seems to me that it'd be better all around for the LC to be involved in making that kind of policy decision. @jyn514, I don't know if you meant to imply that I was "hiding the actual concerns underlying [my] objections" or simply to note that this was a concern before. I don't feel I was doing that. It is true though that at some point in the discussion that led to this RFC, I simply got overwhelmed and decided to check out. I also don't have a checkbox here, so yeah, it's true that I don't feel "represented" by this decision in particular. I imagine many others feel similar. If I have any takeaway from all this, it's that I think that we as a project need to think hard about how we want to make hard decisions. I'm impressed @jyn514 that you've had the staying power to drive this RFC forward, kudos. I don't think it should've been necessary. I also don't really feel we've taken the temperature of the project in any meaningful sense. I feel partly responsible: I had plans to do a survey, I even met with some survey experts to discuss how to setup the survey in a way that would avoid leading questions and so forth, but I didn't complete the work. Ah well. Ultimately, I don't feel this is a good way to make decisions. I continue to think that the correct way forward would've been for the LC to set out a group of people to gather feedback, deliberate, gather data, and come to some conclusions that the rest of us can accept, endorsed by the LC in the end. I think that said group might have reached an interim agreement quite rapidly to ban "slop" contributions or what have you to bring down the temperature, and I would've been happy with that. That said, it feels like that ship has sailed, that's certainly the vibe I'm getting here. So be it. But once the dust has settles, let's talk about how we can approach these sorts of conversations in the future. (On a more practical level, multi-team FCPs are awfully unwieldy. If the precedent is that changing this policy requires getting 40 checkboxes, I think it's going to be very hard to make any changes. It just doesn't seem like the right way to make this sort of decision.) (Regarding the comparison to Symposium, I understand @Kobzol that it doesn't seem comparable to you. To me, it does. The way I see it, in a narrow sense, the lang team had the right to decide as a team to liase with the Symposium org. But it's also true that this would've been seen as a move by the project and hence, given the strong feelings folks had, it would've been "impolite" for us to do so as a team without having had broader LC endorsement. And this is why I decided to withdraw the goal. In the same way, I think it's valid to move this RFC forward, I just don't know that it's wise.) |
- 👍 2 reactions
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
| #### ✅ Allowed | ||
| The following are allowed. | ||
| - Asking an LLM questions about an existing codebase. | ||
| - Asking an LLM to summarize comments on an issue, PR, or RFC. |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| - Asking an LLM to summarize comments on an issue, PR, or RFC. | |
| - Asking an LLM to summarize comments on an issue or PR. |
This is a policy for r-l/r. Speaking about RFCs may confuse the reader as to the scope of this policy.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactionsUh oh!
There was an error while loading. Please reload this page.
Comment thread src/policies/llm-usage.md| - ℹ️ This does not apply if the LLM content is clearly quoted and marked, you can post that. | ||
| However, the content of the comment must stand on its own even without the LLM content; it's not a substitute for your own words. | ||
| - ℹ️ See also "machine-translation" in ⚠️ below. | ||
| - Documentation that is originally authored by an LLM. |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| - Documentation that is originally authored by an LLM. | |
| - Documentation that is originally generated by an LLM. |
Without changing the semantics, could we search and replace all uses of "authored by an LLM" with "generated by an LLM"? As @xtqqczze has pointed out elsewhere:
Authorship is something that applies to a person, not tools; a LLM can generate text, but it isn’t an author.
Pulling the idea of authorship into this policy seems unnecessarily philosophical for what it's trying to accomplish. The technology is called "generative AI". It'd seem more clear, to me, to stick with "generated".
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👍 3 garland-culbreth, Be-ing, and xtqqczze reacted with thumbs up emoji All reactions- 👍 3 reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentjyn specifically clarified authorship as a term here to be specific, so, you can't just change one section and be consistent. It would require at least structural changes to the policy.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👍 1 jyn514 reacted with thumbs up emoji All reactions- 👍 1 reaction
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentAs best I can tell from a careful review, it requires a search-and-replace and then some minor redrafting of the The meaning of "originally authored" section. That section could be redrafted, e.g., as:
This document uses phrases such as "generated by an LLM" to mean "text that was generated by an LLM (and then possibly edited by a human)". No amount of editing can change how the text was originally created; how it was generated originally sets the initial style and it is very hard to change once it's set.
(Of course, there are many ways to redraft it. This is just one way.)
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentRight, I think it would be fair to change "originally authored" to "originally generated," just, it would have to be a structural change affecting multiple places and not just the one line. For what it's worth, I think that the distinction is pedantic, but will defer to jyn on what the better wording is. I assume that "authored" was chosen intentionally.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactionsUh oh!
There was an error while loading. Please reload this page.
| - Writing dev-tools for your own personal use using an LLM, as long as you don't try to merge them into `rust-lang/rust`. | ||
| - 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. | ||
| Please refer to [our guidelines for fuzzers](https://rustc-dev-guide.rust-lang.org/fuzzing.html#guidelines). | ||
| - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. |
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. | |
| - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code when they're not entirely certain about those flaws. |
Could we narrow this somehow? I routinely run models over the lang nomination queue to prepare for meetings. It's not the main purpose of my process, but nonetheless, the models reliably flag things that I would find anyway, e.g., violations of RFC 0344 lint naming conventions, setting the lint level and report_in_deps in a way inconsistent with our process, etc.
The model is going to have found this flaw in the unmerged code first, and I'm going to have seen that, so I'd read that as falling under this policy. But I'm not looking forward to having to pollute all my comments, e.g.:
declare_lint! { - UNUSED_FROBINATOR, + UNUSED_FROBINATORS,Please pluralize this name, according to RFC 0344. (An LLM was used in the discovery of this flaw.)
Or could we come up with a scheme for blanket disclosure? Could we disclose once somewhere, e.g., in team, whether all our review comments should be treated as possibly LLM assisted?
I suppose I'd even be OK if triagebot wants to walk around in my shadow posting scarlet letters after each of my comments as long as I don't need to retype this everywhere.1
View changes since the review
Footnotes
-
That is, I'm OK with this for me. I have deeper concerns about how disclosure affects the Project. See https://github.com/rust-lang/rust-forge/pull/1040#discussion_r3236985179. ↩
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👎 1 tjkirch reacted with thumbs down emoji All reactions- 👎 1 reaction
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI'm a bit confused why you're asking for this clarification since this is under the allowed section. You just don't need to disclose it, from what I can see.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
jyn514
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentNo, under the rules it currently requires disclosure.
Using an LLM to discover bugs, as long as you [...] disclose that an LLM was used.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentAh, that feels a bit confusing, then. Because the way this list is worded, it looks like it is technically allowed, and probably should be moved down to the caveats section.
I don't think that we should be allowing blanket disclosure. Part of the reason why this policy exists is to avoid complacency, and this is a great way to ensure it.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThe model is going to have found this flaw in the unmerged code first, and I'm going to have seen that, so I'd read that as falling under this policy. But I'm not looking forward to having to pollute all my comments, e.g.:
declare_lint! { - UNUSED_FROBINATOR, + UNUSED_FROBINATORS,Please pluralize this name, according to RFC 0344. (An LLM was used in the discovery of this flaw.)
Something I should mention here that's probably not immediately obvious to those outside of lang is that (as we do on the lang calls) I'm generally leaving these comments during a live lang meeting. We might go through 25 items in 150 minutes.
That doesn't leave a lot of bandwidth (hence the lang-ops preparation for the calls). That's the context in which I'm asking for a reliable low-cost way to comply with this while being able to leave the comments I need to leave.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI don't think that you need to “pollute” your comments here. I would say, if you're using an LLM to blanket go through all these items, you could easily satisfy this policy by:
- Having a separate document where all of these details are listed
- Directly link to the spot that mentions the relevant issue
- At the top of the main document, make it clear that an LLM was used to generate it
Disclosure still counts if it requires clicking on a link.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| This policy can be dissolved in a few ways: | ||
|
|
||
| - An accepted FCP by teams using rust-lang/rust. | ||
| - An objective concern raised about active harm the policy is having on the reputation of Rust, with evidence, as decided by a leadership council FCP. |
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| - An objective concern raised about active harm the policy is having on the reputation of Rust, with evidence, as decided by a leadership council FCP. | |
| - An objective concern raised about active harm the policy is having on the reputation of Rust, with evidence, as decided by a leadership council FCP. | |
| - By the leadership council adopting, by FCP, a Project-wide policy and stating in an FCP that it displaces this policy. |
In my view, the LC (at any later time) would be within its rights to decide that rust-lang/rust is a shared space and that the drawbacks exceed the benefits, to the Project, of r-l/r having a policy different from that of the Project overall. The LC should be able to do this without having to make an evidentiary finding that the policy is harming the reputation of Rust.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentFirst, this would be redundant for the first point, since if the LC can just decide whenever to dissolve the policy, then it doesn't matter if they have concerns about active harm.
Second, if you just think the LC can veto any change to how a repository is managed after the teams managing that repo have signed off, without an RFC, I find that at least a little bit concerning.
Third, this is supposed to be a temporary policy, to be replaced by a project-wide policy. (Note that if a project-wide policy sets aside the option for this policy to be tailored by a few specific teams, I would consider that replacing this policy, even if this effectively stays as-is.)
So, from the perspective of this being refined by a larger RFC, I think that it's fair to say that it should only be replaced if there is active and demonstrable harm, not just because the LC doesn't like it. And uh, it's a massive conflict of interest for you to be proposing that to begin with, since you would be one of the people potentially making that decision.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThird, this is supposed to be a temporary policy, to be replaced by a project-wide policy.
The author has rejected framing this as an interim policy, so I'm not sure this is correct. See #1040 (comment).
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI can't comment for what jyn thinks, but to me, the goal here is to not belittle a policy that has already been put in place even if we also agree that policy needs to be put in place elsewhere in the project. The idea isn't that the policy itself is temporary, but rather than the only potential next step would be either:
a) The policy has shortcomings that need to be addressed, or
b) The policy is superceded by a broader one
Neither of these cases are "the LC doesn't like the policy and wants to remove it entirely"
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| The following are allowed. | ||
| - Asking an LLM questions about an existing codebase. | ||
| - Asking an LLM to summarize comments on an issue, PR, or RFC. | ||
| - ℹ️ This does not allow reposting the summary publicly. This only includes your own personal use. |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| - ℹ️ This does not allow reposting the summary publicly. This only includes your own personal use. | |
| - ℹ️ This does not allow reposting the summary publicly on `rust-lang/rust`. |
As written, this could read as a prohibition on posting the summary publicly anywhere. That would be an overreach and is not what I think is meant.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI think the clarification is fair, but I don't think that removing the point about personal use is fair. The point is to clarify that it's for personal use, and posting it publicly outside the project counts as that still.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
traviscross
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThis is a policy for r-l/r, so I'd consider it out of bounds for this to prohibit, e.g., a member of another team using an LLM to construct a summary and then posting that to a Project team space outside of r-l/r for team use. It would stretch the meaning of personal use too far to consider that personal use.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentWhat I meant is:
This does not allow reposting the summary publicly on
rust-lang/rust. This only includes your own personal use.
is fine, because posting it publicly outside of rust-lang/rust counts as personal use under this policy, and is therefore fine.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactionsUh oh!
There was an error while loading. Please reload this page.
petrochenkov commented May 14, 2026
|
I didn't participate in the LLM-related discussions before, but I'd personally be fine with a wide range of policies, except perhaps most extreme ones like "you must review slop" or "no LLMs at all, even in you free time". I'd also be fine with not having a policy and dealing with contributions involving LLMs on case by case basis, using reviewer's judgement, the number of such contributions to rust-lang/rust is not actually large at the moment. |
- 👍 1 reaction
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Comment thread src/policies/llm-usage.md| #### It's not your job to play detective | ||
| ["The optimal amount of fraud is not zero"](https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/). | ||
| Don't try to be the police for whether someone has used an LLM. | ||
| If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. | |
| Point to this policy, maybe report it to the mods (at your discretion), and move on. |
To an outside reader, reporting something to the mods is going to sound like an escalation against the contributor. Given that, it reads a bit backward that the clear violations should only result in the policy being cited while the borderline violations require a report to the mods.
There are many ways this could be redrafted to avoid this. What I'd suggest is leaving whether to report this to the mods to the discretion of the reviewer in all cases and removing the conditional on whether the case is borderline or clear.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThe mods have openly encouraged people to report non-violations so they can keep an eye on things. I don't think that we should be reinforcing the stereotype that communication with the mods is inherently accusatory; we should be breaking that assumption instead.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| If it's clear they've broken the rules, point them to this policy; if it's borderline, report it to the mods and move on. | ||
|
|
||
| #### Be honest | ||
| Conversely, lying about whether or how you've used an LLM is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| Conversely, lying about whether or how you've used an LLM is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. | |
| Conversely, claiming to have not used an LLM when you did or stating your use of an LLM as less than it was is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. |
I think to be fair to people, this language needs to have a safe harbor. People shouldn't have to worry that they have precisely calibrated their disclosures, i.e., not too high, not too low.
They might have done the work many months ago and may not remember the exact details. It must always be safe to over-disclose — to err on the side of stating that more LLM use happened.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
kennytm
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentthe suggested edit is much harder to understand than the original text though
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👍 2 clarfonthey and tjkirch reacted with thumbs up emoji All reactions- 👍 2 reactions
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI actually disagree; I would say that lying is a larger burden to meet and would not include people who are mistaken. Instead of weakening the wording, we could maybe clarify that the mods understand the difference between an lie and a misunderstanding.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
traviscross
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentthe suggested edit is much harder to understand than the original text though
There are many ways to redraft, and I'm OK with one that continues to frame it as lying. E.g.:
Suggested change| Conversely, lying about whether or how you've used an LLM is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. | |
| Conversely, lying about not using an LLM when you did, or lying about relying less on an LLM than you did is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👍 1 kennytm reacted with thumbs up emoji All reactions- 👍 1 reaction
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI mean, I already kind of solved this in my version:
If a user is found to be repeatedly lying about LLM usage (using LLMs in a non-trivial way without disclosing that usage)
It doesn't need to be particularly elegant; parentheses are fine.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| Other violations are left up to the discretion of reviewers and moderators. | ||
| For most first-time violations we recommend closing and locking the PR or issue. | ||
|
|
||
| Using an LLM does **not** mean it's ok to harrass a contributor. |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| Using an LLM does **not** mean it's ok to harrass a contributor. | |
| That a person used an LLM does **not** mean it's OK to harass that contributor. |
I think what this means to say is that it's not OK to harass people who used an LLM. It reads to me, though, as saying that using an LLM doesn't excuse the user harassing people, which is also obviously true, though probably too obvious to mention.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
👍 1 xtqqczze reacted with thumbs up emoji All reactions- 👍 1 reaction
clarfonthey
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThis just feels pedantic, honestly. The new version feels a bit clunky to read, and the original still is understandable imho.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| - Usages that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ | ||
| - Usages that use LLMs for creation or show LLM output to another human are likely banned ❌ |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| - Usages that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ | |
| - Usages that use LLMs for creation or show LLM output to another human are likely banned ❌ | |
| - Uses that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ | |
| - Uses that use LLMs for creation or show LLM output to another human are likely banned ❌ |
The more correct word here is uses. The word usage means a customary pattern or habit of use (or a rate or quantity of use).
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| - Usages that do not use LLMs for creation and do not show LLM output to another human are likely allowed ✅ | ||
| - Usages that use LLMs for creation or show LLM output to another human are likely banned ❌ |
traviscross
May 14, 2026
•
edited by rustbot
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThe policy has evolved since this section was written, and I wonder whether it needs to be redrafted in a softer way. It now reads as far starker than the rest of the policy does.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| Major changes, such as adding a new rule or cancelling an existing rule, require | ||
| a simple majority of members of teams using rust-lang/rust (without concerns). |
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI read "without concerns" ambiguously here. Does it mean "it must achieve a simple majority of the members of teams using r-l/r and no concerns must be filed" or that "it must achieve a simple majority of the members of teams using r-l/r without considering concerns to have effect for blocking it."
Either one I could see as having been intended. The first is more similar to how we normally treat concerns, but it's in conflict with wanting only a simple majority, as it actually requires a kind unanimity — any one person can block it. The second would be closer in spirit to a simple majority system, but it's in tension with our usual system of concerns.
Which reading is intended? Probably this should be made more clear.
View changes since the review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| #### ❌ Banned | ||
| The following are banned. | ||
| - Comments from a personal user account that are originally authored by an LLM. | ||
| - ℹ️ This also applies to issue bodies and PR descriptions. |
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentMost of the work lang members do, as a team, is reviewing language proposals made to us in rust-lang/rust issue bodies, PR descriptions, and comments. Here's a random recent one, by way of example:
- Lang proposal: const expressions in
#[repr(align)]and#[repr(packed)]and friends. rust#155390
We tend to care about policies for how lang-related issue and PR descriptions are put forward, e.g., the stabilization report template. Though we are not ourselves large contributors of code to r-l/r, we are in the set of maintainers of r-l/r — at least, that's how I see it.
So it surprised me a bit, given that this document sets policy for what's allowed for people making lang proposals to us in r-l/r (e.g., by prohibiting LLM-assisted drafting), that we weren't included on this FCP, though it had been earlier discussed.
I don't know what to do about that. I don't really want to ask here for the hassle of the FCP being restarted. And yet, given what the policy covers, it seems awkward to me that we're not on it — as though I'm commenting here with needs and interests as an outsider. That's how it feels, anyway.
Is there anything we can do about this? Maybe the scope can be narrowed so that it doesn't set policy for lang proposals or documentation items lang owns? Maybe something else? I don't know. @jyn514, what do you think?1
View changes since the review
Footnotes
-
If you don't mind, I really do want to hear specifically from @jyn514 on this (no hurry). ↩
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
jyn514
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentI'm happy to narrow the scope so this excludes lang proposals and stabilization reports, so that t-lang can set their own policy. Are there other things in t-lang's purview you would like to see excluded?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
address a few of TC's concerns
ee4f26c
address a few of Jack's concerns
7956574
remove the 'additional scrutiny' examples
b88855a
move 'using an llm to discover bugs' to the caveats section, without …
…
4305e14
…changes to the rules
move LLM-authored code to its own section; add a zulip stream as policy
ab6f8a4
add a section about staying on-topic
d9d8238
Manishearth commented May 14, 2026
|
This is a bit on a tangent, but I think this discussion is also valuable and important to have. I generally agree with @jyn514 about the procedural aspect here, and at the same time, I think 40-checkbox decisions are just ... not really workable. Feel free to reopen this as a discussion elsewhere if you want to avoid further tangent-ing. Or just hide the comment. I think it's useful for the Rust project to spend some time reflecting on its procedural options here for future such decisions.
FWIW, I do think that this is one of the key, deliberate differences between the Leadership Council and Core. Core did make decisions like this, and generally Core was expected to involve everyone in such decisions but not as checkboxes, instead via other mechanisms. I actually think that mostly worked well until the last couple of years of Core where Core was completely swamped with Foundation stuff and other major work items, leading to a bunch of failure modes becoming clear, and people feeling blocked out of these decisions. Core tended to be "fail closed" for top level decision making: if something felt toplevel, Core expected to handle it by default. LC is "fail open": if something feels toplevel, that doesn't make it LC unless it's one of the explicitly enumerated things, or something everyone is broadly comfortable delegating to LC. To some extent, I think this change was an overrotation and ended up tearing down a number of Chesterton's Fences: it is valuable to have a team that you can trust to make decisions like this (regardless of whether they make those decisions by default). There's a lot of good in having an entity that is responsible for ratifying good decisions1, and trusted to do that well, even when it involves heavy compromise. The problem occurs when that trust breaks down, or when the team is broadly unable to do that effectively. I think this is exactly the type of tricky decision where the Rust project should want to delegate consensusbuilding and final ratification to the toplevel team. I have largely not been participating in the LLM discussions, but from the outside, they look exhausting. From the outside, I am reminded of some of the discussions around the 2018 edition, where everyone and their dog had something to say, the same things got said over and over again, and the conversation ended up being dominated by a handful of very vocal, very passionate people who often ended up talking past each other. The 2018 edition sucked for the project. The 2018 edition spawned a whole host of governance work, some of which came to fruition, but we were talking about those problems for years. I would love for the Rust project to be in a place where there is a small team that can be trusted to organize an information gathering process2, take in all of the input, conduct scoped discussions, iterate on a proposal, and finally make decisions on it, while keeping the process open and legible. From what I see here, that doesn't seem to be the case currently, but I would urge people to view this as an aspirational goal for project governance and work towards it by building that trust. I don't want to say they should be doing that by default, but I would love to see a situation where when team ratification leads to too many cooks, everyone feels comfortable delegating to a smaller, trusted group. That group doesn't even have to be the council; but having the council be trusted enough to fill that role in 99% of cases is a valuable property. Lack of trust has been a persistent theme in Rust's governance problems. Footnotes
|
- 👍 4 reactions
- ❤️ 2 reactions
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
jyn514 added 2 commits May 14, 2026 20:53
wording
83b9363
relax moderation policy guidelines
9efffad
nikomatsakis
left a comment
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentOverall my take is that this policy in broad strokes is good but I find it kind of bewildering and hard to follow. I think people are going to read it and just be overwhelmed. I would really rather we lean into something simple. I think it boils down to this
- LLMs for private use (output not shown publicly) is allowed
- Using LLMs to generate code, documentation or text that you post in a PR or issue is disallowed apart from a specific set of cases.
- We have an experimental program where, if you are you can opt-in to having a reviewer work with you.
I don't think we need to overspecify how the experimental program works. I'd lean into mandatory disclosure (enforced by a bot that puts your PR into a draft state if it's not present, say) and ensure that LLM-authored PRs are not auto-assigned in the normal review queues. Failure to disclosure LLM-authored code is a moderation violation, resulting in a closed PR and rapid escalation for repeated cases.
I'd probably want to agree now that we'll check in periodically on how people are feeling. Maybe we ask compiler + libs-api leads to take in comments in all directions (positive and negative). I don't know, something like that. I would hope that we can update the policy as we gain more experience without a massive FCP.
To me, the list of conditions ("not in safety critical code", etc) is overkill and kind of insulting. It signals a lack of trust in your fellow team members to be able to review code. I realize that it makes others feel comfortable, but I think it comes at a severe cost, and it'll be something that ages fairly poorly.
View changes since this review
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| #### ✅ Allowed | ||
| The following are allowed. | ||
| - Asking an LLM questions about an existing codebase. | ||
| - Asking an LLM to summarize comments on an issue, PR, or RFC. | ||
| - ℹ️ This does not allow reposting the summary publicly. This only includes your own personal use. | ||
| - Asking an LLM to privately review your code or writing. | ||
| - ℹ️ This does not apply to public comments. See "review bots" under ⚠️ below. | ||
| - Writing dev-tools for your own personal use using an LLM, as long as you don't try to merge them into `rust-lang/rust`. | ||
| - 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. | ||
| Please refer to [our guidelines for fuzzers](https://rustc-dev-guide.rust-lang.org/fuzzing.html#guidelines). | ||
| - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. |
nikomatsakis
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment Suggested change| #### ✅ Allowed | |
| The following are allowed. | |
| - Asking an LLM questions about an existing codebase. | |
| - Asking an LLM to summarize comments on an issue, PR, or RFC. | |
| - ℹ️ This does not allow reposting the summary publicly. This only includes your own personal use. | |
| - Asking an LLM to privately review your code or writing. | |
| - ℹ️ This does not apply to public comments. See "review bots" under ⚠️ below. | |
| - Writing dev-tools for your own personal use using an LLM, as long as you don't try to merge them into `rust-lang/rust`. | |
| - 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. | |
| Please refer to [our guidelines for fuzzers](https://rustc-dev-guide.rust-lang.org/fuzzing.html#guidelines). | |
| - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. | |
| #### ✅ Allowed | |
| - Any usage of an LLM where you are the only one that sees the output, e.g. | |
| - asking an LLM questions about an existing codebase. | |
| - asking an LLM to summarize comments on an issue, PR, or RFC (but not reposting that summary) | |
| - asking an LLM to privately review your code or writing. | |
| - writing tools and code that you do not attempt to merge into `rust-lang/rust`. | |
| - 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. | |
| Please refer to [our guidelines for fuzzers](https://rustc-dev-guide.rust-lang.org/fuzzing.html#guidelines). | |
| - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
nikomatsakis
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentIs this equivalent?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions
traviscross
May 14, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentThe "where you are the only one that sees the output" clause would be a more expansive prohibition. You could be working with someone else, with another team, or posting it publicly (but not to r-l/r). Maybe something like:
...where the output is not posted to r-l/r in a way intended to be reviewed by compiler, types, libs, or rustdoc.
(See the recent additions for other items this framing is trying to encompass.)
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactions| LLMs are conditionally allowed to assist with the *logic* surrounding a diagnostic (see "code changes" under ⚠️ below), | ||
| but they must not be used to author the message itself. | ||
| - Treating an LLM review as a sufficient condition to merge or reject a change. | ||
| LLM reviews, if enabled by a team, **must** be advisory-only. |
nikomatsakis
May 14, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide commentIt's not clear to me what this "team" language refers to here, as this is the rust-lang/rust policy
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
All reactionsnikomatsakis commented May 14, 2026
I'm actually not sure -- is this what the policy says? If you are an experienced dev, are we saying that in that case it's ok? (I think not.) e.g., if I was working on a PR with an LLM, presumably I would go through the same experimental process? |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters Sign up for free to join this conversation on GitHub. Already have an account? Sign in to commentReviewers
camelid
camelid left review comments
nikomatsakis
nikomatsakis left review comments
joshtriplett
joshtriplett left review comments
oli-obk
oli-obk left review comments
traviscross
traviscross requested changes
davidtwco
davidtwco approved these changes
Manishearth
Manishearth left review comments
nnethercote
nnethercote left review comments
Turbo87
Turbo87 left review comments
Mark-Simulacrum
Mark-Simulacrum left review comments
Urgau
Urgau left review comments
Kobzol
Kobzol left review comments
jieyouxu
jieyouxu left review comments
apiraino
apiraino left review comments
jackh726
jackh726 left review comments
GuillaumeGomez
GuillaumeGomez approved these changes
Be-ing
Be-ing left review comments
Diggsey
Diggsey left review comments
Darksonn
Darksonn left review comments
gulbanana
gulbanana left review comments
xtqqczze
xtqqczze left review comments
alice-i-cecile
alice-i-cecile left review comments
lmmx
lmmx left review comments
kennytm
kennytm left review comments
clarfonthey
clarfonthey left review comments
ChayimFriedman2
ChayimFriedman2 left review comments
AndyGauge
AndyGauge approved these changes
obi1kenobi
obi1kenobi approved these changes
Requested changes must be addressed to merge this pull request.
Assignees
jieyouxu
Labels
I-council-nominated Nominated for discussion during a council meeting. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Team: Bootstrap T-compiler Team: Compiler T-libs Team: Library / libs T-rustdoc Team: rustdoc T-types Team: TypesProjects
None yetMilestone
No milestoneDevelopment
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.