rust-lang/rust is adopting an LLM policy

Recently, five teams within the Rust project adopted a policy that I originally drafted, outlining how Large Language Models (LLMs) can be utilized when contributing to the rust-lang/rust monorepo. Crucially, this new policy isn't an official stance on LLMs, and it doesn't apply universally across the Rust project. I crafted this policy for a specific purpose, which I detail below.

This post explains why we created the policy, what it entails, and how it impacts contributors. The policy impacts the following groups of people: If you don't fall into one of these groups, you don't need to alter your approach to working with the Rust project. While the Rust project is a collection of technical artifacts, it's also a community of individuals working together to build, maintain, and extend those artifacts.

When we discuss contributing to the Rust project, we refer to both working on those artifacts and engaging with the existing community members. Before this policy was in place, individuals were already using LLMs to contribute to rust-lang/rust. Some of these uses aligned with our community guidelines: translating messages into English for contributors to draft in their native language; identifying subpar diagnostics in code snippets written by new Rust contributors; scrutinizing RFCs for potential omissions in discussions relevant to the design.

However, there were also instances where these uses didn't adhere to our community guidelines. Over time, these issues escalated and required the creation of dedicated channels and a moderation policy for addressing them. Nevertheless, these channels conflicted with our goals of transparency and welcomingness, as new contributors were unaware of the rules.

The new policy formalizes these rules publicly, ensuring new contributors understand how to join our community without having their PRs closed due to unclear reasons, and providing existing reviewers with a clear, actionable basis for rejecting PRs that don't comply with the policy. Previously, a polished, well-tested, detailed PR indicated that an author had invested time, effort, and understanding into their work, shaping Rust's culture in several ways: With LLMs, these signals are no longer reliable.

Polished PRs no longer signify the author's effort, nor do they guarantee that the author understands their code—particularly in the case of autonomous agents, where there is no human involved; and since it's become easier to generate code, a polished PR no longer implies a long-term commitment from the author. As of now, there are 1,281 open PRs to rust-lang/rust, representing a significant amount of time invested by both authors and reviewers.

Historically, there have been more people wanting to write code than there have been reviewers willing to take on that responsibility. The rise of LLMs exacerbates this imbalance. Most of the review process involves making decisions, not just catching bugs. It requires evaluating whether a PR's direction is beneficial, determining if the PR is a good idea overall.

In essence, reviewing involves decision-making. Shotgun PRs to reviewers impose a heavy mental burden on them. Many authors of LLM-generated PRs genuinely believe they are helping, but from our perspective, the code is merely the smallest and sometimes the least important aspect of the change. What we value more is the author's understanding of the code, their plans for future modifications, and their ability to envision what the code should look like.

The code itself cannot contribute to any of these aspects. We often receive individuals who respond to review comments by copying the comments into their LLM, then pasting the LLM's response back onto GitHub. In essence, this is a wasteful use of everyone's time. If we sought an LLM's opinion, we could have asked it directly. We desire to hear your thoughts, not a machine's.

Furthermore, this behavior breaches trust between the reviewer and the author. When we review, we assume we are communicating with a real person who intends to deliver their best work. Copying LLM text creates doubt: does the author genuinely care? Is there a human involved at all? Prior to this policy, we had a "wild west" approach to moderation, with dozens of LLM PRs lacking disclosure rules, individuals attempting to introduce risky MIR optimizations as their first PR, and some reviewers posting "Verification: git diff --check" in their PR descriptions as if it served a purpose.

While we had a way to point moderators at problematic PRs, our enforcement was inconsistent and our rules were not publicly available. In practice, the rule was "anything goes, as long as it's not obviously horrible." Compared to the previous situation, the new policy is both stricter and clearer. Regardless of your views on whether LLMs are beneficial, detrimental, or something in between, they can no longer be ignored.

Our options are not to have no policy or to have a policy; our choice is to have a policy that is publicly documented and enforced. While one might question the necessity of an LLM policy or advocate for allowing any use of LLMs deemed pro-social, Rust's governance doesn't function in this manner. We don't have a single leader who can decree "No LLM-generated content, whether it be code or prose." or "AI is a tool, just like other tools we use."

Rust operates through consensus. According to the policy: There is no consensus within the Rust project—and likely never will be—regarding when/how/where it is acceptable to use AI-based tools. While many members of the Rust project and community see value in AI, others believe its negative societal and environmental impacts are severe enough to prohibit any use.

Some are still exploring their stance. Despite these differing views, there are shared values among us: building a community of experts in our collective projects.