Rust's Draft LLM Policy Draws the Right Line

A Rust Forge pull request opened on April 17, 2026 proposes an LLM usage policy for rust-lang/rust. As of May 17, 2026, the pull request remains open, with 65 issue comments and 284 review comments, so the proposal is not adopted policy yet.¹

The draft still matters now because it names the boundary most AI coding guidance avoids: LLMs can help people think, learn, check, and experiment, but they should not replace human authorship in the places where a project preserves judgment, taste, accountability, and shared understanding.²

The proposal also fits existing Rust contribution norms. The current Rust Forge contributing guide already tells contributors to build trust, respect reviewer time, submit work they fully understand, check work in detail before submitting it, and keep comments concise.³ The compiler review policy also says reviewers need sufficient understanding of the code under review and limited review time.⁴ The LLM draft makes those older expectations concrete for AI-assisted work.

TL;DR

The Rust draft allows private LLM use for learning, summarization, private review, personal tooling, and experiments.² It bans LLM-originated public comments, issue bodies, pull request descriptions, documentation, compiler diagnostics, and any process that treats an LLM review as enough to merge or reject code.² It creates a narrow experiment for LLM-created code changes: solicited, non-critical, disclosed, high-quality, well-tested, and fully understood by both author and reviewer.² My read: the policy succeeds because it optimizes for intellectual custody, not output volume.

Key Takeaways

• For maintainers: policy should protect review capacity, project voice, and accountability before it talks about productivity.
• For AI coding teams: allow private use broadly, but draw a harder line at public authorship, docs, diagnostics, and merge authority.
• For contributors: disclosure only helps when the human still owns the work. “The model wrote it” cannot become an excuse.
• For tool builders: review bots need separate identities, blockability, low false-positive pressure, and advisory status.
• For agent teams: the best rule in the draft is cultural, not technical: use AI to write better, not faster.²

The Draft Separates Thinking From Authorship

Most LLM policies collapse two different acts into one category: using AI. The Rust draft splits the act into private cognition and public authorship.

Private cognition gets broad permission. A contributor can ask an LLM questions about the codebase, summarize comments for private understanding, privately review their own code or writing, build personal developer tools, and generate possible solutions to learn from before writing their own solution.²

Public authorship gets the hard line. The draft bans comments from a personal account when an LLM originally created them. The same rule covers issue bodies and pull request descriptions.² The draft also bans documentation originally created by an LLM, including non-trivial source comments, doc comments, safety comments, multi-paragraph comments, and compiler diagnostics.²

That distinction feels right because public artifacts carry project voice. Compiler diagnostics, safety comments, and documentation do not merely move information. They teach users how Rust thinks. They also become part of the project’s long-term maintenance burden.

LLM-generated prose can sound polished while weakening that burden. A reviewer must now ask: who chose this phrasing, who understands the implication, who owns the edge case, and who will fix the confusion later? The draft refuses to let a contributor outsource that responsibility while keeping the credibility of a human account.

The Strongest Rule: No AI Review As Merge Authority

The draft bans treating an LLM review as a sufficient condition to merge or reject a change.² Review bots may exist, but the draft requires them to stay advisory. Reviewers must explicitly endorse an LLM comment before blocking a pull request, and authors still owe self-review.²

That rule avoids a tempting failure mode. Teams can add AI review and call the workflow safer, even when the new tool only creates a second stream of claims no one has time to evaluate. A bot can find real bugs. A bot can also produce trivial objections, stale style advice, hallucinated constraints, or confident comments on code it did not understand.

The Rust draft handles that problem structurally:

The point is not that LLM review has no value. The point is that review authority belongs to people and project process. A machine can assist the reviewer. It cannot become the reviewer of record.

The Code Exception Is Narrow On Purpose

The draft does not ban all LLM-created code. It creates an experiment for code changes that meet five conditions: solicited, non-critical, high-quality, well-tested, and well-reviewed.²

Each word does real work.

Solicited means the reviewer agreed ahead of time to review an LLM-created pull request. New contributors cannot use an LLM for that path unless they first talk with the same reviewer assigned to the PR.²

Non-critical keeps AI-created changes away from areas where a mistake could cause a soundness regression. The draft names internal tooling as more plausible and areas such as the trait system, MIR building, or the query system as probably not appropriate.²

High-quality means the code must meet at least the same standard as other changes. The draft explicitly rejects PRs that degrade the codebase’s quality.²

Well-tested raises the bar. LLM-created PRs face a higher test expectation because LLMs make tests easier to write. If no existing test suite covers the code, the author must write a new one or close the PR.²

Well-reviewed means both author and reviewer commit to fully understanding the code. A project member’s review does not replace self-review.²

That experiment has a useful shape. It does not pretend AI-created code cannot help. It also refuses the lazy version of “AI-assisted contribution” where the contributor generates a patch, asks maintainers to sort through it, and spends no human effort on understanding.

Better, Not Faster

The draft’s most important sentence says LLMs work best when people use them to write better, not faster.²

That sentence should become the default standard for AI coding.

Faster alone shifts work from authors to reviewers. A contributor saves an hour generating a patch, then maintainers spend three hours separating useful code from strange tests, bloated comments, vague diagnostics, and unowned design choices. The project loses even when the diff eventually compiles.

Better asks a different question: did the tool help the human form a sharper understanding? Did it find an edge case the author verified? Did it help draft a test the author understands? Did it make the final contribution easier to review, maintain, and trust?

The Rust draft makes that distinction enforceable. Private LLM use can improve the author’s understanding. Public LLM-originated authorship can degrade the project’s shared understanding. Experimental AI-created code can proceed only when solicitation, scope, quality, tests, and review all carry the extra burden.

That combination beats blanket optimism and blanket prohibition. It says the technology may help, but the project will not absorb low-custody output just because a model made it cheap.

The Moderation Section Avoids Witch Hunts

The draft also handles enforcement with unusual care. It tells contributors that they do not need to play detective about LLM use. If a violation looks clear, point to the policy. If a case looks borderline, report it to moderators and move on.²

The same section treats dishonesty about LLM use as a code-of-conduct issue, but also states that harassing contributors for using LLMs is not acceptable.² That pair matters. A policy that invites suspicion can poison a community faster than the AI-generated content it tries to stop.

Good AI policy needs two boundaries:

The draft puts responsibility on the contributor without turning every reviewer into an investigator. That protects the review culture as much as the code.

What Other Projects Should Copy

The Rust proposal deserves attention because it defines roles instead of vibes.

Use LLMs as:

• a private tutor;
• a private reviewer;
• a summarizer for your own understanding;
• a bug-discovery aid when the human verifies the bug;
• an experiment source when the reviewer opts in and the scope stays low-risk.

Do not use LLMs as:

• the public author of your comment;
• the voice of project documentation;
• the author of compiler diagnostics;
• a substitute for human review;
• an excuse for tests you did not write;
• a way to make maintainers review code you do not understand.

That list gives maintainers something better than a moral argument. It gives them an operating policy.

My Read

The draft lines up with the quality problem AI coding creates. Code gets cheaper to produce. Review attention, taste, coherence, project voice, and social trust do not get cheaper. Scarcity moves upward.

A project that optimizes for output volume will drown its maintainers in plausible diffs. A project that optimizes for custody can still use AI, but only in ways that make the human author more capable and the reviewer less burdened.

The Rust draft protects the scarce layer. It treats diagnostics, comments, documentation, and review authority as part of the project, not as interchangeable text. It treats tests and self-review as obligations, not accessories. It gives experimentation a path, but not a blank check.

That is the right direction for serious software projects. The exact rules may change before Rust adopts anything. The underlying shape should not: AI can help people do better work, but the human must still own the contribution.

FAQ

Is this Rust policy adopted?

No. As of May 17, 2026, the policy exists as an open Rust Forge pull request titled “Add an LLM policy for rust-lang/rust.” The current rust-lang/rust-forge main branch does not contain src/policies/llm-usage.md yet.¹⁵

Does the draft ban all AI use?

No. The draft conditionally allows private LLM use for learning, summarization, review, personal tooling, and idea generation. It also creates a narrow experiment for disclosed, solicited, non-critical, high-quality, well-tested, and well-reviewed LLM-created code.²

What does the draft ban?

The draft bans LLM-originated public comments, issue bodies, pull request descriptions, documentation, compiler diagnostics, and treating LLM review as enough to merge or reject code.²

Why does the draft treat documentation and diagnostics so strictly?

Documentation and diagnostics carry project voice, user guidance, and long-term maintenance obligations. The draft allows LLMs to assist surrounding logic in some cases, but it bars LLMs from creating the messages themselves.²

What should AI coding teams learn from the proposal?

Separate private assistance from public authorship. Require disclosure where AI affects other people. Keep review authority human. Raise the test and self-review bar when AI helps create code. Optimize for better work, not more output.

References