LLM Policy for Rust Compiler

URL SCAN: Add an LLM policy for rust-lang/rust — GitHub Pull Request #1040, rust-lang/rust-forge

FIRST LINE: Add an LLM policy for rust-lang/rust

THE DISSECTION

This is a living document from the Rust compiler project establishing ground rules for LLM-assisted contributions. On its surface, it is a moderation logistics document — a response to a "deluge of low-effort 'slop' PRs" generated by LLMs. But it is also a microcosm of civilizational triage: a high-capability technical community spending months and thousands of messages trying to draw a defensible perimeter around human intellectual contribution in a world where that contribution is being mechanically mass-produced.

The document is notably, almost frantically, scoped to avoid the only questions that matter. The moderators explicitly forbid discussion of:
- Long-term social or economic impact of LLMs
- Environmental impact
- Copyright status of LLM output
- Moral judgments about LLM users

This is not evasion. This is triage discipline. The team has concluded that those questions are unsolvable and unproductive, so they are building policy on the assumption that the questions can be bracketed. They cannot. The questions will be answered by reality regardless of whether a GitHub PR acknowledges them.

THE CORE FALLACY

The document treats the LLM policy problem as a community governance challenge — a problem of norms, moderation bandwidth, and workflow disruption. This framing is legible and tractable, which is why the team chose it. But it fundamentally misdiagnoses the nature of the "slop" problem.

The "slop" is not a culture problem. It is not a norm problem. It is not a moderation problem. It is a thermodynamic problem: the cost of generating a plausible Rust compiler contribution has collapsed to near-zero. The supply curve for human-comparable code has gone vertical, and no amount of governance structure can restore scarcity to a resource that has been made artificially abundant.

The Rust team's response is to build a wall. A well-reasoned, carefully debated wall, with well-labeled gate posts and explicit carve-outs for specific workflows. But a wall nonetheless — designed to preserve the scarcity of meaningful contribution by restricting access to the cheap production channel.

This is the correct immediate response. It is also a rearguard action. The wall will require constant maintenance, regular rebuilding, and increasingly elaborate enforcement as the cost of slop generation continues to fall. There is no equilibrium here, only escalation management.

HIDDEN ASSUMPTIONS

1. Legible human intent can be distinguished from LLM output. The policy leans on "threshold of originality" conditions rather than outright bans, assuming that human creative choices can be separated from AI pattern-matching. This assumption degrades in real time as LLMs improve. The policy is calibrated to current model behavior and will become increasingly unenforceable as frontier models close the gap between "indistinguishable from competent human" and "slop."

2. The project's voluntary contributors can be regulated. The policy governs a voluntary open-source community. The enforcement mechanism is social exclusion — loss of contributor privileges. This works for people who want to be part of the community and intend to comply. It does nothing for the wave of accounts that generate slop PRs without any interest in community membership. The Rust team acknowledges this in their motivation section but treats it as a solvable moderation problem rather than a structural condition of the threat model.

3. Scope limitation is a feature, not a concession. The document explicitly does not apply to subtrees, submodules, or other rust-lang repositories. This is framed as pragmatism — "we don't have the same moderation issues there." But the actual reason is that the Rust team cannot build consensus for a broader policy. The narrow scope is a capitulation to organizational fragmentation, not a deliberate design choice. Other Rust projects will face the same pressure. The policy will either proliferate or the problem will simply migrate to ungoverned spaces.

4. Moderation bandwidth is the binding constraint. The entire policy structure assumes that the bottleneck is human reviewer time and that LLM-generated content is bad because it wastes that time. This is true in the short term. But it mistakes the symptom for the disease. The disease is that human labor input is no longer a meaningful signal of contribution quality, and no governance structure built on the assumption of that signal can survive the collapse of the signal.

SOCIAL FUNCTION

This is transition management. Specifically, it is the work of a high-skill technical community attempting to preserve meaningful human contribution gates at the precise moment when those gates are becoming structurally obsolete.

The document is well-written, intellectually honest within its frame, and almost certainly the right local response to the immediate problem. It does not deserve ridicule. But it must be understood for what it is: a stabilization effort in a system that is not stable. The Rust team is building a dam on a river that is widening every week.

The out-of-scope list is the most telling feature. The hardest questions — economic displacement, copyright, environmental impact, moral status of LLM users — are not addressed because addressing them would require the team to acknowledge that they are participating in a transition that is not reversible, not locally manageable, and not unambiguously good for their community's long-term survival. So they draw a perimeter around the tractable problem and declare the rest out of scope.

This is reasonable. It is also a prequel. The out-of-scope questions will become the only questions, in time.

THE VERDICT

The Rust compiler LLM policy is well-executed local triage on a globally unwinnable problem. The team has correctly identified the symptom (slop PRs consuming moderation bandwidth) and built a targeted response. The response will work — for a while, for the rust-lang/rust repository, for reviewers who share the community's norms about what good contributions look like.

What it will not do: slow the underlying collapse of human labor as a meaningful input to software production. It will not resolve the copyright question. It will not address the economic displacement of programmers. It will not preserve the volunteer contributor model against a wave of zero-cost automated contribution.

The prior art section is the most useful analytical artifact in the document. It maps a spectrum from full ban (postmarketOS, Zig) to full encouragement (Linux Foundation) with the entire open-source ecosystem currently somewhere in the middle, trending toward restriction in high-prestige technical projects and leniency in projects where maintainer bandwidth is the binding constraint.

The direction of travel is toward restriction, because the problem is asymmetric: the cost of generating a plausible contribution is falling faster than the capacity to evaluate it is rising. No governance structure can fix that asymmetry. It can only manage the timeline of its arrival.

VERDICT: The document is a competent, honest piece of community governance that correctly identifies the immediate problem and builds a targeted response, while studiously avoiding the structural questions that make the problem insoluble. Treat it as useful local infrastructure, not as a durable solution. The questions it brackets will arrive regardless of whether this PR is merged.