rust-lang/rust is adopting an LLM policy | Inside Rust Blog
Aug. 5, 2026 · Jynn Nelson
Recently, five teams in the Rust project adopted a policy that I originally authored,<br>governing how Large Language Models can be used when contributing to the rust-lang/rust monorepo.<br>Notably, the new policy is not an official stance on LLMs, and does not apply everywhere in the Rust project.<br>I wrote it for a very specific purpose, described below.
This post talks about why we created that policy, what it says, and how this will affect contributors.
The policy affects the following groups of people:
People who review or moderate PRs on rust-lang/rust.
People who author PRs with LLM-generated code on rust-lang/rust.
People who discover issues using LLMs and post them on rust-lang/rust.
People who write issues or comments that directly quote an LLM on rust-lang/rust.
If you are not in one of those groups, you don't have to change anything about how you work.
Why was this policy created?
While the Rust project is a collection of technical artifacts,<br>it is also a community of people who work together to build, maintain, and extend those artifacts.<br>When we talk about "contributing to the Rust project", we partly mean work on those artifacts,<br>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.<br>Some of those uses respected our community:<br>translating messages to English so people could draft them in their native language;<br>finding poor diagnostics for code snippets that new contributors to Rust might write;<br>analyzing RFCs to see if they were missing a discussion of other parts of the language that could affect the design.<br>Some of those uses, sometimes unintentionally, did not.
I've seen LLMs causing three main issues for our community:
Polished technical products no longer indicate effort and understanding.
Making code easier to write exacerbates our existing issues with review bandwidth.
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.<br>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,<br>and so that existing reviewers can easily point to the rules as an actionable reason when closing PRs that don't follow them.
Technical products no longer indicate effort
It used to be that if an open source project got a polished, well-tested, detailed PR,<br>that indicated that there was someone on the other end who had put time, effort, and understanding into the PR.<br>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.<br>Polished PRs no longer indicate effort;<br>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;<br>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.
Making code easier to write causes review issues
At the time of writing, there are 1,281 open PRs to rust-lang/rust.<br>This represents a staggering amount of time invested by both authors and reviewers.<br>We have long had the problem that there are more people who want to write code than people willing to review it.<br>With the advent of LLMs, this problem only gets worse.
Most of the work of reviewing is not simply catching bugs.<br>A great deal of it is deciding whether this direction is a good approach, whether the PR is a good idea at all.<br>In other words, reviewing is made of decisions.
"Shotgunning" PRs at reviewers incurs a high mental cost for them.<br>I think most authors of LLM PRs believe that they are sincerely helping, but from our perspective,<br>the code itself is the smallest and in some ways least important part of the change.<br>We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like.<br>The code itself cannot help with any of those.
Mechanically copy-pasting LLM output is a waste of time
We will often get people who respond to review comments by copy-pasting them into their LLM, then copy-pasting its response back onto...