While the Rust project is a collection of technical artifacts, it is also a community of people who work together to build, maintain, and extend those artifacts. When we talk about "contributing to the Rust project", we partly mean work on those artifacts, but we also mean joining that community and collaborating with the people already there.

Even before this policy was created, people were using LLMs to contribute to rust-lang/rust. Some of those uses respected our community: translating messages to English so people could draft them in their native language; finding poor diagnostics for code snippets that new contributors to Rust might write; analyzing RFCs to see if they were missing a discussion of other parts of the language that could affect the design. Some of those uses, sometimes unintentionally, did not.

I've seen LLMs causing three main issues for our community:

1. Polished technical products no longer indicate effort and understanding.
2. Making code easier to write exacerbates our existing issues with review bandwidth.
3. People mechanically copy-pasting to and from an LLM is a waste of our time.

As time went on, these issues grew and grew, until we had to create dedicated channels and moderation policy for how to deal with them. However, those channels work against our goals of being transparent and welcoming, because new contributors have no idea what the rules are.

The new policy formalizes those rules publicly, so that new contributors know how to join our community without getting their PRs closed for reasons they don't understand, and so that existing reviewers can easily point to the rules as an actionable reason when closing PRs that don't follow them.

It used to be that if an open source project got a polished, well-tested, detailed PR, that indicated that there was someone on the other end who had put time, effort, and understanding into the PR. That influenced Rust's culture in several ways:

• We are generally reluctant to close PRs, since they represent someone else's hard work.
• Our process emphasizes incremental discussions, where PRs are allowed to change existing design if we discover new facts during creation or review.
• We treat PRs as an indication that someone is interested in joining our community and being mentored to work on future PRs.

With LLMs, none of these signals are reliable. Polished PRs no longer indicate effort; authors of polished PRs no longer necessarily understand their code—and in the case of autonomous agents, there is no longer someone on the other end at all; and because it's become so much easier to write code, a polished PR no longer indicates that someone is likely to stick around for the long term.

At the time of writing, there are 1,281 open PRs to rust-lang/rust. This represents a staggering amount of time invested by both authors and reviewers. We have long had the problem that there are more people who want to write code than people willing to review it. With the advent of LLMs, this problem only gets worse.

We will often get people who respond to review comments by copy-pasting them into their LLM, then copy-pasting its response back onto GitHub. Bluntly: this is a waste of everyone's time. If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine's.

Moreover, this is a breach of trust between the reviewer and the author. Our assumption when we review is that we're talking to a real person who wants to do their best work. Pasting LLM text creates suspicion: does the author actually care? Is there a person here at all?

The policy summarizes itself this way:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second category are heavily restricted.

No one except the author is required to read LLM output unless they choose to: LLM output isn't allowed in public docs, PR descriptions, or Github comments unless it's clearly marked; reviewers aren't required to look at LLM PRs if they don't want to.

No one is required to use LLMs to contribute to rust-lang/rust: policies must be written first for humans, and only summarized for machines; LLM reviews cannot substitute for human review or self-review.

You are allowed to generate LLM content that only you see, without disclosure, as long as you do not post it anywhere that you expect us to read or review.

Disclosure is required for machine translation, "trivial" changes, discovering bugs, and reviewing other people's work using an LLM. We welcome messages posted in your native language; English translation is not required to contribute.

There are very strict guidelines on LLM-generated code changes:

Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

The policy holds LLM-generated changes to a higher bar than human-authored changes, not a lower one: LLM PRs are required to have tests, full stop, regardless of how hard that is, as well as various other restrictions; LLMs must not generate soundness-critical changes unless the author is already a domain expert, and even then it's strongly discouraged.

You must disclose LLM-generated content. You can choose to not post LLM content, or you can choose to post it and disclose its origin. You may not hide LLM involvement.

You must disclose any LLM involvement in discovering or reporting issues. You must tell us if you found an issue using an LLM. You must clearly quote and indicate which parts of your report were LLM-generated; the "no LLM-generated comments" rule applies to you too.

I have written a list of guidelines you should follow if you make a PR to rust-lang/rust with LLM-generated code. You can avoid thinking about them, or indeed reading the list at all, if you follow this simple guideline from the policy:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

If you have volunteered to review LLM PRs, the following section applies to you. No one is required to review LLM PRs unless they volunteer.

Everyone is expected to follow the new policy, not just authors. That means it is your responsibility to check whether an LLM-created PR touches an area that's disallowed by the policy, such as docs, diagnostics, or soundness-critical changes. You may request that the author redo it without LLM-generated code, in which case this section doesn't apply.

Quite a lot of work has been put into this by moderators, team leads, reviewers, council representatives, and various other people inside and outside the project. Some of that work started months ago before the policy itself was written. I'd like to thank everyone who contributed, whether directly or indirectly.

This is not the end of the story. One of the goals of the policy is to help us gather data: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? The answers to those questions will help us determine how the policy changes in the future.

This is not the first LLM policy published by teams in the Rust project, and hopefully it will not be the last. While the current policy only applies to the rust-lang/rust monorepo, I still believe that Rust would benefit from a project-wide policy that specifies what we expect in chats, forums, public communications, repositories without an explicit policy, and other cross-project areas.