Rust LLM Policy: Use AI to Review, Not to Create

The new Rust LLM policy is the most useful AI rulebook in open source right now, and the reason it works is a single verb. On 5 August 2026, five teams in the Rust project adopted an LLM policy for rust-lang/rust. It doesn’t ban AI. It doesn’t wave it through either. It draws the line at creation.

That single distinction does more work than any of the thousand-word “AI usage guidelines” I’ve read this year. It’s the first policy I’ve seen that correctly identifies what LLMs actually broke in open source — and it isn’t code quality.

TL;DR

The Rust LLM policy allows analysis, bans creation. Ask, review, distill, check — yes. Publish machine-written code or prose under your name — no, not without disclosure and pre-arrangement.
Disclosure is scoped to public output. Private LLM use needs no disclosure at all. That’s what makes the policy enforceable instead of theatrical.
LLM-created PRs are held to a higher bar, not a lower one — tests are mandatory “regardless of how hard that is.”
The real problem is review capacity, not bad code. Rust had 1,281 open PRs at the time of writing.
Copy the three-bucket structure (allowed / banned / allowed with caveats), not Rust’s specific verdicts.

What is the Rust LLM policy?

The Rust LLM policy is a set of rules, adopted on 5 August 2026 by five teams in the Rust project, that governs how large language models may be used when contributing to rust-lang/rust. Its guiding principle is a single sentence: “It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.”

In practice that means an LLM may sit anywhere in your process except the final authorship of what you publish. You can ask it what a compiler error means, have it summarize a 200-comment issue, or point it at your own patch to look for holes — and say nothing about any of it. The moment machine-written text or code goes out under your name, it has to be labelled, and in some cases pre-arranged.

The policy is not the official stance of the whole Rust project. It applies to specific teams working in the rust-lang/rust monorepo, and it’s framed as an experiment that gathers data rather than a settled verdict.

What the policy actually says

The policy text on Rust’s forge sorts every LLM use into three buckets: Allowed, Banned, and Allowed with caveats. That structure is the whole design, and it’s why the policy survives contact with reality.

Bucket	Examples	Disclosure
Allowed	Private analysis, summarizing an issue for yourself, reviewing your own code before posting, generating a solution you then rewrite	None required
Allowed with caveats	Machine translation, LLM-assisted bug discovery, LLM-created code changes under the review experiment	Mandatory — “All uses under ‘Allowed with caveats’ must disclose that an LLM was used”
Banned	LLM-created comments, documentation, or diagnostics posted publicly under a personal account	N/A

Three details separate this from the usual corporate AI memo.

Disclosure attaches to publication, not to usage

You can run an entire debugging session through an LLM and say nothing, as long as what you post is yours. The rule is blunt: “You must disclose LLM-generated content. You can choose to not post LLM content, or you can choose to post it and disclose its origin. You may not hide LLM involvement.”

A policy that tried to police private tool use would be unenforceable and everyone would know it. This one only polices the artifact — which is the only part anyone can actually observe.

There’s an explicit experiment lane

The policy carves out a section for “LLM-created Code Changes Intended for Review” with real conditions attached. The change must be non-critical — “extremely unlikely to cause soundness regression,” with the trait system, MIR building, and the query system called out as probably not acceptable. It must also be well-tested, meaning all edge cases covered.

Rust-lang organization members can override the non-critical requirement, and the policy ”strongly discourage[s]” using that provision. This is how you gather evidence about what LLM contributions actually look like instead of guessing from the sidelines.

The standard goes up, not down

The policy is explicit: “LLM-created PRs will be held to a higher standard than human-created PRs, because LLMs make it easier to write tests.” The announcement puts it more bluntly — “LLM PRs are required to have tests, full stop, regardless of how hard that is.”

💡 Key insight: If the machine made authoring cheap, the machine can pay for verification. A tool that halves the cost of writing a patch has no claim to also halve the cost of proving it works.

Why it matters: the bottleneck was never code quality

Here’s the framing most AI policies get wrong. They’re written as if the danger is bad code slipping through. That’s a review problem, and review has caught bad code since before any of us were born.

The actual damage is arithmetic. From the announcement: “At the time of writing, there are 1,281 open PRs to rust-lang/rust. This represents a staggering amount of time invested by both authors and reviewers.”

LLMs changed the ratio between the two sides of that sentence. Writing a plausible patch went from hours to minutes. Reviewing one did not get faster at all — arguably it got slower, because the old heuristics stopped working.

A polished PR with a clean description and consistent style used to be evidence that someone understood the problem. Now it’s evidence of nothing. Reviewers lost a free signal they’d been leaning on for twenty years, and nobody handed them a replacement.

That’s the same dynamic behind fake CVE reports flooding open source security inboxes: the submission cost collapsed, the triage cost didn’t, and maintainers absorbed the difference. Rust is protecting reviewer attention, which is the project’s actual scarce resource.

The enforcement design follows from this. “It’s not your job to play detective.” Accusing someone of LLM use based on writing style is prohibited. Minor violations get a nudge to comply; major ones get the PR closed — “You are allowed to close PRs that don’t follow the policy, no questions asked.” The policy deliberately leaves some violations unenforceable, because a rule that demands forensic effort from reviewers is itself a tax on the thing it’s trying to protect.

Rust vs Zig: two coherent answers

Rust isn’t the only project drawing a line, and the contrast is instructive.

	Rust	Zig
Line drawn at	Creation — output published under your name	Contact — any LLM involvement
Bug-finding with an LLM	Allowed with disclosure	Prohibited
Reviewing your own code with an LLM	Allowed, no disclosure	Prohibited
Paraphrasing LLM output	Disclose it	Prohibited
Enforcement posture	Nudge, then close the PR	Removal from project spaces

Zig’s strict no-LLM, no-AI policy bans LLM-generated code and prose, paraphrased LLM content, and using AI for editing, translation, brainstorming, or bug-finding. It’s a cultural statement as much as a process rule, and it’s genuinely simpler to apply: there is no judgment call anywhere in it.

Both are defensible. But they optimize for different things, and you should know which you’re picking. Zig’s version is cheap to enforce and expensive to comply with. Rust’s is the reverse — it costs reviewers some judgment and buys contributors a tool they’d use anyway.

The blanket ban’s real weakness is that it makes honest contributors choose between the rule and their workflow, and the ones who quietly ignore it are indistinguishable from the ones who comply. Rust’s version at least generates data about what people are actually doing.

Common mistakes when writing your own AI policy

Most of what gets published as an “AI contribution policy” fails on one of these.

Policing input instead of output. “Do not use AI tools” is unverifiable and everyone knows it, so it decays into a rule that only honest people follow. Govern what gets published under someone’s name.
Lowering the bar for AI-assisted work. The instinct is to be lenient because “it’s just a small AI-generated fix.” Backwards. Rust’s higher standard is the correct default — the tool that made writing cheap should fund the tests.
One bucket instead of three. A binary allowed/banned policy forces you to mis-sort the entire middle: translation, bug discovery, private drafting. Rust’s “allowed with caveats” bucket is where most real-world usage lives.
Turning reviewers into detectives. If your enforcement depends on identifying AI-written prose by vibes, you’ve added a second unpaid job to the role you were trying to protect. Say out loud that style-based accusations are off the table.
Writing it once and freezing it. Rust framed theirs as an experiment, with a Leadership Council issue open about a dedicated LLM sub-team. The right posture is a revision date, not a verdict.

What to actually do with this

If you maintain anything with outside contributors, take the shape and re-derive the contents for your risk profile:

Write the one-sentence principle first. Rust’s create-versus-analyze line is doing 80% of the work. Yours might be different, but it must fit in a sentence a first-time contributor reads in five seconds.
Sort your real cases into three buckets, not two. Start from what contributors already do, not from what you wish they did.
Attach disclosure to public artifacts only. Anything else is unenforceable and corrodes trust in the rest of the policy.
Raise the test bar for disclosed AI work, explicitly, in writing.
Name what reviewers may do — close without explanation, ask for tests — so the rule reduces their load instead of adding to it.

The same principle scales down to a single team’s agent setup. If your repo already carries an AGENTS.md or CLAUDE.md, that file is where the create-versus-analyze boundary belongs in machine-readable form — see how to write a CLAUDE.md that actually helps for what earns its place there. And if you’re pushing agents toward writing production code rather than reviewing it, the honest reckoning with what that costs is in the vibe-to-live gap and in spec-driven development for AI agents.

The take

Every AI policy that starts from “is this code good?” is solving last decade’s problem. Code review already answers that. What LLMs broke is the economics underneath review — the assumption that effort spent writing correlates with effort worth spending reading.

The Rust LLM policy is the first one I’ve seen that names that directly and prices it in: disclose what the machine made, hold it to a higher bar, and let humans keep the judgment. Not because AI writes bad code. Because reviewer attention is the scarcest resource in open source, and nothing about a language model made more of it.

Copy the structure. Argue about the buckets. But start from the verb.

FAQ

What is the Rust LLM policy? It’s a set of rules adopted on 5 August 2026 by five teams in the Rust project governing how large language models may be used when contributing to rust-lang/rust. The guiding principle is that LLMs may answer questions, analyze, distill, refine, check, suggest, and review — but not create. Anything published under your name that an LLM wrote must be disclosed as such.

Does Rust ban AI-generated code entirely? No. Rust bans LLM-created content posted publicly without disclosure and pre-arrangement, but it runs an explicit experiment channel for LLM-created code changes intended for review. Those PRs must be disclosed, must be non-critical to soundness, and must ship tests regardless of how hard the tests are to write.

How is the Rust LLM policy different from Zig’s? Zig’s code of conduct has a strict no-LLM, no-AI policy covering code and prose, including paraphrased LLM output, editing, translation, and brainstorming. Rust draws the line at creation instead of at contact, so a Rust contributor can legitimately use an LLM to find a bug or review their own patch privately, with no disclosure required. Zig’s rule is cheaper to enforce; Rust’s is cheaper to comply with.

Why does LLM-generated code get held to a higher standard? Because the cost asymmetry is real: generating a patch got dramatically cheaper while reviewing one did not. Rust’s policy states LLM-created PRs are held to a higher standard than human-created PRs precisely because LLMs make it easier to write the tests that prove the patch is correct. If the machine made authoring cheap, it can pay for the verification.

Do I have to disclose using an LLM on a Rust contribution? Only for public output. Private use — asking questions, summarizing an issue, reviewing your own code before you post it, or generating a solution you then rewrite yourself — needs no disclosure. Every use in the “allowed with caveats” bucket must disclose that an LLM was involved, and hiding LLM involvement is itself a violation.

Should my project copy the Rust LLM policy? Copy the structure, not the verdicts. The valuable parts are the create-versus-analyze line, the disclosure-on-public-output rule, and the explicit allowed/banned/allowed-with-caveats buckets. Your project’s risk profile determines which items land in which bucket — a soundness-critical compiler and a docs site should not draw the same lines.

Sources

Rust Blog (Inside Rust), “rust-lang/rust is adopting an LLM policy” by Jynn Nelson, 5 August 2026 — the announcement, the guiding principle, the 1,281 open PRs figure, and the reviewer-authority quotes.
Rust Forge, LLM Usage Policy — the normative text: the allowed / banned / allowed-with-caveats buckets, disclosure requirements, the review experiment, and the moderation appendix.
Zig Software Foundation, Code of Conduct — Strict No LLM / No AI policy — the contrasting blanket-ban approach used in the comparison table.

Written for umesh-malik.com — no-fluff technical writing on AI, Web Dev, and Engineering.