The 50% Circuit Breaker Counts Disclosures, Not Code

The pattern

A project publishes rules about AI-generated contributions. The rules are written in the vocabulary of correctness — soundness, testing, review depth. Then you follow what they actually restrict, and the binding mechanism turns out to govern how much work arrives at a reviewer, not how good it is.

Two projects have now written policies that look like opposites. Both are rationing the same resource, and it is not code quality. It is unpaid human attention.

The latest instance

On 5 August 2026 the Inside Rust blog announced that rust-lang/rust has adopted a policy governing LLM use in contributions. Five teams ratified it — compiler, libs, types, rustdoc, bootstrap, and their subteams. It does not extend to other rust-lang repositories, to submodules and dependencies, or to teams that did not ratify, which the policy names as including lang and edition.

The summary line is easy to restate: an LLM may analyse, review, refine, check, and suggest, but not create. That is not the operative part.

The policy document on Rust Forge carries a circuit breaker. If more than half the pull requests merged into rust-lang/rust in any six-week window are LLM-created, merging of new LLM-created pull requests is suspended until the share drops back below half, and the suspension lasts at least ten days.

Nothing about that clause is a quality control. It does not care whether the code is correct. It caps throughput.

The rest of the document reads the same way once you look for it. LLM-created code needs a reviewer arranged in advance, before the code exists, through a dedicated mentoring channel on Zulip. Members of the rust-lang organisation are exempted from the non-critical restriction. Reviewers may close a pull request that appears LLM-created without disclosure, no explanation owed. Those are queue controls wearing the vocabulary of correctness.

What the breaker actually counts

Almost every other rule in the document turns on a person applying judgement in the moment. The circuit breaker is arithmetic, which makes it look like the sturdiest clause in the policy. It is worth being precise about what it measures.

Its numerator is self-reported. The contributor guidance tells authors to disclose LLM involvement when they open the pull request, and to write that disclosure themselves rather than have a model draft it. The reviewer guidance tells reviewers to attach the ai-assisted label to any pull request carrying such a disclosure. And the policy tells reviewers not to investigate — the stated position is that chasing this down is not a reviewer's job and that writing style is not evidence of anything.

Put those together and the ratio counts pull requests whose authors said so. It measures candor, not volume.

That has an uncomfortable property: undisclosed LLM-created work pushes the ratio down, not up. The breaker gets harder to trip at exactly the moment the norm it protects is being ignored. A project where nobody discloses reads as a project with no LLM contributions at all.

The claim, stated so it can be wrong: any AI-contribution threshold whose numerator comes from authors measures disclosure rate, not usage rate. What would show this wrong — if the labelled share of merged rust-lang/rust pull requests over a six-week window lands close to what contributors report in an anonymous survey, then disclosure is tracking usage and the number means what it appears to mean.

The second instance, with the opposite policy

Zig's code of conduct rules out LLM-generated content of any kind, code or prose, along with paraphrasing such content, using a model to correct spelling, and applying one to translation, brainstorming, or bug-finding. Where Rust permits with conditions, Zig prohibits outright.

But read what the prohibition is justified by. It is framed around keeping the environment suited to focused technical work — a statement about the conditions maintainers work under, not about defect rates. Same constraint, opposite lever.

A total ban does have one operational advantage over a graduated policy: it needs no numerator, because there is nothing to count. It also gives up every use Rust chose to keep.

Why teams keep walking into it

Because governance gets treated as a drafting exercise. Agree the rules, publish the page, assume compliance follows.

Rust's drafting is genuinely careful. It does not enumerate forbidden directories; it names properties. LLM-created code is out for anything touching soundness, for user-facing diagnostics, and for public doc-comments and safety comments, and the reviewer guidance gives the underlying test: keep it out of the parts of the tree where a defect would not be visible on inspection. A property survives refactors in a way a path list does not.

And the document still cannot count its own compliance. Drafting quality and measurability are separate problems, and only one of them got solved. This is the same failure mode that strands enterprise AI between demo and production — the constraint is process capacity, not model capability.

The cheapest way out

Move the label from open to merge. Copy the disclosure design as written and the author supplies the flag while the reviewer transcribes it. Make it instead a required merge-time field the reviewer fills in — AI-authored, AI-assisted, or neither — so the record comes from whoever read the diff. This is the instrumentation that never reaches the plan, alongside the evaluation and monitoring work nobody budgets for.

Write the property, not the path list. Ask where in your repository a wrong change would not look wrong. For most teams that is schema migrations, permission checks, money arithmetic, and retry or idempotency logic.

Choose the ratio and the window before you need them. Rust picked above 50% over six weeks with a ten-day floor on the cooldown. The specific numbers matter less than committing to them while no individual contribution is at stake.

Require a named reviewer before the branch exists. Cheapest clause in the document to adopt, and it does the most work. An agent-generated change with no reviewer attached is a queue entry, not a contribution.

If your reviewers are paid and scale with volume, none of this is your problem — you have a budget lever where these projects have a threshold, and should pull it first. Everyone else should get the number before arguing about the policy. Pull the last six weeks of merges and ask how many a reviewer would label AI-authored today:

gh pr list --state merged --limit 200 --json number,mergedAt,labels,author

If you cannot produce that second figure, you do not have a policy yet. You have a document.