I read the Rust Project’s new policy on large language model contributions (LLMs, AI systems that generate text or code from a prompt) twice in one sitting, which is not something I do often with project governance. I maintain a small open source repo on the side, and the question I have been fielding for two years is some version of “is AI-generated code okay here?” My answer has always been “depends, I am still working out depends on what.” That answer is finally defensible. The rust-lang/rust maintainers wrote a policy that is short, specific, and built around the assumption that humans still have to show up.
What stood out to me is the size of the rule, not its ambition. The team did not try to settle the AI question for the entire open source world. They wrote something that applies to specific groups inside one repository, and they stopped there. If you run a fork, a working group project, or a side library, none of it binds you. That scope is the point. Broad policies tend to read well and enforce poorly. This one reads tightly and ships with a concrete mechanism behind it.
A few details carry the weight:
- Only specific teams inside the main rust-lang/rust repo are bound by the new rule. Other projects adopt their own version on their own schedule.
- Private use stays fine. Querying a model about an error, summarizing a long discussion, or reviewing your own diff before opening a PR is encouraged.
- Public posting is the hard line. Comments, issue text, PR descriptions, documentation, and non-trivial source comments must come from you, not from a model.
The last bullet is where the policy lives. Most of the work in any maintainer’s queue is text, not code. PR descriptions that read like a first-draft model output. Issue bodies that paraphrase a chatbot answer. Doc PRs that rewrite a model’s first response with a few synonyms. Reviewers spend real nights triaging this. The Rust rule treats that as the bright line. Polishing the output afterwards does not move it across the line, because the test is whether a model originated the content, not whether it now reads like a polished human wrote it. That is the strictest clause in the document, and it is the one I expect other projects to copy first.
For code itself, the door stays open but narrower than most readers will expect. Submitting AI-generated code requires a reviewer who has agreed to handle the PR in advance. The contributor has to disclose the AI involvement on the PR. If the contribution merges, it carries an ai-assisted label so maintainers can study whether these PRs help or just add to the queue. Reviewers may close the contribution at any point if the policy is broken. The label loop is what I find most useful. It turns the question from a vibes argument into something the project can actually measure.
Concrete side effects follow from this shape:
- Disclosure moves to the front of the process. The contributor states it before submission, not after a reviewer notices.
- Reviewer load shifts to the contributor. Securing a willing reviewer is now part of the work of opening the PR.
- The ai-assisted tag gives maintainers a metric to track. Within a quarter or two, they can count the PRs, measure review time, and see whether the policy is paying for itself.
- The tag also acts as a quiet signal to newcomers who skim the merged history. A PR labelled ai-assisted reads differently than an untagged one, which does most of the enforcement work without anyone playing detective.
That last point is underappreciated. Most “AI policy” conversations I have followed in open source communities have been entirely opinion. Either AI contributions are obviously fine, or they are obviously harmful, and nobody collects numbers. The Rust rule is structured to collect numbers, which means a future revision can be informed by what actually happened rather than by what people feared would happen.
Where this is better than a blanket ban
A blanket ban is the easiest position to defend in a public conversation, and it is the position most projects will land on by default. It also does not survive contact with reality. The maintainer who bans AI entirely will still get AI-generated issues, AI-generated support tickets, and AI-generated documentation patches submitted as “small typos.” The line will be tested no matter what, so the question is whether your policy is structured to handle the test. The Rust policy is. The reason is that it puts the cost on the contributor who chose to generate the code, not on the maintainer who is already short on time. Reviewers now make judgement calls about disclosure, and contributors ask permission before sending work. That friction is the price of keeping the door open without flooding the queue. If you have ever maintained a popular repo, you know that a slightly slower but honest pipeline beats a fast one that quietly eats your weekends.
What to copy if you maintain a project
If you maintain anything and you have been waiting for someone to go first, this is your template. The structure travels well. You can lift the scope section, the allowed-uses list, the public-posting line, and the ai-assisted tag workflow and adapt them to your own repository in an afternoon. What you cannot lift is the wording. The Rust policy reads like a maintainer talking to other maintainers. Your version will read like a maintainer talking to strangers. Both are valid. Read the original, write your own scope, and publish it where contributors will see it. A CONTRIBUTING.md link is enough. A pinned issue is enough. What is not enough is silence.
If you contribute to Rust itself, read the policy in full before opening your next PR, especially the disclosure section. The full document is short enough to read twice, and the consequences of misreading it are not abstract. Reviewers can close contributions that violate the rule, and the label on a merged PR follows the commit history for as long as the project keeps the tag.
Trade-offs
This policy is not free. Reviewer load increases in absolute terms, because every AI-generated PR requires an opt-in reviewer, and finding one is the contributor’s job. Smaller projects will struggle to enforce the disclosure clause, because they do not have the reviewer depth to catch silent violators. The ai-assisted label is a real commitment to data collection, and the project will be expected to publish what it learns. If the tag becomes a quiet annotation with no follow-up report, the policy loses its strongest justification.
For projects that adopt a version of this rule, the trade-off is the same one the Rust maintainers accepted. You get a written rule that survives argument, and you give up the comfort of staying silent. In my experience that is a fair trade, especially for the maintainer who has been answering “is AI okay here?” in private for two years and is tired of guessing.
Bottom line
AI contributions are not the same as human contributions. Pretending they are is what flooded the queues. Pretending they are worthless is what made the conversation dishonest. The Rust policy is the first template I have read that admits both halves of that and writes a rule that follows from it. If you maintain anything, copy the structure. If you contribute to Rust, read the policy. Either way, the message is the same. AI is fine as a draft. It is not fine as a substitute for showing up.