From 772edebca89bb597b33fafacbf6779944831718c Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 17 Apr 2026 08:58:02 +0200 Subject: [PATCH 01/48] Add an LLM policy for `rust-lang/rust` ## 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](https://github.com/rust-lang/leadership-council/issues/273#issuecomment-4051188890), 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](https://github.com/rust-lang/compiler-team/issues/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 - https://github.com/NixOS/nixpkgs/issues/410741 ## Unresolved questions [unresolved-questions]: #unresolved-questions See the "Moderation guidelines" and "Drawbacks" section for a list of topics that are out of scope. --- src/SUMMARY.md | 1 + src/how-to-start-contributing.md | 4 +- src/policies/llm-usage.md | 107 +++++++++++++++++++++++++++++++ 3 files changed, 111 insertions(+), 1 deletion(-) create mode 100644 src/policies/llm-usage.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 245aedf2..2f6ca847 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -87,6 +87,7 @@ - [Project groups](./governance/project-groups.md) - [Policies](./policies/index.md) - [Crate ownership policy](./policies/crate-ownership.md) + - [LLM usage policy](./policies/llm-usage.md) - [Infrastructure](./infra/index.md) - [Other Installation Methods](./infra/other-installation-methods.md) - [Archive of Rust Stable Standalone Installers](./infra/archive-stable-version-installers.md) diff --git a/src/how-to-start-contributing.md b/src/how-to-start-contributing.md index 83a21ccb..088e121a 100644 --- a/src/how-to-start-contributing.md +++ b/src/how-to-start-contributing.md @@ -122,13 +122,15 @@ We know that starting contributing in a FOSS[^1] project could be confusing at t both contributors and reviewers have the best possible experience when collaborating in our project. To achieve this goal, we want to build trust and respect of each other's time and efforts. Our recommendation is to follow these simple guidelines: -- Start small. A big ball of code as first contribution does not help to build trust +- Start small. A big ball of code as first contribution does not help to build trust. - The work you submit is your own, meaning that you fully understand every part of it - You take care of checking in detail your work before submitting it - ask questions or signal us (with inline comments or `todo!()`) the parts you're unsure about - If you want to fix an issue but have doubts about the design, you're welcome to join our [Zulip][rust-zulip] server and ask for tips - Please respect the reviewers' time: allow some days between reviews, only ask for reviews when your code compiles and tests pass, or give an explanation for why you are asking for a review at that stage (you can keep them in draft state until they're ready for review) - Try to keep comments concise, don't worry about a perfect written communication. Strive for clarity and being to the point +See also our [LLM usage policy](./policies/llm-usage.md). + [^1]: Free-Open Source Project, see: https://en.wikipedia.org/wiki/Free_and_open-source_software ### Different kinds of contributions diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md new file mode 100644 index 00000000..76afc070 --- /dev/null +++ b/src/policies/llm-usage.md @@ -0,0 +1,107 @@ +## Policy + +For additional information about the policy itself, see [the appendix](#appendix). + +### Overview + +Using an LLM while working on `rust-lang/rust` is conditionally allowed. +However, we find it important to keep the following points in mind: + +- 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. + +Therefore, the guidelines are roughly as follows: + +> It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**. + +> LLMs work best when used as a tool to write *better*, not *faster*. + +#### Legend + +- ✅ Allowed +- ❌ Banned +- ⚠️ Allowed with caveats. Must disclose that an LLM was used. +- ℹ️ Adds additional detail to the policy. These bullets are normative. + +### Rules + +#### ✅ 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 bugs in unmerged code. + +#### ❌ 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. + - ℹ️ See also "machine-translation" in ⚠️ below. +- Documentation that is originally authored by an LLM. + - ℹ️ This includes non-trivial source comments, such as paragraph+ doc-comments or multiple inline paragraphs. + - ℹ️ This includes compiler diagnostics. +- Code changes that are originally authored by an LLM. + - This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. + We understand that while asking an LLM research questions it may, unprompted, suggest small changes where there really isn't another way to write it. + However, you must still type out the changes yourself; you cannot give the LLM write access to your source code. + - We do not accept PRs made up solely of trivial changes. + See [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). + - See also "learning from an LLM's solution" in ⚠️ below. + +#### ⚠️ Allowed with caveats +The following are decided on a case-by-case basis. +Please avoid them where possible. +In general, existing contributors will be treated more leniently here than new contributors. +We may ask you for the original prompts or design documents that went into the LLM's output; +please have them on-hand, and be available yourself to answer questions about your process. + +- Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. +- Using machine-translation from your native language without posting your original message. + Doing so can introduce new miscommunications that weren't there originally, and prevents someone who speaks the language from providing a better translation. + - ℹ️ Posting both your original message and the translated version is always ok, but you must still disclose that machine-translation was used. + - ℹ️ This policy also applies to non-LLM machine translations such as Google Translate. +- Using an LLM as a "review bot" for PRs. + - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. They **must not** post under a personal account. + - ℹ️ Review bots that post without being approved by a maintainer will be banned. + - ℹ️ If a linter already exists for the language you're writing, we strongly suggest using that linter instead of or in addition to the LLM. + - ℹ️ Please keep in mind that it's easy for LLM reviews to have false positives or focus on trivialities. We suggest configuring it to the "least chatty" setting you can. + - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". + - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. + - ℹ️ This does not apply to private use of an LLM for reviews; see ✅ above. + +All of these **must** disclose that an LLM was used. + +## Appendix + +### No witch hunts +["The optimal amount of fraud is not zero"](https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/). +Do not 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. + +Conversely, lying about whether you've used an LLM is an instant code of conduct violation. +If you are not sure where you fall in this policy, please talk to us. +Don't try to hide it. + +### Responsibility + +All contributions are your responsibility; you cannot place any blame on an LLM. +- ℹ️ This includes when asking people to address review comments originally authored by an LLM. See "review bots" under ⚠️ above. + +### "originally authored" + +This document uses the phrase "originally authored" to mean "text that was generated by an LLM (and then possibly edited by a human)". +No amount of editing can change authorship; authorship sets the initial style and it is very hard to change once it's set. + +For more background about analogous reasoning, see ["What Colour are your bits?"](https://ansuz.sooke.bc.ca/entry/23) + +### Non-exhaustive policy + +This policy does not aim to be exhaustive. +If you have a use of LLMs in mind that isn't on this list, judge it in the spirit of this overview: +- 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 ❌ From 815da6eaed40bb1b045cc89d37fa4287e505744f Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 17 Apr 2026 13:03:11 +0200 Subject: [PATCH 02/48] address some of jieyouxu's comments --- src/policies/llm-usage.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 76afc070..70b6823e 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -43,7 +43,7 @@ The following are banned. - ℹ️ This also applies to issue bodies and PR descriptions. - ℹ️ See also "machine-translation" in ⚠️ below. - Documentation that is originally authored by an LLM. - - ℹ️ This includes non-trivial source comments, such as paragraph+ doc-comments or multiple inline paragraphs. + - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. - Code changes that are originally authored by an LLM. - This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. @@ -52,6 +52,12 @@ The following are banned. - We do not accept PRs made up solely of trivial changes. See [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). - See also "learning from an LLM's solution" in ⚠️ below. +- Treating an LLM review as a sufficient condition to merge a change. + LLM reviews, if enabled by a team, **must** be advisory-only. + Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, + but they may not have a policy that an LLM counts as a person. + - ℹ️ See "review bots" in ⚠️ below. + - ℹ️ An LLM review does not substitute for self-review. Authors are expected to review their own code before posting and after each change. #### ⚠️ Allowed with caveats The following are decided on a case-by-case basis. @@ -83,7 +89,7 @@ All of these **must** disclose that an LLM was used. Do not 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. -Conversely, lying about whether you've used an LLM is an instant code of conduct violation. +Conversely, lying about whether you've used an LLM is an instant [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. If you are not sure where you fall in this policy, please talk to us. Don't try to hide it. @@ -105,3 +111,6 @@ This policy does not aim to be exhaustive. If you have a use of LLMs in mind that isn't on this list, judge it in the spirit of this overview: - 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 ❌ + +This policy is not set in stone. +We can evolve it as we gain more experience working with LLMs. From 17a35f405be7d852ba4bb97be13279a34465b5cd Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Fri, 17 Apr 2026 17:05:57 +0200 Subject: [PATCH 03/48] revert extraneous change --- src/how-to-start-contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-start-contributing.md b/src/how-to-start-contributing.md index 088e121a..4489db80 100644 --- a/src/how-to-start-contributing.md +++ b/src/how-to-start-contributing.md @@ -122,7 +122,7 @@ We know that starting contributing in a FOSS[^1] project could be confusing at t both contributors and reviewers have the best possible experience when collaborating in our project. To achieve this goal, we want to build trust and respect of each other's time and efforts. Our recommendation is to follow these simple guidelines: -- Start small. A big ball of code as first contribution does not help to build trust. +- Start small. A big ball of code as first contribution does not help to build trust - The work you submit is your own, meaning that you fully understand every part of it - You take care of checking in detail your work before submitting it - ask questions or signal us (with inline comments or `todo!()`) the parts you're unsure about - If you want to fix an issue but have doubts about the design, you're welcome to join our [Zulip][rust-zulip] server and ask for tips From 61e5e2c8ef9ddbb54b303bee23d043c272eb9033 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 18 Apr 2026 09:32:12 +0200 Subject: [PATCH 04/48] address some more review comments --- src/policies/llm-usage.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 70b6823e..8dff7f54 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -1,4 +1,4 @@ -## Policy +## LLM Usage Policy For additional information about the policy itself, see [the appendix](#appendix). @@ -35,7 +35,7 @@ The following are allowed. - 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 bugs in unmerged code. + - ℹ️ This also includes reviewers who use LLMs to discover flaws in unmerged code. #### ❌ Banned The following are banned. @@ -62,20 +62,22 @@ The following are banned. #### ⚠️ Allowed with caveats The following are decided on a case-by-case basis. Please avoid them where possible. -In general, existing contributors will be treated more leniently here than new contributors. +In general, existing contributors will be treated more leniently here than new contributors, +since they've already established trust with their reviewers. We may ask you for the original prompts or design documents that went into the LLM's output; please have them on-hand, and be available yourself to answer questions about your process. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. -- Using machine-translation from your native language without posting your original message. +- Using machine-translation (e.g. Google Translate) from your native language without posting your original message. Doing so can introduce new miscommunications that weren't there originally, and prevents someone who speaks the language from providing a better translation. - ℹ️ Posting both your original message and the translated version is always ok, but you must still disclose that machine-translation was used. - - ℹ️ This policy also applies to non-LLM machine translations such as Google Translate. - Using an LLM as a "review bot" for PRs. - - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. They **must not** post under a personal account. + - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. + You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. + - ℹ️ Review bot accounts must be blockable by individual users via the standard GitHub user-blocking mechanism. (Note that some GitHub "app" accounts post comments that look like users but cannot be blocked.) - ℹ️ Review bots that post without being approved by a maintainer will be banned. - ℹ️ If a linter already exists for the language you're writing, we strongly suggest using that linter instead of or in addition to the LLM. - - ℹ️ Please keep in mind that it's easy for LLM reviews to have false positives or focus on trivialities. We suggest configuring it to the "least chatty" setting you can. + - ℹ️ Configure LLM review tools to reduce false positives and excessive focus on trivialities, as these are common, exhausting failure modes. - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. - ℹ️ This does not apply to private use of an LLM for reviews; see ✅ above. @@ -84,21 +86,21 @@ All of these **must** disclose that an LLM was used. ## Appendix -### No witch hunts +### 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/). Do not 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. Conversely, lying about whether you've used an LLM is an instant [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. -If you are not sure where you fall in this policy, please talk to us. +If you are not sure where something you would like to do falls in this policy, please talk to us. Don't try to hide it. ### Responsibility -All contributions are your responsibility; you cannot place any blame on an LLM. +Your contributions are your responsibility; you cannot place any blame on an LLM. - ℹ️ This includes when asking people to address review comments originally authored by an LLM. See "review bots" under ⚠️ above. -### "originally authored" +### The meaning of "originally authored" This document uses the phrase "originally authored" to mean "text that was generated by an LLM (and then possibly edited by a human)". No amount of editing can change authorship; authorship sets the initial style and it is very hard to change once it's set. From 8ee5ed40b15521b02aa33f50c471b2f53bff509f Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 18 Apr 2026 09:44:17 +0200 Subject: [PATCH 05/48] more review comments --- src/policies/llm-usage.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 8dff7f54..5fda2c4f 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -52,7 +52,7 @@ The following are banned. - We do not accept PRs made up solely of trivial changes. See [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). - See also "learning from an LLM's solution" in ⚠️ below. -- Treating an LLM review as a sufficient condition to merge a change. +- 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. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, but they may not have a policy that an LLM counts as a person. @@ -66,6 +66,7 @@ In general, existing contributors will be treated more leniently here than new c since they've already established trust with their reviewers. We may ask you for the original prompts or design documents that went into the LLM's output; please have them on-hand, and be available yourself to answer questions about your process. +We may also ask for the exact LLM model used to generate the output. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. - Using machine-translation (e.g. Google Translate) from your native language without posting your original message. From 7cd8c17b33384f79f0d1758f0e6989b582d9c3a6 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 18 Apr 2026 18:41:11 +0200 Subject: [PATCH 06/48] more wording --- src/policies/llm-usage.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 5fda2c4f..6d04d5ee 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -65,7 +65,7 @@ Please avoid them where possible. In general, existing contributors will be treated more leniently here than new contributors, since they've already established trust with their reviewers. We may ask you for the original prompts or design documents that went into the LLM's output; -please have them on-hand, and be available yourself to answer questions about your process. +please have them on-hand, and be available to personally answer questions about your process. We may also ask for the exact LLM model used to generate the output. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. @@ -77,7 +77,7 @@ We may also ask for the exact LLM model used to generate the output. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. - ℹ️ Review bot accounts must be blockable by individual users via the standard GitHub user-blocking mechanism. (Note that some GitHub "app" accounts post comments that look like users but cannot be blocked.) - ℹ️ Review bots that post without being approved by a maintainer will be banned. - - ℹ️ If a linter already exists for the language you're writing, we strongly suggest using that linter instead of or in addition to the LLM. + - ℹ️ If a more reliable tool, such as a linter or formatter, already exists for the language you're writing, we strongly suggest using that tool instead of or in addition to the LLM. - ℹ️ Configure LLM review tools to reduce false positives and excessive focus on trivialities, as these are common, exhausting failure modes. - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. From 2db74657fe433436848b4ab53bcc03c784c94c1f Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:21:06 +0200 Subject: [PATCH 07/48] rewrite "trivial changes" section --- src/policies/llm-usage.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 6d04d5ee..c2b81962 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -46,12 +46,10 @@ The following are banned. - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. - Code changes that are originally authored by an LLM. - - This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. - We understand that while asking an LLM research questions it may, unprompted, suggest small changes where there really isn't another way to write it. - However, you must still type out the changes yourself; you cannot give the LLM write access to your source code. - - We do not accept PRs made up solely of trivial changes. - See [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). - - See also "learning from an LLM's solution" in ⚠️ below. + - ℹ️ This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. + - ℹ️ 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). + - See also "learning from an LLM's solution" in ⚠️ below. - 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. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, From 9b2b3c28f49102c70fb13cd6744bb73aa069edd2 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:21:19 +0200 Subject: [PATCH 08/48] rewrite intro to 'Allowed with caveats' --- src/policies/llm-usage.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index c2b81962..1ecf74a3 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -53,18 +53,14 @@ The following are banned. - 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. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, - but they may not have a policy that an LLM counts as a person. + but they may not have a policy that an LLM review substitutes for a human review. - ℹ️ See "review bots" in ⚠️ below. - ℹ️ An LLM review does not substitute for self-review. Authors are expected to review their own code before posting and after each change. #### ⚠️ Allowed with caveats The following are decided on a case-by-case basis. -Please avoid them where possible. -In general, existing contributors will be treated more leniently here than new contributors, -since they've already established trust with their reviewers. -We may ask you for the original prompts or design documents that went into the LLM's output; -please have them on-hand, and be available to personally answer questions about your process. -We may also ask for the exact LLM model used to generate the output. +In general, new contributors will be scrutinized more heavily than existing contributors, +since they haven't yet established trust with their reviewers. - Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. - Using machine-translation (e.g. Google Translate) from your native language without posting your original message. From e3b1394a0da1cefd3db5f63e087663bfaf89ea25 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:21:39 +0200 Subject: [PATCH 09/48] Be more specific in "Moderation policy" --- src/policies/llm-usage.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 1ecf74a3..f04d0175 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -81,15 +81,21 @@ All of these **must** disclose that an LLM was used. ## Appendix -### It's not your job to play detective +### Moderation policy +#### 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/). Do not 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. -Conversely, lying about whether you've used an LLM is an instant [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. -If you are not sure where something you would like to do falls in this policy, please talk to us. +#### 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. +If you are not sure where something you would like to do falls in this policy, please talk to the [moderation team](mailto:rust-mods@rust-lang.org). Don't try to hide it. +#### Penalties +This policy follows the same guidelines as the code of conduct: +Violations will first result in a warning, and repeated violations may result in a ban. + ### Responsibility Your contributions are your responsibility; you cannot place any blame on an LLM. From e3f2aec2958b28b906be7dc7e703dc0b61d56938 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 02:22:00 +0200 Subject: [PATCH 10/48] Add explicit conditions for modification or removal --- src/policies/llm-usage.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index f04d0175..2cea47e7 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -115,5 +115,14 @@ If you have a use of LLMs in mind that isn't on this list, judge it in the spiri - 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 ❌ -This policy is not set in stone. -We can evolve it as we gain more experience working with LLMs. +### Conditions for modification or dissolution +This policy is not set in stone, and we can evolve it as we gain more experience working with LLMs. + +Minor changes, such as typo fixes, only require a normal PR approval. +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). + +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. From 864428fe21c44658d126e95c5bf2392db038cd93 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 10:34:09 +0200 Subject: [PATCH 11/48] mention that the policy is intentionally conservative --- src/policies/llm-usage.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 2cea47e7..0be8e617 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -9,6 +9,8 @@ However, we find it important to keep the following points in mind: - 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. +- LLMs are a new technology, and we are still learning how to use, moderate, and improve them. + Since we're still learning, we have chosen an intentionally conservative policy that lets us maintain the standard of quality that Rust is known for. Therefore, the guidelines are roughly as follows: From 593d5386c838d682a94fd8e55a72693fce9c546f Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 21 Apr 2026 10:34:26 +0200 Subject: [PATCH 12/48] extend "Penalties" section with sentencing guidelines --- src/policies/llm-usage.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 0be8e617..be247745 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -95,8 +95,17 @@ If you are not sure where something you would like to do falls in this policy, p Don't try to hide it. #### Penalties -This policy follows the same guidelines as the code of conduct: +The policies below follow the same guidelines as the code of conduct: Violations will first result in a warning, and repeated violations may result in a ban. +- 🔨 Comments from a personal account originally authored by an LLM +- 🔨 Violations of the "Be honest" section + +Other violations are left up to the discretion of reviewers and moderators. +For most cases we recommend closing and locking the PR or issue, but not escalating further. + +Using an LLM does **not** mean it's ok to harrass a contributor. +All contributors must be treated with respect. +The code-of-conduct applies to *all* conversations in the Rust project. ### Responsibility From 75050a2c57fc4fe59156b7ee66487285979f6fa9 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Thu, 23 Apr 2026 21:22:40 +0200 Subject: [PATCH 13/48] be more clear where the CoC is invoked --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index be247745..6c453296 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -95,7 +95,7 @@ If you are not sure where something you would like to do falls in this policy, p Don't try to hide it. #### Penalties -The policies below follow the same guidelines as the code of conduct: +The policies marked with a 🔨 follow the same guidelines as the code of conduct: Violations will first result in a warning, and repeated violations may result in a ban. - 🔨 Comments from a personal account originally authored by an LLM - 🔨 Violations of the "Be honest" section From b6a8662a55c2f8325adc7c0d2141af9e91eba207 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:30:34 +0200 Subject: [PATCH 14/48] minor edits; add "Motivation and guiding principles" section --- src/policies/llm-usage.md | 40 ++++++++++++++++++++++++++------------- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 6c453296..f4449043 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -4,29 +4,24 @@ For additional information about the policy itself, see [the appendix](#appendix ### Overview -Using an LLM while working on `rust-lang/rust` is conditionally allowed. -However, we find it important to keep the following points in mind: +Using LLMs while working on `rust-lang/rust` is conditionally allowed, when done with care. +LLMs are not a substitute for thought, +and we do not allow them to be used in ways that risk losing our shared social and technical understanding of the project, +nor in ways that hurt our goals of creating a strong community. -- 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. -- LLMs are a new technology, and we are still learning how to use, moderate, and improve them. - Since we're still learning, we have chosen an intentionally conservative policy that lets us maintain the standard of quality that Rust is known for. - -Therefore, the guidelines are roughly as follows: +The policy's guidelines are roughly as follows: > It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**. > LLMs work best when used as a tool to write *better*, not *faster*. +### Rules #### Legend - - ✅ Allowed - ❌ Banned - ⚠️ Allowed with caveats. Must disclose that an LLM was used. - ℹ️ Adds additional detail to the policy. These bullets are normative. -### Rules - #### ✅ Allowed The following are allowed. - Asking an LLM questions about an existing codebase. @@ -82,11 +77,30 @@ since they haven't yet established trust with their reviewers. All of these **must** disclose that an LLM was used. ## Appendix +### Motivation and guiding principles + +There is not a consensus within the Rust project—and likely never will be—about when/how/where it is acceptable to use AI-based tools. +Many members of the Rust project and community find value in AI; +many others feel that its negative impact on society and the climate are severe enough that no use is acceptable. +Still others are working out their opinion. + +Despite these differences, there are many common goals we all share: + +- Building a community of deep experts in our collective projects. +- Building an inclusive community where all feel welcome and respected. + +To achieve those goals, this policy is designed with the following points in mind: + +- 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. +- LLMs are a new technology, and we are still learning how to use, moderate, and improve them. + Since we're still learning, we have chosen an intentionally conservative policy that lets us maintain the standard of quality that Rust is known for. + ### Moderation policy #### 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/). -Do not try to be the police for whether someone has used an LLM. +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. #### Be honest @@ -136,4 +150,4 @@ a simple majority of members of teams using rust-lang/rust (without concerns). 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. +- 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. From 9a944f7db4bfa6cf25794458ddb9a2b451714069 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:30:54 +0200 Subject: [PATCH 15/48] Relax and clarify moderation guidelines --- src/policies/llm-usage.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index f4449043..fb671cd0 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -111,11 +111,10 @@ Don't try to hide it. #### Penalties The policies marked with a 🔨 follow the same guidelines as the code of conduct: Violations will first result in a warning, and repeated violations may result in a ban. -- 🔨 Comments from a personal account originally authored by an LLM - 🔨 Violations of the "Be honest" section Other violations are left up to the discretion of reviewers and moderators. -For most cases we recommend closing and locking the PR or issue, but not escalating further. +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. All contributors must be treated with respect. From 14956c3d6c0f8f6ad8706aca2c02c8c67aed3237 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:36:03 +0200 Subject: [PATCH 16/48] Carve out a space for experimentation --- src/policies/llm-usage.md | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index fb671cd0..22eaca1e 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -13,7 +13,7 @@ The policy's guidelines are roughly as follows: > It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**. -> LLMs work best when used as a tool to write *better*, not *faster*. +> We carve out a space for "experimentation" to inform future revisions to this policy. ### Rules #### Legend @@ -42,11 +42,8 @@ The following are banned. - Documentation that is originally authored by an LLM. - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. -- Code changes that are originally authored by an LLM. - - ℹ️ This does not include "trivial" changes that do not meet the [threshold of originality](https://fsfe.org/news/2025/news-20250515-01.en.html), which fall under ⚠️ below. - - ℹ️ 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). - - See also "learning from an LLM's solution" in ⚠️ below. + 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. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, @@ -63,6 +60,28 @@ since they haven't yet established trust with their reviewers. - Using machine-translation (e.g. Google Translate) from your native language without posting your original message. Doing so can introduce new miscommunications that weren't there originally, and prevents someone who speaks the language from providing a better translation. - ℹ️ Posting both your original message and the translated version is always ok, but you must still disclose that machine-translation was used. +- "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. + 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. + - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. + 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. + - ℹ️ Examples: + - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. + - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. + - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. + 1. "High-quality" means that it is held to at least the same standard as other code changes. + Everyone reads code, not just the author and reviewer; + we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. + 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. + - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. + - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. + There are no exceptions for "writing the tests seems hard". + 5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. + - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. + - ℹ️ A review from a project member does not substitute for self-review. + Authors are expected to review their own code before posting and after each change. - Using an LLM as a "review bot" for PRs. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. @@ -94,7 +113,8 @@ To achieve those goals, this policy is designed with the following points in min - 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. - LLMs are a new technology, and we are still learning how to use, moderate, and improve them. - Since we're still learning, we have chosen an intentionally conservative policy that lets us maintain the standard of quality that Rust is known for. + Since we're still learning, we have chosen an intentionally conservative policy that lets us maintain the standard of quality that Rust is known for; + but leave space open to experiment with LLMs to inform future policies. ### Moderation policy From 8fe728119f50cc2183dcbf119f386f41aaa75a59 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:38:45 +0200 Subject: [PATCH 17/48] fix typo --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 22eaca1e..c0d5b00e 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -71,7 +71,7 @@ since they haven't yet established trust with their reviewers. - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. - 1. "High-quality" means that it is held to at least the same standard as other code changes. + 3. "High-quality" means that it is held to at least the same standard as other code changes. Everyone reads code, not just the author and reviewer; we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. From 791e46f89483206f6341a6b9386a9ce6fbeef4f4 Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:41:32 +0200 Subject: [PATCH 18/48] recommend adversarial review from another LLM --- src/policies/llm-usage.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index c0d5b00e..89bb23ba 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -82,6 +82,7 @@ since they haven't yet established trust with their reviewers. - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. - ℹ️ A review from a project member does not substitute for self-review. Authors are expected to review their own code before posting and after each change. + - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. - Using an LLM as a "review bot" for PRs. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. From 8520038cc6465b6765069f002ab1f9836345f1fe Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:44:39 +0200 Subject: [PATCH 19/48] markdown formatting --- src/policies/llm-usage.md | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 89bb23ba..04a7ebd3 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -64,25 +64,25 @@ since they haven't yet established trust with their reviewers. - ℹ️ 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. - 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. - 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. - - ℹ️ Examples: - - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. - - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. - - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. - 3. "High-quality" means that it is held to at least the same standard as other code changes. - Everyone reads code, not just the author and reviewer; - we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. - 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. - - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. - - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. - There are no exceptions for "writing the tests seems hard". - 5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. - - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. - - ℹ️ A review from a project member does not substitute for self-review. - Authors are expected to review their own code before posting and after each change. - - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. + 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. + - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. + 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. + - ℹ️ Examples: + - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. + - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. + - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. + 3. "High-quality" means that it is held to at least the same standard as other code changes. + Everyone reads code, not just the author and reviewer; + we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. + 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. + - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. + - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. + There are no exceptions for "writing the tests seems hard". + 5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. + - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. + - ℹ️ A review from a project member does not substitute for self-review. + Authors are expected to review their own code before posting and after each change. + - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. - Using an LLM as a "review bot" for PRs. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. From b14e8ca10f6467f86135d6bbc165843dc0e0fbeb Mon Sep 17 00:00:00 2001 From: Jynn Nelson Date: Tue, 28 Apr 2026 19:46:05 +0200 Subject: [PATCH 20/48] more markdown formatting --- src/policies/llm-usage.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 04a7ebd3..904b4e56 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -65,24 +65,24 @@ since they haven't yet established trust with their reviewers. 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. 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. + - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. - - ℹ️ Examples: - - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. - - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. - - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. + - ℹ️ Examples: + - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. + - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. + - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. 3. "High-quality" means that it is held to at least the same standard as other code changes. Everyone reads code, not just the author and reviewer; we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. - - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. - - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. - There are no exceptions for "writing the tests seems hard". + - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. + - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. + There are no exceptions for "writing the tests seems hard". 5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. - - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. - - ℹ️ A review from a project member does not substitute for self-review. - Authors are expected to review their own code before posting and after each change. - - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. + - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. + - ℹ️ A review from a project member does not substitute for self-review. + Authors are expected to review their own code before posting and after each change. + - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. - Using an LLM as a "review bot" for PRs. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. From 69b6dc15e0ac30a23f3f2961e19d968be83fc3bf Mon Sep 17 00:00:00 2001 From: jyn Date: Wed, 13 May 2026 21:25:05 +0200 Subject: [PATCH 21/48] Note that explicitly marking LLM content is ok --- src/policies/llm-usage.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 904b4e56..ac652e8b 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -38,6 +38,8 @@ The following are allowed. 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. + - ℹ️ 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. - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. From d682475ef0d8502afd1d37101d2ecd4400760d1f Mon Sep 17 00:00:00 2001 From: jyn Date: Wed, 13 May 2026 21:25:05 +0200 Subject: [PATCH 22/48] Exempt t-security-response from a few requirements --- src/policies/llm-usage.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index ac652e8b..952bac75 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -98,6 +98,10 @@ since they haven't yet established trust with their reviewers. All of these **must** disclose that an LLM was used. +As a special case, T-security-response is exempt from the "solicited", "non-critical", and "well-tested" rules for LLM-authored code. +This only applies to team members of T-security-response, and only for security bugs. +If you believe your bug is security critical, please report it to security-response through [normal channels](https://rust-lang.org/policies/security/). + ## Appendix ### Motivation and guiding principles From ea4e5043ceaedeb47f45976769e493c5e227cff3 Mon Sep 17 00:00:00 2001 From: jyn Date: Wed, 13 May 2026 21:25:05 +0200 Subject: [PATCH 23/48] Make "solicited" even stricter --- src/policies/llm-usage.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 952bac75..fca722eb 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -68,6 +68,9 @@ since they haven't yet established trust with their reviewers. - Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM. 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. + - ℹ️ As an additional check, the team that owns the code must be pinged on (but does not need to complete an MCP for) LLM-authored PRs, + and the reviewer must allow 48 hours to elapse after the ping before merging the PR. + Teams can choose to remove this requirement for code they own by completing an FCP. 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. - ℹ️ Examples: - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. From cd9aecdc256bb1392f42e40648e78e70686af40b Mon Sep 17 00:00:00 2001 From: jyn Date: Wed, 13 May 2026 21:45:03 +0200 Subject: [PATCH 24/48] Revert "Exempt t-security-response from a few requirements" They don't actually need the exemption, being able to post the security report is enough for their needs. This reverts commit d682475ef0d8502afd1d37101d2ecd4400760d1f. --- src/policies/llm-usage.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index fca722eb..46ca7ab5 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -101,10 +101,6 @@ since they haven't yet established trust with their reviewers. All of these **must** disclose that an LLM was used. -As a special case, T-security-response is exempt from the "solicited", "non-critical", and "well-tested" rules for LLM-authored code. -This only applies to team members of T-security-response, and only for security bugs. -If you believe your bug is security critical, please report it to security-response through [normal channels](https://rust-lang.org/policies/security/). - ## Appendix ### Motivation and guiding principles From ee4f26c19bc211284105b0d7fc700ab0a0921b95 Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 17:18:58 +0200 Subject: [PATCH 25/48] address a few of TC's concerns --- src/policies/llm-usage.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 46ca7ab5..b3490f2f 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -33,6 +33,9 @@ The following are allowed. - 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. +- Using an LLM to generate possible solutions to an issue, learning from them, and then writing something from scratch in your own style. +- Syncing code and documentation into `rust-lang/rust` (e.g., using submodules, subtrees, [josh](https://github.com/josh-project/josh), etc.) from other repositories that do not follow this policy. +- Using an LLM in the creation of experimental code changes that are not meant to be reviewed and will never be merged but must live as draft PRs on `rust-lang/rust` for tooling reasons, such as to run crater or perf. #### ❌ Banned The following are banned. @@ -58,7 +61,6 @@ The following are decided on a case-by-case basis. In general, new contributors will be scrutinized more heavily than existing contributors, since they haven't yet established trust with their reviewers. -- Using an LLM to generate a solution to an issue, learning from its solution, and then rewriting it from scratch in your own style. - Using machine-translation (e.g. Google Translate) from your native language without posting your original message. Doing so can introduce new miscommunications that weren't there originally, and prevents someone who speaks the language from providing a better translation. - ℹ️ Posting both your original message and the translated version is always ok, but you must still disclose that machine-translation was used. From 795657402268ff4989d73213e8786d2c9dc124a4 Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 17:18:58 +0200 Subject: [PATCH 26/48] address a few of Jack's concerns --- src/policies/llm-usage.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index b3490f2f..0dd4e65a 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -69,15 +69,13 @@ since they haven't yet established trust with their reviewers. 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. 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - - ℹ️ New contributors are discouraged from using an LLM unless they first talk with a reviewer. - - ℹ️ As an additional check, the team that owns the code must be pinged on (but does not need to complete an MCP for) LLM-authored PRs, - and the reviewer must allow 48 hours to elapse after the ping before merging the PR. - Teams can choose to remove this requirement for code they own by completing an FCP. + - ℹ️ New contributors cannot use an LLM unless they first talk with a reviewer. + This must be the *same* reviewer who will be assigned to the PR. 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. - ℹ️ Examples: - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. - - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. + - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. 3. "High-quality" means that it is held to at least the same standard as other code changes. Everyone reads code, not just the author and reviewer; we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. From b88855aa6ed6e6cfa235453fe027a7c4e5571fdf Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 17:27:24 +0200 Subject: [PATCH 27/48] remove the 'additional scrutiny' examples --- src/policies/llm-usage.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 0dd4e65a..420d0d4f 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -75,7 +75,6 @@ since they haven't yet established trust with their reviewers. - ℹ️ Examples: - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. - - Changes that occasionally affect soundness, like `compiletest`, diagnostics, and feature-gated code, are discouraged and may be subject to additional scrutiny. 3. "High-quality" means that it is held to at least the same standard as other code changes. Everyone reads code, not just the author and reviewer; we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. From 4305e14a7d5cd32eb443070e882477c5fc43d2d6 Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 17:28:58 +0200 Subject: [PATCH 28/48] move 'using an llm to discover bugs' to the caveats section, without changes to the rules --- src/policies/llm-usage.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 420d0d4f..c8eb49d3 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -30,9 +30,6 @@ The following are allowed. - 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. - Using an LLM to generate possible solutions to an issue, learning from them, and then writing something from scratch in your own style. - Syncing code and documentation into `rust-lang/rust` (e.g., using submodules, subtrees, [josh](https://github.com/josh-project/josh), etc.) from other repositories that do not follow this policy. - Using an LLM in the creation of experimental code changes that are not meant to be reviewed and will never be merged but must live as draft PRs on `rust-lang/rust` for tooling reasons, such as to run crater or perf. @@ -67,6 +64,9 @@ since they haven't yet established trust with their reviewers. - "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). +- 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. - Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM. 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - ℹ️ New contributors cannot use an LLM unless they first talk with a reviewer. From ab6f8a4d0739778fd06ef68cec2fe62fefd7622e Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 17:48:42 +0200 Subject: [PATCH 29/48] move LLM-authored code to its own section; add a zulip stream as policy --- src/policies/llm-usage.md | 49 +++++++++++++++++++++++---------------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index c8eb49d3..705d37d4 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -67,26 +67,6 @@ since they haven't yet established trust with their reviewers. - 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. -- Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM. - 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - - ℹ️ New contributors cannot use an LLM unless they first talk with a reviewer. - This must be the *same* reviewer who will be assigned to the PR. - 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. - - ℹ️ Examples: - - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. - - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. - 3. "High-quality" means that it is held to at least the same standard as other code changes. - Everyone reads code, not just the author and reviewer; - we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. - 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. - - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. - - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. - There are no exceptions for "writing the tests seems hard". - 5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. - - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. - - ℹ️ A review from a project member does not substitute for self-review. - Authors are expected to review their own code before posting and after each change. - - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. - Using an LLM as a "review bot" for PRs. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. @@ -100,6 +80,35 @@ since they haven't yet established trust with their reviewers. All of these **must** disclose that an LLM was used. +#### Experiment: LLM-authored code changes + +Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure. +1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. + - ℹ️ New contributors cannot use an LLM unless they first talk with a reviewer. + This must be the *same* reviewer who will be assigned to the PR. +2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. + - ℹ️ Examples: + - Changes to internal tooling like `tidy`, `x setup`, and `linkchecker` are probably ok. + - Changes that have a strong soundness impact, like the trait system, MIR building, or the query system are probably not ok. +3. "High-quality" means that it is held to at least the same standard as other code changes. + Everyone reads code, not just the author and reviewer; + we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. +4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. + - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. + - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. + There are no exceptions for "writing the tests seems hard". +5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. + - ℹ️ All review requirements in [our existing review policy](../compiler/reviews.md#basic-reviewing-requirements) still apply. + - ℹ️ A review from a project member does not substitute for self-review. + Authors are expected to review their own code before posting and after each change. + - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. + +LLM-authored PRs must be tagged with a new `ai-assisted` label. +All such PRs will be posted to a new (private) Zulip channel, which will be accessible to all members of the `rust-lang` organization. +The goal of the channel is *not* to act as an additional gate-keeper on LLM-authored PRs. +Instead, it's to collect information about *whether this experiment is working*: +Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? + ## Appendix ### Motivation and guiding principles From d9d8238910e06c07cd86327e4d3caf1b1ca63c60 Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 18:44:26 +0200 Subject: [PATCH 30/48] add a section about staying on-topic --- src/policies/llm-usage.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 705d37d4..7d6d552f 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -81,7 +81,6 @@ since they haven't yet established trust with their reviewers. All of these **must** disclose that an LLM was used. #### Experiment: LLM-authored code changes - Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure. 1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. - ℹ️ New contributors cannot use an LLM unless they first talk with a reviewer. @@ -109,6 +108,15 @@ The goal of the channel is *not* to act as an additional gate-keeper on LLM-auth Instead, it's to collect information about *whether this experiment is working*: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? +This new channel will have higher-than-normal standards for what counts as on-topic. +For example, the following are on-topic: +- Whether a PR meets the criteria for the experiment exception +- Whether a PR follows the policy in general + +And the following are off-topic: +- Technical and design discussions. These should be posted directly on the PR or in a public Zulip channel. +- Discussions about effort, communication style, or intent +- General discussions about the LLM policy ## Appendix ### Motivation and guiding principles From 83b9363fe37c06268d8db749f68dd18fe7f416aa Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 20:53:54 +0200 Subject: [PATCH 31/48] wording --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 7d6d552f..a382ea22 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -108,7 +108,7 @@ The goal of the channel is *not* to act as an additional gate-keeper on LLM-auth Instead, it's to collect information about *whether this experiment is working*: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? -This new channel will have higher-than-normal standards for what counts as on-topic. +Because the new channel is private, it will have higher-than-normal standards for what counts as on-topic. For example, the following are on-topic: - Whether a PR meets the criteria for the experiment exception - Whether a PR follows the policy in general From 9efffad99114e1ef5c5ef057d09d71f61808a9db Mon Sep 17 00:00:00 2001 From: jyn Date: Thu, 14 May 2026 20:56:21 +0200 Subject: [PATCH 32/48] relax moderation policy guidelines --- src/policies/llm-usage.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index a382ea22..275dd0a4 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -156,7 +156,8 @@ Violations will first result in a warning, and repeated violations may result in - 🔨 Violations of the "Be honest" section 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. +For minor violations we recommend telling the author that we can't review the PR until it complies with the policy, with pointers to exactly what they need to do. +For major violations or extractive PRs, we recommend closing the PR or issue. Using an LLM does **not** mean it's ok to harrass a contributor. All contributors must be treated with respect. From 24f236cc591c087c45f7668ab98f08de383060cb Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 07:31:08 +0200 Subject: [PATCH 33/48] ban llms from writing safety comments --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 275dd0a4..c96bdd4a 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -42,7 +42,7 @@ The following are banned. 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. - - ℹ️ This includes non-trivial source comments, such as doc-comments or multiple paragraphs of non-doc-comments. + - ℹ️ This includes non-trivial source comments, such as doc-comments, safety comments, or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. 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. From f85aac6d34db8c65b876e0d84aca0173e1ae5e97 Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 07:33:34 +0200 Subject: [PATCH 34/48] Group some "personal use" bullets together --- src/policies/llm-usage.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index c96bdd4a..82333f1d 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -24,13 +24,14 @@ The policy's guidelines are roughly as follows: #### ✅ 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 generate possible solutions to an issue, learning from them, and then writing something from scratch in your own style. +- Any use of an LLM where you are the only one who sees the output. For example: + - 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. + - Using an LLM to generate possible solutions to an issue, learning from them, and then writing something from scratch in your own style. - Syncing code and documentation into `rust-lang/rust` (e.g., using submodules, subtrees, [josh](https://github.com/josh-project/josh), etc.) from other repositories that do not follow this policy. - Using an LLM in the creation of experimental code changes that are not meant to be reviewed and will never be merged but must live as draft PRs on `rust-lang/rust` for tooling reasons, such as to run crater or perf. From adfc5e2cd9198d8b60295e0e336847aabe66458f Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 08:36:57 +0200 Subject: [PATCH 35/48] remove "by a team" phrase --- src/policies/llm-usage.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 82333f1d..9c185430 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -48,7 +48,7 @@ The following are banned. 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. + LLM reviews, if enabled, **must** be advisory-only. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, but they may not have a policy that an LLM review substitutes for a human review. - ℹ️ See "review bots" in ⚠️ below. @@ -69,10 +69,10 @@ since they haven't yet established trust with their reviewers. 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. - Using an LLM as a "review bot" for PRs. + - ℹ️ Review bots that post without being approved by a maintainer will be banned. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. You **must not** post (or allow a tool to post) LLM reviews verbatim on your personal account unless clearly quoted with your own personal interpretation of the bot's analysis. - ℹ️ Review bot accounts must be blockable by individual users via the standard GitHub user-blocking mechanism. (Note that some GitHub "app" accounts post comments that look like users but cannot be blocked.) - - ℹ️ Review bots that post without being approved by a maintainer will be banned. - ℹ️ If a more reliable tool, such as a linter or formatter, already exists for the language you're writing, we strongly suggest using that tool instead of or in addition to the LLM. - ℹ️ Configure LLM review tools to reduce false positives and excessive focus on trivialities, as these are common, exhausting failure modes. - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". From 014cf85fc13a146cbc4f7db8780f03ec3da49c6b Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 15:18:23 +0200 Subject: [PATCH 36/48] clarify wording on harrassment policy --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 9c185430..52bba115 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -160,7 +160,7 @@ Other violations are left up to the discretion of reviewers and moderators. For minor violations we recommend telling the author that we can't review the PR until it complies with the policy, with pointers to exactly what they need to do. For major violations or extractive PRs, we recommend closing the PR or issue. -Using an LLM does **not** mean it's ok to harrass a contributor. +It is **not** ok to harrass a contributor for using an LLM. All contributors must be treated with respect. The code-of-conduct applies to *all* conversations in the Rust project. From db8fdae4a3912f0ef78dc516ee6d4b9e900fca6b Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 15:22:21 +0200 Subject: [PATCH 37/48] t-lang didn't get a vote, so narrow the policy not to apply to them --- src/policies/llm-usage.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 52bba115..be8ebde8 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -39,6 +39,8 @@ The following are allowed. 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. + - ℹ️ This does *not* include stabilization reports, t-lang proposals, and changes to documentation owned by t-lang. + T-lang is free to set their own separate policy for those. - ℹ️ 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. From 196cf632749e752d276325c9778ab0ba54a5935e Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 15:27:59 +0200 Subject: [PATCH 38/48] clarify wording on modification policy --- src/policies/llm-usage.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index be8ebde8..ff564476 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -189,8 +189,9 @@ If you have a use of LLMs in mind that isn't on this list, judge it in the spiri This policy is not set in stone, and we can evolve it as we gain more experience working with LLMs. Minor changes, such as typo fixes, only require a normal PR approval. -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). +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. +- No outstanding concerns from those members. This policy can be dissolved in a few ways: From 6374d5747e5b4be83b79af0eb6c696673b379aa0 Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 15:29:11 +0200 Subject: [PATCH 39/48] clarify wording on "be honest" policy --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index ff564476..91f6a5b6 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -149,7 +149,7 @@ 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. #### 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. +Conversely, lying about whether you've used an LLM, or attempting to hide the extent of the use, is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. If you are not sure where something you would like to do falls in this policy, please talk to the [moderation team](mailto:rust-mods@rust-lang.org). Don't try to hide it. From 8a1ce25d78f9d20a85201bf8808f1c8081be41cf Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 16:09:13 +0200 Subject: [PATCH 40/48] s/authored/created/g --- src/policies/llm-usage.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 91f6a5b6..b20172db 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -37,18 +37,18 @@ The following are allowed. #### ❌ Banned The following are banned. -- Comments from a personal user account that are originally authored by an LLM. +- Comments from a personal user account that are originally created by an LLM. - ℹ️ This also applies to issue bodies and PR descriptions. - ℹ️ This does *not* include stabilization reports, t-lang proposals, and changes to documentation owned by t-lang. T-lang is free to set their own separate policy for those. - ℹ️ 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. +- Documentation that is originally created by an LLM. - ℹ️ This includes non-trivial source comments, such as doc-comments, safety comments, or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. 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. + but they must not be used to create the message itself. - Treating an LLM review as a sufficient condition to merge or reject a change. LLM reviews, if enabled, **must** be advisory-only. Teams can have a policy that code can be merged without review, and they can have a policy that code must be reviewed by at least one person, @@ -83,9 +83,9 @@ since they haven't yet established trust with their reviewers. All of these **must** disclose that an LLM was used. -#### Experiment: LLM-authored code changes -Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally authored by an LLM are allowed, with disclosure. -1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-authored PR. +#### Experiment: LLM-created code changes +Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure. +1. "Solicited" means that a reviewer has communicated *ahead of time* that they are willing to review an LLM-created PR. - ℹ️ New contributors cannot use an LLM unless they first talk with a reviewer. This must be the *same* reviewer who will be assigned to the PR. 2. "Non-critical" means that it is extremely unlikely for the PR to cause a [soundness](https://jacko.io/safety_and_soundness.html) regression. @@ -96,7 +96,7 @@ Solicited, non-critical, high-quality, well-tested, and well-reviewed code chang Everyone reads code, not just the author and reviewer; we are not interested in "vibe-coded" PRs that degrade the quality of the codebase. 4. "Well-tested" means that you have covered all edge-cases that either you or the reviewer can think of. - - ℹ️ LLM-authored PRs will be held to a higher standard than human-authored PRs, because LLMs make it easier to write tests. + - ℹ️ LLM-created PRs will be held to a higher standard than human-created PRs, because LLMs make it easier to write tests. - ℹ️ If there is no existing test suite for a section of code, you must either write a new test suite or close the PR. There are no exceptions for "writing the tests seems hard". 5. "Well-reviewed" means the author and reviewer both commit to fully understanding the code. @@ -105,9 +105,9 @@ Solicited, non-critical, high-quality, well-tested, and well-reviewed code chang Authors are expected to review their own code before posting and after each change. - ℹ️ We recommend, but do not require, using a second LLM for adversarial local review before publishing your changes. -LLM-authored PRs must be tagged with a new `ai-assisted` label. +LLM-created PRs must be tagged with a new `ai-assisted` label. All such PRs will be posted to a new (private) Zulip channel, which will be accessible to all members of the `rust-lang` organization. -The goal of the channel is *not* to act as an additional gate-keeper on LLM-authored PRs. +The goal of the channel is *not* to act as an additional gate-keeper on LLM-created PRs. Instead, it's to collect information about *whether this experiment is working*: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? @@ -169,12 +169,12 @@ The code-of-conduct applies to *all* conversations in the Rust project. ### Responsibility Your contributions are your responsibility; you cannot place any blame on an LLM. -- ℹ️ This includes when asking people to address review comments originally authored by an LLM. See "review bots" under ⚠️ above. +- ℹ️ This includes when asking people to address review comments originally created by an LLM. See "review bots" under ⚠️ above. -### The meaning of "originally authored" +### The meaning of "originally created" -This document uses the phrase "originally authored" to mean "text that was generated by an LLM (and then possibly edited by a human)". -No amount of editing can change authorship; authorship sets the initial style and it is very hard to change once it's set. +This document uses the phrase "originally created" to mean "text that was generated by an LLM (and then possibly edited by a human)". +No amount of editing can change how it was originally created; how it was generated sets the initial style and it's very hard to change once it's set. For more background about analogous reasoning, see ["What Colour are your bits?"](https://ansuz.sooke.bc.ca/entry/23) From 742d9f43478d69ba223f7eee2e27437c72b1e28e Mon Sep 17 00:00:00 2001 From: jyn Date: Fri, 15 May 2026 19:13:09 +0200 Subject: [PATCH 41/48] spruce up "spirit of the law" section --- src/policies/llm-usage.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index b20172db..b78516ba 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -182,8 +182,9 @@ For more background about analogous reasoning, see ["What Colour are your bits?" This policy does not aim to be exhaustive. If you have a use of LLMs in mind that isn't on this list, judge it in the spirit of this overview: -- 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 ❌ +- Using an LLM for your own personal use is likely allowed ✅ +- Showing LLM output to another human without solicitation is likely banned ❌ +- Making a decision based on LLM output requires disclosure ⚠️ ### Conditions for modification or dissolution This policy is not set in stone, and we can evolve it as we gain more experience working with LLMs. From 235432bdc5961221775f5101a1487470bb80a42e Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 09:58:57 +0200 Subject: [PATCH 42/48] wording --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index b78516ba..1f32fc5c 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -26,7 +26,7 @@ The policy's guidelines are roughly as follows: The following are allowed. - Any use of an LLM where you are the only one who sees the output. For example: - Asking an LLM questions about an existing codebase. - - Asking an LLM to summarize comments on an issue, PR, or RFC. + - Asking an LLM to summarize comments on an issue or PR. - ℹ️ 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. From 9396306a58a6db883ab57164babfbd37a99b21e3 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 09:58:57 +0200 Subject: [PATCH 43/48] further clarify moderation section --- src/policies/llm-usage.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 1f32fc5c..3181924d 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -147,6 +147,11 @@ To achieve those goals, this policy is designed with the following points in min ["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. +You are not required to "actively look" for whether an LLM was involved. + +Reporting to moderation is not intended to be a penalty. +The mod team is interested in seeing non-violations as well as violations. +As always, the mod team is free to exercise their own judgement and discretion. #### Be honest Conversely, lying about whether you've used an LLM, or attempting to hide the extent of the use, is considered a [code of conduct](https://rust-lang.org/policies/code-of-conduct/) violation. From 33b1407c740481213578687bc02381525a3a706d Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 09:58:57 +0200 Subject: [PATCH 44/48] Add a "scope" section --- src/policies/llm-usage.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 3181924d..32dca0e6 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -32,18 +32,16 @@ The following are allowed. - ℹ️ This does not apply to public comments. See "review bots" under ⚠️ below. - Writing dev-tools for your own personal use using an LLM. - Using an LLM to generate possible solutions to an issue, learning from them, and then writing something from scratch in your own style. -- Syncing code and documentation into `rust-lang/rust` (e.g., using submodules, subtrees, [josh](https://github.com/josh-project/josh), etc.) from other repositories that do not follow this policy. - Using an LLM in the creation of experimental code changes that are not meant to be reviewed and will never be merged but must live as draft PRs on `rust-lang/rust` for tooling reasons, such as to run crater or perf. #### ❌ Banned The following are banned. - Comments from a personal user account that are originally created by an LLM. - ℹ️ This also applies to issue bodies and PR descriptions. - - ℹ️ This does *not* include stabilization reports, t-lang proposals, and changes to documentation owned by t-lang. - T-lang is free to set their own separate policy for those. - ℹ️ 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. + - ℹ️ See also "Scope" in the appendix below. - Documentation that is originally created by an LLM. - ℹ️ This includes non-trivial source comments, such as doc-comments, safety comments, or multiple paragraphs of non-doc-comments. - ℹ️ This includes compiler diagnostics. @@ -121,6 +119,23 @@ And the following are off-topic: - Discussions about effort, communication style, or intent - General discussions about the LLM policy ## Appendix +### Scope + +This policy only applies to `rust-lang/rust`, and only to the teams that have ratified it: compiler, libs, types, rustdoc, bootstrap, and their subteams. +The following are not in scope and are free to set their own policies: +- Other repositories in `rust-lang` +- Submodules, subtrees, and crates.io dependencies +- Teams that have not ratified the policy, such as lang and edition + +For example, the following do not fall under the policy: +- Tracking issues for T-lang +- T-lang proposals +- Stabilization reports +- Language documentation +- The style guide +- Names of compiler lints. This only applies to the names themselves; the diagnostic messages are still covered under this policy. +- Direct quotes from any of the above in documentation or diagnostics. + ### Motivation and guiding principles There is not a consensus within the Rust project—and likely never will be—about when/how/where it is acceptable to use AI-based tools. From 08a6b17185d87820642a8985b67d3e61c6d15ca9 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 10:13:57 +0200 Subject: [PATCH 45/48] add back "better, not faster" quote --- src/policies/llm-usage.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 32dca0e6..0f11de0d 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -13,6 +13,8 @@ The policy's guidelines are roughly as follows: > It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to **create**. +> LLMs work best when used as a tool to write *better*, not *faster*. + > We carve out a space for "experimentation" to inform future revisions to this policy. ### Rules From 3740dc5975c014159122e3259d80109267dbb5a2 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 10:13:57 +0200 Subject: [PATCH 46/48] wording --- src/policies/llm-usage.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 0f11de0d..c907afd6 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -67,9 +67,10 @@ since they haven't yet established trust with their reviewers. - "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). -- 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. +- Using an LLM to discover bugs, as long as you personally verify the bug. 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. + - ℹ️ See also "Comments from a personal user account" under ❌ above. - Using an LLM as a "review bot" for PRs. - ℹ️ Review bots that post without being approved by a maintainer will be banned. - ℹ️ Review bots **must** have a separate GitHub account that marks them as an LLM. @@ -81,7 +82,7 @@ since they haven't yet established trust with their reviewers. - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. - ℹ️ This does not apply to private use of an LLM for reviews; see ✅ above. -All of these **must** disclose that an LLM was used. +All uses under "⚠️ Allowed with caveats" **must** disclose that an LLM was used. #### Experiment: LLM-created code changes Solicited, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure. From fb37c6905cbc769e6fbbba4f5762b01326977a4a Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 10:24:49 +0200 Subject: [PATCH 47/48] delete confusing review bot sentence --- src/policies/llm-usage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index c907afd6..76ed66fe 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -78,7 +78,7 @@ since they haven't yet established trust with their reviewers. - ℹ️ Review bot accounts must be blockable by individual users via the standard GitHub user-blocking mechanism. (Note that some GitHub "app" accounts post comments that look like users but cannot be blocked.) - ℹ️ If a more reliable tool, such as a linter or formatter, already exists for the language you're writing, we strongly suggest using that tool instead of or in addition to the LLM. - ℹ️ Configure LLM review tools to reduce false positives and excessive focus on trivialities, as these are common, exhausting failure modes. - - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. It's ok to require a *response* to each comment but the response can be "the bot's wrong here". + - ℹ️ LLM comments **must not** be blocking; reviewers must indicate which comments they want addressed. - In other words, reviewers must explicitly endorse an LLM comment before blocking a PR. They are responsible for their own analysis of the LLM's comment and cannot treat it as a CI failure. - ℹ️ This does not apply to private use of an LLM for reviews; see ✅ above. From 8444f54629dc472cdf0573237ff8eb03dc1a16a5 Mon Sep 17 00:00:00 2001 From: jyn Date: Sat, 16 May 2026 10:30:51 +0200 Subject: [PATCH 48/48] add link to CoC --- src/policies/llm-usage.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/policies/llm-usage.md b/src/policies/llm-usage.md index 76ed66fe..32499dd4 100644 --- a/src/policies/llm-usage.md +++ b/src/policies/llm-usage.md @@ -164,7 +164,8 @@ To achieve those goals, this policy is designed with the following points in min #### 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. +If it's clear they've broken the rules, point them to this policy; +if it's borderline, [report it to the mods](https://rust-lang.org/policies/code-of-conduct/) and move on. You are not required to "actively look" for whether an LLM was involved. Reporting to moderation is not intended to be a penalty.