Rust-lang/rust is adopting an LLM policy

Inside Rust Blog Rust Install Learn Tools Governance Community 🖌 Light Dark System rust-lang/rust is adopting an LLM policy Aug. 5, 2026 · Jynn Nelson Recently, five teams in the Rust project adopted a policy that I originally authored, governing how Large Language Models can be used when contributing to the rust-lang/rust monorepo. Notably, the new policy is not an official stance on LLMs, and does not apply everywhere in the Rust project. 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, 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: 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. 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. Technical products no longer indicate effort 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