The Rust project has adopted a policy regulating the use of LLMs in contributions to the main repository rust-lang/rust. Five teams have signed the document, written by Jynn Nelson. The policy defines what is acceptable and what is not when using a model to open pull requests, report issues, or respond to review comments.

The move comes as Debian is still voting on four similar proposals, as we reported on July 26. The two most structured open source projects writing explicit rules in the same period signal a phase change: AI contribution governance becomes operational.

Why this matters to you. If you’re integrating LLMs into collaborative technical workflows, these documents are the model to start from. Rust identifies three concrete problems: PRs generated by a model look curated but don’t indicate real understanding, the volume of contributions saturates review capacity, and people who paste LLM responses into review comments waste reviewers’ time. These are dynamics any technical team encounters when members use AI assistants in shared work.

The policy formalizes rules that were previously implicit and applied inconsistently. Now contributors know what’s expected before sending a PR, and reviewers have an explicit reference when closing one that doesn’t comply.

In detail

Before this policy, the Rust project applied what Nelson calls a “wild west” approach: no published rules on LLM use, inconsistent moderation, new contributors discovering the rules only when their PR was closed for reasons they didn’t understand. The lack of explicit rules worked against the project’s goals of transparency and inclusiveness.

The underlying problem is that a well-written pull request, with tests and documentation, was traditionally a signal of commitment and understanding. It influenced Rust’s culture in specific ways: reviewers were reluctant to close PRs because they represented someone’s work, the process emphasized incremental discussion, and a PR was interpreted as interest in joining the community long-term.

With LLMs, none of these signals are reliable anymore. A curated PR no longer indicates real effort. The author doesn’t necessarily understand the code they produced. In the case of autonomous agents, there’s no one on the other side. Nelson notes that at publication time there are 1,281 open PRs on rust-lang/rust, against review capacity already insufficient before models arrived. Making code writing easier worsens a problem the project already had.

The policy applies to four categories of people: those who review or moderate PRs, those who write PRs with LLM-generated code, those who report issues found with a model, and those who directly cite LLM output in issues or comments. Those who don’t fall into these categories don’t need to change anything.

The point for those managing technical teams. Nelson is explicit: most review work consists of deciding if a direction is right and if the PR makes sense. Sending dozens of PRs to reviewers carries high mental cost. The code itself is the smallest and in some cases least important part of the contribution. What matters is that the author understands what the code does, has planned how it will evolve, and decided how it should look. An LLM doesn’t help with any of these steps.

The policy is an operational document for a specific repository. It applies to five teams among all those in the project, and governance remains local. The limits are stated: the policy concerns only rust-lang/rust and doesn’t extend to the entire Rust ecosystem.

The parallel with Debian is direct. Both projects are writing rules on the same topic in the same period, starting from similar problems: contributors using LLMs without knowing what’s expected of them, reviewers without explicit references to reject unacceptable contributions, and tension between welcoming newcomers and collaboration quality. The difference is that Rust already has a document signed by five teams, while Debian is still voting on four proposals ranging from total ban to gradual approach.

For those bringing AI into collaborative processes, the precedent is twofold: written rules come before problems, and code generated by a model doesn’t substitute for the judgment of whoever produces it.