{"slug": "rust-s-llm-policy-bans-creation-not-assistance", "title": "Rust's LLM Policy Bans Creation, Not Assistance", "summary": "Five teams maintaining the Rust compiler and standard library — compiler, libs, types, rustdoc, and bootstrap — adopted a formal LLM policy for the rust-lang/rust repository that permits using LLMs for assistance but bans their use for creating content, citing the need to protect reviewer trust rather than copyright. The policy, which took nearly four months to finalize and generated over 3,000 Zulip messages, explicitly rules copyright out of scope and targets the social signal that polished pull requests once conveyed, which LLMs have broken. The policy includes tiers: private use is unrestricted, disclosure is required for visible output, and hard bans cover comments, issue bodies, PR descriptions, documentation, and compiler diagnostics, with an escape hatch for pre-arranged, high-quality code outside soundness-critical areas.", "body_md": "[AI](https://sourcefeed.dev/c/ai)Article\n\n# Rust's LLM Policy Bans Creation, Not Assistance\n\nThe new rust-lang/rust rules protect reviewer trust rather than copyright, and they read like a template other projects will fork.\n\n[Priya Nair](https://sourcefeed.dev/u/priya_nair)\n\nFive of the teams that maintain the Rust compiler and standard library — compiler, libs, types, rustdoc, and bootstrap — have [adopted a formal LLM policy](https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/) for the `rust-lang/rust`\n\nrepository. The core rule fits in a sentence: it's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, and review. But not to create.\n\nThat sentence took nearly four months to land. Jynn Nelson opened [the policy PR](https://github.com/rust-lang/rust-forge/pull/1040) against rust-forge in mid-April; by late May the debate had generated over 3,000 Zulip messages, and the text merged only after a formal sign-off across all five teams. It was contested to the end — Niko Matsakis, one of Rust's most senior language designers, argued the draft was \"worse than no policy\" because of what it signals to a generation of contributors who treat LLMs as standard equipment. That it shipped anyway tells you how much strain Rust's review queues are under.\n\n## A different reason to say no\n\nRust isn't the first major project to restrict AI-generated contributions, but it's the first big one to do it for this reason — and the reason matters more than the rule.\n\nGentoo banned AI-generated code in April 2024, NetBSD followed weeks later, and [QEMU](https://www.qemu.org/) declines AI-generated patches outright. Those are provenance arguments: nobody can honestly certify the origin of model output under a Developer Certificate of Origin, so the legally safe move is refusal. At the other pole, LLVM, Mesa, Firefox, and the Linux kernel have converged on disclose-and-stay-accountable permissiveness.\n\nRust's policy makes neither argument — it explicitly rules copyright out of scope. The problem it targets is social. A polished pull request used to be a costly signal: proof that someone understood the problem and invested effort, which told reviewers where to spend scarce attention. LLMs broke that signal without breaking the artifact. The PR still looks polished; it just no longer means anything. And in a project where review bandwidth — not code production — is the binding constraint, a tool that makes plausible code free is an attack on the economics of maintenance, whatever its copyright status. [curl](https://curl.se/) learned the same lesson through its bug bounty, which drowned in AI-generated \"slop\" reports until Daniel Stenberg started publicly banning submitters.\n\nThat's why the policy's slogan is \"write better, not faster.\" Faster is precisely the failure mode.\n\n## Where the line actually sits\n\nThe tiers are more pragmatic than the headlines suggest. Private use is untouched and undisclosed: ask a model to explain the query system, summarize a 200-comment tracking issue, review your own diff before you push — nobody cares, because nobody else has to read the output. Studying an LLM's solution and then writing your own from scratch is likewise fine.\n\nDisclosure kicks in when output becomes visible: machine-translating your own words, trivial mechanical fixes, bugs an LLM found (after you've verified them yourself), and advisory review bots running on separate, blockable accounts.\n\nThe hard bans cover anything a maintainer must read as if a human meant it: comments, issue bodies, PR descriptions, documentation including doc comments and safety comments, and compiler diagnostics. Notably, an LLM review can never count toward a merge decision.\n\nThen there's the escape hatch, framed as an explicit experiment: LLM-generated code may land if it's pre-arranged with a reviewer, avoids soundness-critical territory (the trait system, MIR building, the query system), and is high-quality, well-tested, and fully understood by both author and reviewer. Such PRs get an `ai-assisted`\n\nlabel. Internal tooling like `tidy`\n\nis the designated sandbox. And there's a genuinely novel mechanism: if LLM-created PRs ever exceed half of merges over a six-week window, a circuit breaker halts new ones for at least ten days. Nobody else's AI policy has a rate limiter.\n\n## Policy engineered like code\n\nThe scope is deliberately narrow — one repository, excluding submodules, subtrees, and the rest of the rust-lang org — and the text anticipates its own revision. The leadership council is weighing a standing LLM committee, and a [project-wide policy RFC](https://github.com/rust-lang/rfcs/pull/3959) is already open. Enforcement is aimed at actions, not tools: reviewers can bounce non-compliant PRs, lying about LLM use is a Code of Conduct matter, and — the underrated clause — so is harassing people you *suspect* of using one. Anyone who's watched an \"this reads like ChatGPT\" accusation spiral on an issue tracker knows why that's in there.\n\nThe obvious objection is that disclosure regimes can't catch a disciplined liar, and the policy essentially concedes it. That's the right trade. A rule you can't perfectly enforce still coordinates the honest majority, and the CoC hook handles the rest. The weaker point is friction: pre-arranging LLM-assisted work punishes exactly the good-faith newcomers Rust already struggles to onboard, while the drive-by sloppers were never reading CONTRIBUTING.md in the first place.\n\n## What to take from it\n\nIf you contribute to `rust-lang/rust`\n\n, the practical change is small unless you were pasting model output into public view: keep the assistant for comprehension and self-review, write your own prose, and if you want LLM-written code merged, ask the reviewer before you open the PR and stay out of compiler internals.\n\nIf you maintain anything else, this is the document to fork. The assist-versus-create line is a sturdier primitive than tool bans, which age badly and can't be checked, or blanket disclosure, which just shifts cost onto reviewers. The circuit breaker converts an irreversible political fight into a reversible experiment. The anti-witch-hunt clause pre-empts your next moderation crisis.\n\nMost projects' AI policies to date have been position statements — legal hedges or vibes. This one is instrumented: labeled inputs, a rollback lever, a designated amendment path, an owner. Whether or not you agree with where Rust drew the line, it's the first LLM policy designed the way engineers design systems, and that — more than the restriction itself — is what other projects are going to copy.\n\n## Sources & further reading\n\n-\n[rust-lang/rust is adopting an LLM policy](https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/)— blog.rust-lang.org -\n[Add an LLM policy for rust-lang/rust](https://github.com/rust-lang/rust-forge/pull/1040)— github.com -\n[LLM Usage Policy (full policy text)](https://github.com/jyn514/rust-forge/blob/llm-policy/src/policies/llm-usage.md)— github.com -\n[Rust Moves to Restrict LLM Use in Contributions After Months of Debate](https://socket.dev/blog/rust-moves-to-restrict-llm-use-in-contributions)— socket.dev -\n[Gentoo and NetBSD ban AI code, but Debian doesn't - yet](https://www.theregister.com/2024/05/18/distros_ai_code/)— theregister.com -\n[Project-wide LLM policy RFC](https://github.com/rust-lang/rfcs/pull/3959)— github.com\n\n[Priya Nair](https://sourcefeed.dev/u/priya_nair)· AI & Developer Experience Writer\n\nPriya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to.\n\n## Discussion 0\n\nNo comments yet\n\nBe the first to weigh in.", "url": "https://wpnews.pro/news/rust-s-llm-policy-bans-creation-not-assistance", "canonical_source": "https://sourcefeed.dev/a/rusts-llm-policy-bans-creation-not-assistance", "published_at": "2026-08-05 14:10:25+00:00", "updated_at": "2026-08-05 14:42:22.445923+00:00", "lang": "en", "topics": ["ai-policy", "ai-ethics", "developer-tools"], "entities": ["Rust", "rust-lang/rust", "Jynn Nelson", "Niko Matsakis", "Gentoo", "NetBSD", "QEMU", "Daniel Stenberg"], "alternates": {"html": "https://wpnews.pro/news/rust-s-llm-policy-bans-creation-not-assistance", "markdown": "https://wpnews.pro/news/rust-s-llm-policy-bans-creation-not-assistance.md", "text": "https://wpnews.pro/news/rust-s-llm-policy-bans-creation-not-assistance.txt", "jsonld": "https://wpnews.pro/news/rust-s-llm-policy-bans-creation-not-assistance.jsonld"}}