Rust's new rules require disclosing LLM use. A Linux maintainer gives AI patches three seconds.
Five Rust teams ratified an LLM policy that bans AI-written docs and mandates disclosure. Linux leaves it to each maintainer. Both are rationing review time.
Five Rust teams ratified an LLM policy on August 5. It bans model-written documentation and diagnostics outright, and requires disclosure almost everywhere else. The reason isn’t taste. The monorepo is sitting on 1,281 open pull requests.
Linux is rationing the same resource with the opposite mechanism. Greg Kroah-Hartman barred LLM-generated patches from drivers/staging on August 4. Two days later Johannes Berg, who maintains the kernel’s wireless stack, said he would give AI-generated patches a three-second review and ignore whatever didn’t pass. The kernel has shipped a tree-wide AI policy since Linux 7.0, and Linus Torvalds spent July telling critics that Linux is not an anti-AI project. Neither fact stopped individual maintainers. Writing a patch got cheap. Reading one didn’t.
Review capacity is the scarce side
Jynn Nelson authored the policy and put the arithmetic straight into the announcement: “At the time of writing, there are 1,281 open PRs to rust-lang/rust.” Then the structural claim underneath it: “We have long had the problem that there are more people who want to write code than people willing to review it. With the advent of LLMs, this problem only gets worse.” Models add authors. They add no reviewers.
Most of what a reviewer does isn’t bug-hunting, which is the part that makes the backlog hard to automate away. “A great deal of it is deciding whether this direction is a good approach, whether the PR is a good idea at all,” Nelson writes. That’s why he calls shotgunning PRs at reviewers a high mental cost, and why he puts the code itself last: Rust wants an author who understands the change and can plan how it evolves. A diff supplies neither.
The signal collapse is the deeper problem. A polished, well-tested PR used to be evidence that a person had spent real time on it, and Rust’s culture got built on that inference: the project is reluctant to close PRs, it reads one as the opening of a mentoring relationship, it lets design shift mid-review. None of those signals survive contact with an agent, and Nelson says so bluntly: 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.”
Hobbyist communities are arguing along the same fault line, in blunter language. Fogus’s essay “Born Against”, posted August 4 and carrying 332 points and 373 comments on Hacker News, puts it as a claim about what the artifact is for: “the process of mastering a difficult field itself is the product, and something that runs is generally a nice-to-have.” Rust’s policy says a milder, more procedural version of that.
This is a different fight from the one Codeberg and Debian picked in July. That one turns on provenance and hosting: who can certify a license, which projects a forge is willing to keep. Neither Rust nor the kernel is arguing about copyright here. They’re arguing about whose afternoon gets spent reading the diff.
What the Rust policy asks of contributors
The policy text compresses to a single line: “It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.” Private use is unrestricted so long as nobody else sees the output. Ask a model about the codebase, have it summarize a long issue thread for you, have it review your own patch before you post: all allowed, none disclosed, because you’re the only reader.
Publishing changes the rules. Comments, issue bodies, and PR descriptions “originally created by an LLM” are banned from personal accounts, and so is model-written documentation, a category the policy stretches to cover doc comments, safety comments, and compiler diagnostic messages. Banned too: treating an LLM review as sufficient grounds to merge or reject. Review bots are permitted, but they need a separate GitHub account a user can block, and their comments “must not be blocking” until a human reviewer explicitly endorses them.
One tier down sit the uses that are fine if you say so. Machine translation, trivial changes, bugs you found with a model and verified yourself, and LLM-assisted review of someone else’s code all require disclosure. Rust also states that English isn’t required to contribute.
LLM-written code aimed at review lives inside an explicit, revocable experiment with five conditions: “Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.” Pre-arranged means a specific reviewer agreed beforehand, and a new contributor has to have that conversation before the PR exists at all. Non-critical means a soundness regression is very unlikely, which puts the trait system, MIR building, and the query system out of bounds. Well-tested has no escape hatch: if the area has no test suite you write one or you close the PR, and the policy spells out that “there are no exceptions for ‘writing the tests seems hard’.”
Every such PR gets an ai-assisted label and lands in a private Zulip channel whose stated job is data collection rather than gatekeeping. There’s also a hard tripwire. If more than half the PRs merged in a six-week window are LLM-created, new LLM-created merges stop until the share falls back under 50%, with a 10-day minimum cooldown. Scope is narrower than the headlines suggest: the policy binds rust-lang/rust and only the teams that ratified it, meaning compiler, libs, types, rustdoc and bootstrap. Lang and edition didn’t sign, and other rust-lang repositories set their own rules.
The genuine ambiguity is in the definitions. “Originally created by an LLM” covers editor autocompletion, not just chat output, so a contributor with inline completions turned on is inside the policy whether they think of themselves that way or not. Most of that output falls in the “trivial” bucket, which needs disclosure rather than a rewrite, and “trivial” is defined as a change where the alternative phrasings would be nearly identical. That’s a judgment call, and Nelson doesn’t pretend otherwise: many clauses are unenforceable, and the stated goal is “to remove plausible deniability” rather than to catch every violation.
Enforcement leans the same way. Reviewers are told not to play detective, style is explicitly not evidence even though generated output does have tells, and the one clause carrying a Code of Conduct penalty is lying about it. Nelson’s own verdict on the result is unusually candid for a policy author: “I do not think every rule in this policy is wholly good.”
The kernel rations by maintainer instead
Linux wrote its version down first. Documentation/process/coding-assistants.rst merged in December 2025 and shipped with Linux 7.0. It asks for an Assisted-by: trailer naming the agent and model version, and it draws one line the Rust policy doesn’t need to: “AI agents MUST NOT add Signed-off-by tags,” because “only humans can legally certify the Developer Certificate of Origin (DCO).” The human submitter reviews the output, checks licensing, adds their own sign-off, and owns the patch.
What the tree lacks is a single bar for what gets read. Torvalds’ July position is that “AI is a tool, just like other tools we use,” and that anyone who wants Linux to be an anti-AI project can fork it or walk away. Below him, subsystems are diverging fast. Kroah-Hartman’s staging rule is the cleanest example, and its logic is pedagogical rather than legal: drivers/staging exists “PRIMARILY as a place for new kernel developers to learn how to get involved in kernel development,” so pointing a model at its coding-style cleanups “is EXPLICITLY defeating the whole purpose.” Real security fixes still get through if the submitter tested on hardware.
Berg went further, and his phrasing is the line that stuck. He wrote that he would “make judicious use of ability to ignore patches, and apply it to pretty much all syzbot-AI-generated patches unless a 3-second review says ‘obviously right’,” and that he would not “argue with an LLM that can bullshit out code faster than another computer can even deliver it to me by email.” His condition for engaging is that a person is actually there: “Whoever is currently pretending to be the human in the loop absolutely needs to think about the patches.” syzbot has since been switched off for AI-assisted patches covering wireless.
Then there’s the third effect, which is deletion. Kroah-Hartman proposed dropping the Moxa Intellio driver, roughly 2,200 lines dating to 1999, and gave the reason plainly: no known hardware survives, the vendor says it isn’t needed, “and the LLMs are starting to poke at it and find ‘interesting’ things which will just waste everyone’s time given it’s not actually used.” A second removal in the same window took out the ipwireless driver for 3G PCMCIA cards, 3,635 deleted lines, with no trace of a user since 2011.
That second patch is the detail worth sitting with. It came from Qingfang Deng and carries the trailer Assisted-by: Codex:GPT-5.6 in the submission, so a model helped delete code that models had made expensive to keep. The kernel’s tag did its job there: tool, model version and human sign-off are all on the record. Berg’s rule and Kroah-Hartman’s are discretion rather than law, which is the mechanism on the Linux side. Maintainers have always been able to ignore patches. They’re now saying out loud when they will.
What this means for you
Check the specific repository and subsystem before you send anything, because there is no longer one answer per project. Rust’s policy covers five teams in one monorepo. The kernel’s document covers the whole tree, and then drivers/staging and wireless layer stricter local rules on top of it.
If a model was involved, say so where the project expects to see it: a disclosure line in the PR description for Rust, an Assisted-by: trailer for the kernel. Both projects penalize concealment far more heavily than tool use. And don’t route review replies through a model. Nelson is short about that one: “If we wanted an LLM’s opinion, we could have asked it ourselves.”
For a Rust patch the order of operations has changed. Find the reviewer, agree the change is in scope, write it, then bring tests for every edge case either of you can name. Skipping the first step is now a policy violation rather than an etiquette problem, and reviewers can close the PR without discussion.
Watch the circuit breaker. If LLM-created PRs cross half of merged PRs in a six-week window, merging stops for at least 10 days while the teams reopen the question. It’s the only numeric limit in either policy, and the number it produces will settle more than the argument has. Either the experiment stays a minority of the queue, or Rust finds out where its own ceiling is.
Share this article
Quick reference
Sources
- rust-lang/rust is adopting an LLM policy — Inside Rust Blog
- LLM Usage Policy — Rust Forge
- Nelson: rust-lang/rust is adopting an LLM policy — LWN.net
- AI Coding Assistants — The Linux Kernel documentation
- Linux Wireless Maintainer Takes Firm Stance Against AI/LLM Generated Slop Patches — Phoronix
- Linux's Staging Area To Now Reject LLM-Generated Patches, Except For Real Security Fixes — Phoronix
- Additional Old Linux Drivers Face Removal Due To Noise From AI/LLM Coding Agents — Phoronix
- tty: remove the ipwireless driver — git.kernel.org
- Born Against, or why hobby programming communities are against LLM usage — Fogus
Frequently Asked
- Can I still use an LLM to write a Rust patch?
- Only inside the policy's experiment. A reviewer has to agree in advance, the change has to be non-critical, you have to disclose it, and you have to ship tests. Documentation and compiler diagnostics are off-limits either way.
- Does the Linux kernel have one policy?
- It has one document. Documentation/process/coding-assistants.rst shipped with Linux 7.0 and applies tree-wide, but maintainers add stricter local rules on top. drivers/staging now rejects LLM-generated patches, and Linux wireless gives them a three-second look.
- What do I have to disclose?
- In Rust, any public LLM output the policy doesn't exempt, including machine translation, trivial changes, bugs you found with a model, and LLM-assisted reviews of other people's code. In the kernel, an Assisted-by trailer naming the agent and model version.
- Can an AI agent sign off on a kernel patch?
- No. The kernel documentation says AI agents must not add Signed-off-by tags, because only a human can legally certify the Developer Certificate of Origin.
- What happens if I hide LLM use in Rust?
- Lying is the one clause carrying a Code of Conduct penalty: a warning first, a possible ban for repeat violations. Reviewers are told not to hunt for evidence, and that writing style is not proof.