The takeaway first: asking AI is fine — letting AI create is not

If you use AI tools while writing Rust, this one is worth five minutes.

On August 5, 2026, Rust’s official Inside Rust blog published Jynn Nelson’s post “rust-lang/rust is adopting an LLM policy”: five teams — compiler, libs, types, rustdoc, and bootstrap — have formally adopted an LLM usage policy covering everyone who files PRs, opens issues, or posts comments on the rust-lang/rust monorepo.

The whole policy compresses into one sentence, verbatim:

It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

“Create”-category uses are heavily restricted inside an “experiment clause” gated by five conditions. How strict? The two most concrete rules:

  • LLM-created PRs must ship tests, full stop. The policy text: if the area you’re changing has no existing test suite, you either write one or close the PR — “writing the tests seems hard” is not an accepted excuse.
  • A 50% circuit breaker: if more than half of PRs merged in any 6-week window are LLM-created, new LLM PRs stop being merged until the share falls back below 50%, with a minimum 10-day cooldown.

The post drew 120+ points and 70+ comments on Hacker News. Below is the full policy breakdown, plus what the community is arguing about.

quote-card

Why now: a review crisis behind 1,281 open PRs

Nelson’s post is unusually candid about motivation, and each of the three reasons deserves attention from anyone maintaining open source.

First, a polished PR no longer signals anything. A well-crafted PR used to prove someone on the other end had invested time, effort, and understanding — Rust’s review culture is built on that signal: maintainers are reluctant to close PRs because they represent hard work, and PRs are treated as a sign the author wants to join the community long-term. LLMs broke all of these: polish no longer implies effort or understanding — and with autonomous agents, there may be no one on the other end at all.

Second, review bandwidth was already short, and AI made code cheaper to produce. The number given in the post: 1,281 open PRs on rust-lang/rust at time of writing. Most of reviewing is not catching bugs — it is making decisions: is this direction right, should this PR exist at all. Code can be delegated to an LLM; those decisions cannot. In the author’s words, from a maintainer’s perspective “the code itself is the smallest and in some ways least important part of the change.”

Third, mechanical copy-pasting wastes everyone’s time. People paste review comments into their LLM and paste the response back onto GitHub. The post is blunt:

Bluntly: this is a waste of everyone’s time. If we wanted an LLM’s opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine’s.

Before the policy, rust-lang/rust was a “wild west”: dozens of LLM-related PRs, no disclosure rules, people adding risky MIR optimizations as their very first PR, and PRs claiming “Verification: git diff –check” as if that did anything. The rules existed only as internal moderator notes — new contributors had no idea why their PRs were closed. So the choice was never “policy or no policy”; it was “unwritten moderation notes or public rules.”

The rules: what’s allowed, banned, and disclosure-gated

The full policy lives on Rust Forge as the “LLM Usage Policy,” organized into ✅ / ❌ / ⚠️ tiers. Here is each tier unpacked.

The three tiers of Rust’s LLM policy: allowed, disclose, banned

✅ Allowed (as long as the output is seen only by you):

  • Asking an LLM questions about the codebase; asking it to summarize issue or PR comments for yourself (reposting the summary publicly is not allowed)
  • Having an LLM privately review your code or prose
  • Writing dev-tools for personal use with an LLM
  • Generating possible solutions with an LLM, learning from them, then writing from scratch in your own style
  • Clearly experimental PRs (crater or perf runs marked with S-experimental labels, [PERF] titles, r? ghost) — disclosure recommended but not required; the moment the experimental marker comes off, disclosure becomes mandatory

❌ Banned outright:

  • Posting LLM-created comments from a personal account — this covers issue bodies, PR descriptions, and even voice/video scripts. Clearly quoted and marked LLM content may appear, but the comment must “stand on its own” without it
  • LLM-created documentation — including doc comments, safety comments, multi-paragraph non-doc comments, and compiler diagnostics (an LLM may assist the logic around a diagnostic, but must not write the message itself)
  • Processes written so that an LLM is required to execute them — e.g., documenting test locations only in an AGENTS.md. Documentation must be authored for humans first; the machine-facing version may only summarize it
  • Treating an LLM review as a sufficient condition to merge or reject a change — LLM reviews must be advisory-only, and they never substitute for the author’s own self-review

⚠️ Conditionally allowed (all require disclosure of LLM use):

  • Machine translation: posting only the translation without your original text is “allowed but discouraged” — it can introduce new miscommunication; posting both the original and the translation is always fine, with disclosure
  • “Trivial” changes: typos, Markdown links, synonym swaps, type signatures for a trait impl — changes with essentially no other way to be written
  • LLM-discovered bugs: allowed if you personally verify the bug, following the fuzzer reporting guidelines
  • Review bots: one-time maintainer approval, a separate GitHub account clearly marked as an LLM, blockable via standard user-blocking, and LLM comments must not block a PR — a human reviewer must explicitly endorse a bot comment before it gates merging

Want LLM-created code merged? Five gates first

This is the policy’s core “experiment clause” (Experiment: LLM-created code changes). All five conditions are mandatory, with disclosure throughout:

  1. Pre-arranged: a reviewer must have communicated ahead of time that they are willing to review the LLM-created PR. New contributors must talk with the reviewer who will be assigned before opening such a PR. The suggested path is pushing to your fork and posting a link on Zulip to find a reviewer, rather than opening the PR cold.
  2. Non-critical: extremely unlikely to cause a soundness regression. Internal tooling (tidy, x setup, linkchecker) is probably fine; the trait system, MIR building, or the query system is probably not. rust-lang organization members are exempt from this clause, but the policy “strongly discourages” using that exemption — LLMs are very good at plausible-looking code, and soundness is hard to test.
  3. High-quality: held to at least the same standard as human-authored changes. The text names it directly: no “vibe-coded” PRs that degrade the codebase.
  4. Well-tested: LLM-created PRs are held to a higher testing bar than human PRs, because LLMs make tests easier to write. No existing test suite means you write one or close the PR. No exceptions.
  5. Well-reviewed: both author and reviewer commit to fully understanding the code. A project member’s review does not substitute for self-review — authors re-review their own work after every change.

Procedurally, these PRs get a new ai-assisted label and are mirrored to a private Zulip channel visible to rust-lang organization members — not as another gatekeeper, but to collect data: are people doing interesting things with LLMs, are they learning, do they become repeat contributors? That data shapes the next revision.

Note the clause’s own framing: it is an experiment meant to inform future permanent policy, not the standing rule.

The 50% circuit breaker: a quantitative valve on AI contributions

The most deliberately engineered rule in the policy, worth its own section.

In any 6-week window (chosen to align with Rust’s release cycle), if more than half of merged PRs are LLM-created, merging new LLM-created PRs stops until the share falls back below 50% — with a minimum 10-day cooldown (aligned with the FCP final-comment-period process, to avoid flip-flopping between allowed and banned).

The cooldown exists to answer four questions, stated in the policy itself: How is the experiment going? Are we adopting AI sustainably? Are contributors who choose not to use LLMs being included? Does the policy need changes?

The policy also “strongly suggests” automating the breaker — inconsistent manual enforcement breeds resentment.

Rust’s 50% LLM circuit breaker: 6-week window, over half merges trips the switch, 10-day cooldown

My take (opinion, not policy): this is a rare attempt among major open source projects to put a quantitative valve on AI contributions. Most projects’ AI policies stay qualitative (allow / ban / disclose). Rust’s design implicitly admits a premise — review bandwidth is a scarce resource that must be rate-limited like traffic. Writing the cap down beats letting maintainer burnout enforce it quietly.

Scope: what this policy does not govern

Don’t be misled by the headline — the policy is narrower than it looks:

  • It applies only to the rust-lang/rust monorepo, and only to the five ratifying teams: compiler, libs, types, rustdoc, bootstrap, and their subteams
  • Teams like lang and edition are out of scope and may set their own policies
  • Other rust-lang repositories, submodules, and crates.io dependencies are unaffected

Enforcement details that matter:

  • Judged by actions, not intent. The policy admits many clauses are unenforceable — the goal is not catching every violation but, in its own words, to “remove plausible deniability”: you either follow it or intentionally violate it. Hiding LLM involvement counts as lying, which is a Code of Conduct violation
  • “Style is not evidence.” A reviewer who thinks code “looks AI-written” may not accuse the author; report suspicions privately to the moderation team. Harassing people for using LLMs is likewise a conduct violation
  • This is not the Rust project’s official stance on AI. Per the post, there is no consensus within the project — “and likely never will be.” The policy is deliberately easier to change than it was to adopt, and the leadership council is considering a dedicated LLM-policy subteam

For contrast, the Zig project is far stricter: its code of conduct carries a “Strict No LLM / No AI Policy” banning all LLM-generated content — code, prose, paraphrasing, editing, and translation. The line quoted in Rust’s post — “No LLM-generated content, whether it be code or prose” — is Zig’s own wording. Rust did not take that path because, as the post puts it, Rust has no benevolent dictator; it governs by consensus.

What the community is arguing about

The Hacker News thread is a representative snapshot.

The top-voted summary is the policy’s own one-liner (HN user andsoitis): “It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.” Most readers accept the split. User ares623’s reading: you may use the tool to help with your own tedious parts, but not to pass that tedium off to reviewers.

The dissent is loud too. User socalgal2 wrote “Sounds like the beginning of the end of rust to me,” arguing that “AI is a jet engine” — restricting creation amounts to forcing everyone onto propeller planes. Below that analogy, user happyweasel’s rebuttal resonated widely: Rust just wants to make sure “you are a capable pilot that can actually steer a plane before stealing everyone else’s attention.”

A third camp questions whether “deep understanding” is overrated: nobody fully understands a large codebase, including its original authors. Replies cited ffmpeg and a string of single-developer games as counterexamples. The argument has no winner — which is exactly why the policy labels itself an experiment.

What this means for you: a pre-flight checklist for AI-assisted PRs

The policy governs only rust-lang/rust, but it will likely be studied by many projects. If you contribute with tools like Cursor, Codex, or Copilot, run this checklist:

  • ✅ Do I actually understand every line I’m submitting? When a reviewer pushes back, the one who answers should be me, not my AI
  • ✅ Are the PR description, comments, and issues written by me? AI drafting is fine — what I post must be words I edited and own
  • ✅ Did I disclose? More projects will follow Rust in asking “was this LLM-generated” right in the PR template — lying costs far more than disclosure
  • ✅ Are the tests there? Rust sets a higher testing bar for AI PRs than human ones; expect that to spread
  • ✅ For anything near a critical path, did I talk to a maintainer first?
  • ❌ Never paste review comments into an LLM and paste its reply back — it is the single most despised behavior in the entire policy

FAQ

Has Rust banned writing code with AI?

No. The policy only covers five teams on the rust-lang/rust monorepo (compiler, libs, types, rustdoc, bootstrap). Private AI use for learning, questions, summaries, and self-review is fully allowed. Landing LLM-created code requires five conditions: pre-arrangement, non-critical path, high quality, complete tests, and thorough review — plus disclosure.

What is Rust’s 50% circuit breaker?

If more than half of PRs merged in any 6-week window (aligned with the Rust release cycle) are LLM-created, merging new LLM PRs is paused until the share drops back below 50%, with a minimum 10-day cooldown. The policy suggests automating the breaker.

Will other open source projects reject my AI-assisted PRs too?

Each project differs. Rust’s policy applies only to rust-lang/rust; Zig’s code of conduct strictly bans all LLM-generated content. Safe universal practice: disclose AI involvement, understand every line you submit, write your own PR descriptions and comments, and never paste raw AI replies into discussions.

Sources

All policy claims in this article are anchored to the official texts; reading them side by side is recommended:

If Rust interests you, these pieces are worth your time:

About 全栈之巅-梦兽编程 (Rexai Programming): in-depth content on AI coding and full-stack technology. Follow our WeChat official account「梦兽编程」for more Rust and AI programming tutorials.