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](rust-lang/leadership-council#273 (comment)),
although we have taken the liberty of moving the Rust project's prior art to the top.
We thank her for her help.

### Rust
- [Moderation team's spam policy](https://github.com/rust-lang/moderation-team/blob/main/policies/spam.md/#fully-or-partially-automated-contribs)
- [Compiler team's "burdensome PRs" policy](rust-lang/compiler-team#893)
### Other organizations
 These are organized along a spectrum of AI friendliness, where top is least friendly, and bottom is most friendly.
- full ban
  - [postmarketOS](https://docs.postmarketos.org/policies-and-processes/development/ai-policy.html)
        - also explicitly bans encouraging others to use AI for solving problems related to postmarketOS
        - multi point ethics based rational with citations included
  - [zig](https://ziglang.org/code-of-conduct/)
    - philosophical, cites [Profession (novella)](https://en.wikipedia.org/wiki/Profession_(novella))
    - rooted in concerns around the construction and origins of original thought
  - [servo](https://book.servo.org/contributing/getting-started.html#ai-contributions)
    - more pragmatic, directly lists concerns around ai, fairly concise
  - [qemu](https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators)
    - pragmatic, focuses on copyright and licensing concerns
    - explicitly allows AI for exploring api, debugging, and other non generative assistance, other policies do not explicitly ban this or mention it in any way
- allowed with supervision, human is ultimately responsible
  - [scipy](https://github.com/scipy/scipy/pull/24583/changes)
    - strict attribution policy including name of model
  - [llvm](https://llvm.org/docs/AIToolPolicy.html)
  - [blender](https://devtalk.blender.org/t/ai-contributions-policy/44202)
  - [linux kernel](https://kernel.org/doc/html/next/process/coding-assistants.html)
    - quite concise but otherwise seems the same as many in this category
  - [mesa](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/submittingpatches.rst)
    - framed as a contribution policy not an AI policy, AI is listed as a tool that can be used but emphasizes same requirements that author must understand the code they contribute, seems to leave room for partial understanding from new contributors.
        > Understand the code you write at least well enough to be able to explain why your changes are beneficial to the project.
  - [forgejo](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md)
    - bans AI for review, does not explicitly require contributors to understand code generated by ai.
      One could interpret the "accountability for contribution lies with contributor even if AI is used" line as implying this requirement, though their version seems poorly worded imo.
  - [firefox](https://firefox-source-docs.mozilla.org/contributing/ai-coding.html)
  - [ghostty](https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md)
    - pro-AI but views "bad users" as the source of issues with it and the only reason for what ghostty considers a "strict AI policy"
  - [fedora](https://communityblog.fedoraproject.org/council-policy-proposal-policy-on-ai-assisted-contributions/)
    - clearly inspired and is cited by many of the above, but is definitely framed more pro-ai than the derived policies tend to be
- [curl](https://curl.se/dev/contribute.html#on-ai-use-in-curl)
  - does not explicitly require humans understand contributions, otherwise policy is similar to above policies
- [linux foundation](https://www.linuxfoundation.org/legal/generative-ai)
  - encourages usage, focuses on legal liability, mentions that tooling exists to help automate managing legal liability, does not mention specific tools
- In progress
  - NixOS
    - NixOS/nixpkgs#410741

## Unresolved questions
[unresolved-questions]: #unresolved-questions

See the "Moderation guidelines" and "Drawbacks" section for a list of topics that are out of scope.

Author: jyn514

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)

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

src/policies/llm-usage.md

@@ -0,0 +1,105 @@
+## 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
+- Asking an LLM questions about an existing codebase.
+- Asking an LLM to summarize comments on an issue, PR, or RFC.
+    - ℹ️ This does not include 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 the Rust project.
+- 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.
+    - ℹ️ This applies even outside GitHub, such as in emails to help@crates.io or Zulip comments.
+    - ℹ️ 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.
+  - 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 can only be enabled by a Rust project team. 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 ❌