The news
On August 5, 2026, five teams in the Rust project adopted a policy governing how Large Language Models can be used when contributing to rust-lang/rust. The TL;DR: LLMs are fine for asking questions, analyzing, distilling, reviewing. But not to create.
The policy doesn’t ban LLMs outright. It draws a line: you can use them to think, but not to generate for you. If you post LLM-generated code, you must disclose it. If you copy-paste review comments into ChatGPT and paste its response back, your PR gets closed. If you submit soundness-critical compiler changes generated by an AI, you’d better be a domain expert — and even then, it’s strongly discouraged.
The internet, predictably, lost its mind. 610 upvotes on r/programming. Hundreds of comments. Half calling it a necessary defense of the human community, half calling it Luddite gatekeeping.
Why I think they’re right
I’ve been contributing to open source for a few years now. Not at Rust’s scale, obviously — but enough to understand the dynamic. And here’s the thing nobody talks about when they debate “should open source accept LLM code?”
Code is the smallest part of open source.
When you submit a PR to a project like Rust, the code itself is maybe 20% of what you’re contributing. The other 80% is:
- Understanding why this change matters
- Planning how it interacts with everything else
- Being available to maintain it when it inevitably breaks
- Joining the community and building trust with reviewers
An LLM can fake the 20%. It cannot fake the 80%. And when a reviewer spends 45 minutes reviewing a polished, well-tested PR only to discover the author has no idea what the code does — that’s not just wasted time. That’s trust destroyed.
The Rust policy has a great framework for this. It distinguishes between using LLMs as a tool for thinking (answering questions, analyzing RFCs, checking for edge cases) versus using them as a replacement for thinking (generating code, writing comments, responding to reviews). The first is allowed, often without disclosure. The second is heavily restricted.
The real problem: review bandwidth
There are currently 1,281 open PRs on rust-lang/rust. The project has never had enough reviewers. Making it easier to generate code without making it easier to review code is a recipe for collapse.
The policy addresses this head-on: reviewers are not required to review LLM-generated PRs. They can close them on sight. This isn’t elitism — it’s triage. When you have 1,281 PRs and limited reviewer attention, you have to prioritize PRs where the author can actually participate in the review conversation.
The Zig approach vs the Linux approach
What makes this interesting is how different projects handle the same problem:
- Zig has a flat ban: “No LLM-generated content, whether it be code or prose.” Period. Andrew Kelley drew a hard line.
- Linux says “AI is a tool, just like other tools we use.” Linus Torvalds is pragmatic — if the code is good, who cares how it was made?
- Rust is trying to find the middle ground. Neither ban nor free-for-all. A policy that acknowledges both sides of the debate and creates enforceable rules.
I respect all three positions, but Rust’s approach is the most interesting to me. It’s explicitly designed to be changed later — the policy has provisions making it easier to modify than it was to adopt. It’s a living document for a problem that’s evolving faster than any governance structure can keep up with.
What this means for the rest of us
Most of us aren’t contributing to Rust. But the dynamics this policy addresses affect every project, every company, every team.
The core tension is real: LLMs make it easier to produce artifacts, but open source is not a factory for artifacts. It’s a community of people building things together. If you optimize for artifact production, you destroy the community. If you optimize for community, you might slow down artifact production. There’s no easy answer.
What I appreciate about the Rust policy is that it’s honest about this tension. It doesn’t pretend LLMs don’t exist. It doesn’t pretend they’re neutral tools. It says: here’s how we’re handling this right now, we know it’s imperfect, and we’ll revisit it.
That’s governance done right.
For the curious: the full policy is here, and the announcement blog post is worth reading in full.