--- title: "rust-lang/rust is adopting an LLM policy" url: https://daily.dev/posts/rust-lang-rust-is-adopting-an-llm-policy-uzuah8jmp source_url: https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy type: article source: "Inside Rust Blog" published: 2026-08-05T05:57:53.649Z updated: 2026-08-06T10:43:05.518Z tags: ["open-source", "llm", "rust", "code-review"] reading_time: 12 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # rust-lang/rust is adopting an LLM policy **[Inside Rust Blog](https://daily.dev/sources/insiderustblog)** · 12 min read · 0 upvotes · 0 comments ## Summary Five teams in the Rust project have adopted a formal policy governing LLM usage when contributing to the rust-lang/rust monorepo. The policy was created to address three growing problems: polished LLM-generated PRs no longer signal genuine effort or understanding, LLMs exacerbate the existing review bandwidth shortage by making code easier to produce, and mechanical copy-pasting of LLM responses wastes reviewer time. The policy's core principle is that LLMs are fine for answering questions, analyzing, refining, and reviewing, but not for creating code. LLM-generated code changes are held to a higher bar than human-authored ones, requiring mandatory tests, disclosure, and prohibiting soundness-critical changes unless the author is already a domain expert. Disclosure is required for all public LLM-generated content, harassment of LLM users is prohibited, and reviewers may close non-compliant PRs without explanation. The policy is intentionally scoped to the rust-lang/rust monorepo and is designed to be revisable as the project gathers data on LLM contributions. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 96 comments across lobsters, hackernews (as of 2026-08-06). **TL;DR:** The community broadly respects the policy's thoughtfulness — especially the explicit anti-harassment rule for LLM users — while debating enforceability, the create/refine distinction, and whether disclosure requirements will invite gatekeeping of new contributors. **Sentiment:** 45% positive · 35% mixed · 20% skeptical **The case for** - The explicit rule prohibiting harassment of LLM users was widely praised as unusually fair and not seen in comparable policies. - The policy's core distinction — LLMs fine for analysis/refinement, not for creation — was seen as a clear, principled bright line. - Keeping the policy revisable and framing LLM code PRs as an experiment was appreciated as intellectually honest. - The anti-detective clause ('you are not required to actively look for LLM involvement') was welcomed as a practical safeguard against witch-hunting. - The policy's reasoning that code is the least important part of a PR — understanding and long-term ownership matter more — resonated with many reviewers. **The pushback** - Concern that disclosure requirements will enable false accusations and gatekeeping of new contributors who have no community connections to defend themselves. - The create/refine distinction is philosophically fuzzy — analysis, distillation, and suggestion are themselves acts of creation. - Enforceability is questionable since a careful contributor can strip obvious LLM markers, making the policy more about culture than detection. - New contributors face a catch-22: they need to contact a reviewer before submitting LLM-generated code, but they have no existing relationships to leverage. - Some feel the policy conflates low-quality contributions with LLM use, when the real problem is review bandwidth regardless of authorship tool. **Hottest debate:** Whether mandatory disclosure will protect or harm new contributors who lack community standing to contest false accusations of LLM use. **Open questions** - How will moderators practically distinguish LLM-generated code from human code written by someone who simply writes in a polished style? - What is the concrete onboarding path for a new contributor who wants to use LLM-generated code but knows no reviewers to pre-arrange it with? - Will the anti-harassment rule be consistently enforced, or will social stigma around LLM use persist regardless of policy? - Does banning LLM code creation put the Rust project at a long-term disadvantage as AI-assisted development becomes the industry norm? **Highlights** > yes. there's a reason there's exactly two things in the policy that are marked as moderation consequences and they're directly next to each other. "no harassment" doesn't work if people are paranoid that any PR could be LLM slop, and "disclosure is required" doesn't work if people are worried about harassment. you need both, and you need them to go into force at the same time. > — [jynelson on hackernews · 1 comments](https://news.ycombinator.com/item?id=49180364) > The exact rules on LLM generated code submission live here: https://forge.rust-lang.org/policies/llm-usage.html https://rustc-dev-guide.rust-lang.org/llm-guidance/writing.h... > Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure. They clearly put a lot of thought into this and it shows. Huge respect. > New contributors cannot create a PR using an LLM unless they first talk with a reviewer. New contributors do not have community connections. I don't know any rust-lang/rust reviewer. What is the correct procedure for this? > Harassment is not allowed. > You may not harass people for using an LLM, regardless of whether or not their use is banned by the policy. Refreshing take. Not a fan of heavy handed moderation, but I'm still very happy to see that they have this stance given the racism-tier insults I've gotten on forums without it. I especially like this rule: > Don’t try to be the police for whether someone has used an LLM. You are not required to “actively look” for whether an LLM was involved. > — [matheusmoreira on hackernews · 3 comments](https://news.ycombinator.com/item?id=49179783) > I'm not upset because LLM disclosure is mandatory. I'm upset about the consequences this has and how easy this makes for people to gatekeep new IC's under false and difficult to prove pretenses. "This looks like AI, closed". And you as a new IC with no connections, no community visibility have no recourse to fight back against it. Anti-ai people love boasting about humans > systems and forget about those humans will be surely (even if it's a low number) be negatively affected by this. If you are a new programmer who is just learning and spend time creating a PR for a project you have a lot of respect for and the first interaction is someone falsely accuses you of using LLM's then closes your PR you've now removed someone who could have genuinely grown into your community from ever joining. Not only that but since now you are by default a suspect of having used an LLM (and you need to prove you didn't use one) why even bother not using one? You are going to get accused of it either way. > — [weli on hackernews · 1 comments](https://news.ycombinator.com/item?id=49180952) > > the code itself is the smallest and in some ways least important part of the change. 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. The code itself cannot help with any of those. This struck me so hard I just wrote a post to my team about it. Yesterday I reviewed an LLM-generated PR from a teammate that did identify and fix the source of a bug, but did so in a ridiculous way that resembled a Rube Goldberg device. I don’t know whether the co-worker reviewed the change at all before creating the PR. > — [snej on lobsters · 1 points](https://lobste.rs/s/czvkjy/rust_lang_rust_is_adopting_llm_policy#c_jmmye6) > Please put summaries/TL;DR on comms like these. I don't really care if it was written by a clanker or not. I want to know how am I expected to behave without needing to sieve through pages and pages of text like I'm dealing with a government. IMO. In generally every formal-ish communication should follow a progressive disclosure style, where it starts with a most concise summary, then progressively gets into more and more details that people can read on a per-need/interest basis. > Rust’s new LLM policy says: > > * **Private use is fine:** understanding code, brainstorming, summarizing, and reviewing your own work. > * **Public LLM-written prose is generally banned:** issue text, PR descriptions, comments, docs, diagnostics, and substantive code comments. > * **LLM-assisted reviews and bug discovery are allowed with disclosure**, but humans must verify findings and make decisions. > * **LLM-generated code PRs are allowed only by prior agreement**, with disclosure, strong tests, human understanding, and usually only for non-critical code. > * Contributors must disclose relevant LLM use, but reviewers should not publicly accuse people based only on writing style. > > The goal is to protect reviewer time, accountability, and genuine technical understanding. Seems reasonable to me. > — [dpc\_pw on lobsters · 1 points](https://lobste.rs/s/czvkjy/rust_lang_rust_is_adopting_llm_policy#c_hyr2v2) **Source threads** - [lobsters](https://lobste.rs/s/czvkjy/rust_lang_rust_is_adopting_llm_policy) · 104 points · 24 comments - [hackernews](https://news.ycombinator.com/item?id=49179039) · 61 points · 72 comments ## Similar posts on daily.dev - [Add an LLM policy for rust-lang/rust](https://daily.dev/posts/add-an-llm-policy-for-rust-lang-rust-j1gmauu6f) · Drew DeVault · 0 upvotes · 0 comments --- Tags: [#open-source](https://daily.dev/tags/open-source), [#llm](https://daily.dev/tags/llm), [#rust](https://daily.dev/tags/rust), [#code-review](https://daily.dev/tags/code-review) [View this post on daily.dev](https://daily.dev/posts/rust-lang-rust-is-adopting-an-llm-policy-uzuah8jmp)