Five teams in the Rust project have adopted a policy governing how large language models can be used when contributing to rust-lang/rust — and the reasoning behind it says more about the future of collaborative software development than any model launch this year.
The policy, published Tuesday on the Inside Rust blog, draws a line that’s simple to state and hard to argue with: “It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.”
Why a Code Project Needs an AI Policy
The Rust compiler is one of the most consequential open-source projects on Earth. It’s the language now used in the Linux kernel, in Android, in Cloudflare’s infrastructure, and in thousands of production systems where memory safety matters. When the people maintaining it say they have a problem with AI-generated contributions, that’s not a philosophical debate — it’s an operational one.
The blog post, written by the policy’s original author, describes three issues that grew until the project had to respond:
-
Polished technical products no longer indicate effort and understanding. A well-structured pull request used to mean someone had spent hours learning the codebase. Now an LLM can produce one in seconds. The author writes: “Authors of polished PRs no longer necessarily understand their code — and in the case of autonomous agents, there is no longer someone on the other end at all.”
-
Making code easier to write exacerbates review bandwidth problems. There are 1,281 open pull requests to
rust-lang/rustat the time of writing. More code arrives than reviewers can assess. LLMs make that worse — not because the code is bad, but because reviewing is mostly about deciding whether a change is a good idea, not just whether it works. -
Mechanical copy-pasting wastes everyone’s time. Contributors paste review comments into an LLM and paste the response back. “If we wanted an LLM’s opinion, we could have asked it ourselves,” the author writes. “We want to hear your thoughts, not a machine’s.”
What the Policy Actually Says
The rules apply to four groups: people who review or moderate PRs, people who submit LLM-generated code, people who report issues found using LLMs, and people who quote LLMs in comments. Everyone else can carry on.
The core distinction is between using AI as a tool and using AI as a substitute for understanding:
- Allowed without disclosure: Using an LLM privately to understand code, draft ideas, or check your work — as long as you don’t post the output publicly.
- Allowed with disclosure: Machine translation, trivial changes, bug discovery, and reviewing other people’s work with AI assistance.
- Heavily restricted: LLM-generated code changes. These require pre-arrangement, full disclosure, tests, and a domain expert author. The policy holds AI-generated code to a higher bar than human-authored code, not a lower one.
- Banned: LLM-generated soundness-critical changes (code that affects Rust’s memory safety guarantees), LLM text in public docs or PR descriptions without clear marking, and posting LLM output as if it were your own.
The policy is deliberately not a blanket ban. The author acknowledges that many in the Rust community “find value in AI” while others “feel that its negative impact on society and the climate are severe enough that no use is acceptable.” Rust operates by consensus, not by decree. The policy exists because the alternative — an unofficial list of moderation notes applied inconsistently — was worse.
The Problem This Exposes
What stands out here is not the policy itself but the gap it reveals. The Rust project is one of the most well-resourced open-source communities in the world, with corporate backing from Microsoft, Google, AWS, and others. If they are struggling with review bandwidth under the weight of AI-generated contributions, smaller projects are further underwater.
The 1,281 open PRs number is the tell. Review capacity has been the bottleneck in open source for years — the Rust team says so explicitly. AI doesn’t solve that problem; it inverts it. More code arrives, faster, better-formatted, and with less understanding behind it. Reviewers now have to assess not just whether the code is correct but whether the person who submitted it actually knows what it does.
This is a labour question dressed up as a technology question. The review burden — the unpaid, mostly invisible work of reading other people’s code and deciding whether it’s safe to merge — is the structural cost of open source. LLMs increase that cost while reducing the cost of producing the code being reviewed. The economics point in one direction: more reviewer burnout.
How Other Projects Are Handling It
The Rust policy sits between two extremes. At one end, the Zig programming language has a strict “no LLM, no AI” policy: “No LLM-generated content, whether it be code or prose.” At the other, the Linux kernel’s position, articulated by Linus Torvalds, treats AI as a tool like any other: “AI is a tool, just like other tools we use.”
The Rust author notes that neither extreme works for a consensus-governed project. A ban would alienate contributors who use AI productively. A free-for-all would drown reviewers in low-effort submissions. The middle path — allow AI as a tool, restrict it as a creator, require disclosure — is likely what most projects will land on, because most projects face the same structural pressures.
What This Means for New Zealand
New Zealand’s open-source community is small but active. Projects like the Servo browser engine (originally Mozilla, now community-maintained) and various Rust-based tools have Kiwi contributors. The Rust policy directly affects how those contributors can participate.
More broadly, the policy sets a precedent that could reach beyond open source. If the Rust project — which values transparency, community, and deep expertise — has concluded that AI-generated contributions need higher scrutiny than human ones, that logic applies to any collaborative knowledge project. Wikipedia, academic peer review, and standards bodies all face the same inversion: AI makes production cheap and review expensive.
❓ FAQ
Can I still use ChatGPT to help me contribute to Rust? Yes. The policy explicitly allows using LLMs to answer questions, analyse code, check your work, and suggest improvements. What it restricts is having an LLM write the code you submit, and posting LLM-generated text in public discussions without disclosure.
Does this mean AI-generated code is banned in Rust? Not entirely. Pre-arranged, non-critical, well-tested LLM-generated code changes are allowed with disclosure. The policy sets a higher bar, not an absolute prohibition. Soundness-critical changes — code affecting Rust’s memory safety guarantees — are effectively off-limits for LLM generation.
Why not just ban AI altogether? The author explains: Rust operates by consensus, and there is no consensus on AI within the community. Some members use AI productively; others oppose it on ethical or environmental grounds. A ban would require a benevolent dictator, and Rust doesn’t have one.
Will other open-source projects adopt similar policies? Several already have. Zig has a stricter ban. Linux has a more permissive stance. The Rust approach — structured middle ground with clear disclosure rules — is likely the template for consensus-governed projects that can’t swing to either extreme.
🔍 THE BOTTOM LINE
The Rust policy is not about whether AI is good or bad. It’s about what happens when the cost of producing code drops to near zero while the cost of reviewing it stays the same. That asymmetry is the real story, and it’s coming for every collaborative project that relies on volunteer review. The Rust team wrote their rules down. Most projects haven’t yet.
