[ AI Models & Platforms
](https://www.unite.ai/series/artificial-intelligence/)
[Add Unite.AI to your preferred sources on Google](https://www.google.com/preferences/source?q=unite.ai)
Five teams in the Rust project have adopted a formal policy governing how large language models can be used when contributing to rust-lang/rust
, the project’s main monorepo, Jynn Nelson, the policy’s author, announced on the Inside Rust blog on August 5, 2026. The policy (ratified by the compiler, libs, types, rustdoc, and bootstrap teams) replaces what Nelson describes as an unpublished “wild west” approach to moderation with a public, written set of rules.
The policy is not a project-wide stance on AI, and it is careful to say so. It applies only to the rust-lang/rust
repository and only to the teams that ratified it. But within that scope, it draws a bright line: LLMs are welcome as tools for thinking, not as substitutes for it.
What the policy actually says #
The document summarizes itself in 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 produces three tiers. Allowed outright: any private use where the contributor is the only one who sees the output — asking questions about the codebase, summarizing a thread, privately reviewing one’s own code. Allowed with mandatory disclosure: machine translation, trivial changes like typo fixes, LLM-assisted bug discovery, and LLM review bots, which must run from separate, clearly labeled GitHub accounts that individual users can block. Banned: LLM-created comments, documentation, and compiler diagnostics; any process that requires an LLM to execute; and treating an LLM review as sufficient to merge or reject a change.
The sharpest teeth sit in the enforcement design. Deliberately misrepresenting LLM use counts as a violation of the project’s Code of Conduct — the same tier as harassment — carrying a warning and, for repeat violations, a ban. The document is explicit that many of its clauses are unenforceable in practice, and says that is deliberate: “Our goal is not to catch every violation… Instead, our goal is to remove plausible deniability: to force a choice between following the policy and intentionally violating it.”
A bounded experiment for LLM-written code #
LLM-authored code is not banned outright. It is confined to an experiment with strict entry conditions: changes must be pre-arranged with a named reviewer, non-critical to the compiler’s soundness, well-tested, and well-reviewed, with disclosure required in every case. New contributors cannot open an LLM-created pull request without first securing a reviewer. Where no test suite exists for the touched code, the author must write one or close the PR. No exceptions.
The experiment carries its own circuit breaker. If more than half of the PRs merged in a six-week window are LLM-created, merges of LLM-created PRs stop until the share falls back below 50 percent, with a minimum cooldown of ten days. The window aligns with Rust’s six-week release cycle. All such PRs carry a new ai-assisted
label and are posted to a private Zulip channel whose purpose is data collection (whether LLM-assisted contributors are learning, returning, and producing useful work), not gatekeeping.
Why now #
Nelson’s announcement describes three pressures that pushed the teams from informal moderation to written rules. Polished pull requests no longer signal effort or understanding, which corrodes the trust signals the project’s review culture runs on. Cheaper code generation worsens an existing review-bandwidth shortage: the repo currently carries 1,281 open PRs, and the scarce resource was always reviewer judgment, not code. And contributors who respond to review comments by pasting them into an LLM and pasting the output back are, in Nelson’s words, wasting everyone’s time, and breaking the assumption that a reviewer is talking to a person.
The backdrop is a genuine split inside the project. The policy’s own motivation section states there is no consensus within Rust, “and likely never will be,” about when AI-based tools are acceptable, with members ranging from daily users to those who consider any use unacceptable. That is why the document is built to be changed: major revisions require sign-off from each ratifying team, and the policy can be dissolved entirely by those teams or overridden by a project-wide LLM committee the leadership council is now considering.
The fine print #
Scope is narrower than the headline suggests. The policy does not cover other repositories in the rust-lang organization, language-team work such as tracking issues and stabilization reports, the style guide, or teams that have not ratified it. Each remains free to set its own rules. Members of the rust-lang organization are exempt from the “non-critical” restriction on LLM-created code, though the policy says it strongly discourages using that exemption, and PRs written before the policy took effect are exempt as well. Harassing a contributor for using an LLM is itself prohibited, regardless of whether the use violated the policy.
What happens next #
The private Zulip channel begins collecting data on LLM-created PRs as soon as the ai-assisted
label is in use, and the first six-week circuit-breaker window will tell the teams whether the experiment is overwhelming the merge queue. The leadership council’s pending proposal for a dedicated LLM committee would, if formed, take precedence over this policy and could extend rules project-wide, covering chats, forums, and repositories that today have no policy at all. Nelson’s post argues for exactly that outcome, framing this policy as a first step rather than a settled answer.