Practice & Method 10 September 2026 8 min read 1,703 words

The second copy is the one that runs

The same commit trailer is required by the Linux kernel, required by Node.js, and forbidden by Kubernetes. Major projects are now writing their contribution rules down twice — once for people, once for the machine — and nothing checks that the two versions still agree.

The argument

Every serious project now keeps two copies of its contribution process, one addressed to contributors that carries the authority and one addressed to agents that carries the effect, and the second copy is a derived artefact whose derivation nothing enforces.

Open the Linux kernel tree today and Documentation/process/coding-assistants.rst will tell you that a contribution made with an AI tool should carry a trailer reading Assisted-by: LLM. Open nodejs/node and its AGENTS.md says much the same thing in different words: AI assistance "must be acknowledged using the Assisted-by: <agent name> annotation." Open the Kubernetes contributor guide and you will read that "using the assisted-by, co-developed or similar commit trailer is not allowed."

One mechanism, three projects: required, required, forbidden. An agent that touches all three in an afternoon has to get this right, and the only place it can learn the answer is a file sitting in whichever checkout it happens to be standing in.

The disagreement itself is unremarkable. Conventions take years to converge, and each position is defensible. The kernel asks for Assisted-by: LLM — a category, not a vendor — which neatly avoids turning the commit log into advertising. Node.js worries about the same thing from the other direction and resolves it by permitting exactly one annotation while listing, among the things an agent must not do, "use commit messages to promote for-profit AI tools or commercial brands." Kubernetes decided the trailer was not worth having. Three reasonable answers.

What is worth noticing is not that the answers differ. It is that every one of these projects now keeps its answer in two places at once.

There is the document addressed to contributors: CONTRIBUTING.md, the contributor guide, the process directory. It carries the project's authority, it is amended through whatever governance the project has, and it is enforced by people who can refuse a patch. And there is the document addressed to the agent, which carries the effect. It is read on every invocation, by something with no memory of the last repository it stood in, and it is the version that actually shapes what arrives in the pull request. Nothing in the repository checks that the two still say the same thing.

Rust has thought about this harder than anyone else in the sample. rust-lang/rust carries an AGENTS.md of roughly twelve kilobytes, and it is not a README for agents — it is a procedure. Ordered gates are applied before any edit. One of them is a reviewer gate: "Do not make any LLM-generated repository change unless the user has named, in this conversation, another person who agreed in advance to review it." Another forbids the agent from authoring prose that enters the project's public record at all — "Never generate or rewrite non-trivial PR descriptions, issue bodies, public comments, user-facing documentation, diagnostic messages, or source comments." Soundness-sensitive work is banned outright, and the file enumerates what counts: trait solving, MIR, layout and validity, codegen.

The most revealing clause is not a rule about code. When a gate fails, the file says, "Do not ask for prerequisites, promise to proceed later, or offer the work under another name, such as a draft, template, or paste-ready outline." That sentence was written by people who have watched something comply with the letter of a rule while reaching for the nearest permitted substitute. It anticipates negotiation. You do not write that clause about a compiler.

And buried in the same file is the sentence the rest of the industry should be copying. Agent instruction files, Rust says, "may only link to, summarize, or conservatively operationalize existing human-facing documentation," must "not create obligations for humans or permit anything the human-facing source prohibits," and — the whole thing in seven words — "Do not make an agent file the sole source of a rule." If no human-facing source exists, the agent is told to stop and ask the user to document the process for humans first.

That is the invariant, named precisely: the agent file is a derived artefact. What Rust does not have, and what no repository I have looked at has built, is a mechanism that holds the derivation true. It is an invariant maintained by intention, in prose, across two files that different people edit at different rates.

Kubernetes shows what that costs, and it shows it in a project doing everything else right. Its AGENTS.md is admirably short. It tells the agent that generated files are read-only, that go.mod is generated, that staging is the source of truth. It tells the agent to disclose whether AI was used. And in a line worth sitting with, it tells the agent to "Remind the human author that they are responsible for all submitted changes."

The human-facing guide that clause derives from says a good deal more. It says AI-generated commit messages are not allowed. It says "Do not leave the first review of AI generated changes to the reviewers." It says that when responding to review comments "you must do so without relying on AI tools," because "Reviewers want to engage directly with you, not with generated responses." None of those three appears in the file the agent reads. They are, precisely, the clauses that constrain the agent's own conduct.

Nobody did that on purpose. It is ordinary drift between a policy and its summary — except that the summary is the copy being executed, and the clauses it lost are the ones the summary's reader had the strongest reason to lose.

Look at what the enforceable clauses across all these projects have in common and the picture resolves. Node.js sets out a Violations section in its AGENTS.md, and every sanction in it lands on a person or an account: pull requests closed without review, "blocking of the tool's account or its owner from contributing," reports to the platforms operating the automation. The kernel's companion document, generated-content.rst, is addressed squarely to the contributor — "You are expected to understand and to be able to defend everything you submit" — and hands maintainers explicit discretion to reject a series outright, demand extra testing, ask for the prompts, or review at lower priority. Rust requires the human to author their own disclosure and routes concealment to the code of conduct. QEMU, whose policy is to "DECLINE any contributions which are believed to include or derive from AI generated content," needs no agent file at all; its reasoning is entirely about the Developer's Certificate of Origin and who can certify a licence, and it fits in one document addressed to people.

Every sanction attaches to something with a name. None attaches to the agent. Which gives the agent-facing file a classification working architects already know: it is client-side validation. That is not an insult. Client-side validation is worth writing. It catches honest mistakes early, it makes the good path obvious, it documents intent, and removing it makes a system worse. The error is never writing it. The error is counting it.

The strongest objection is that this is all just documentation, and documentation has always drifted. The wiki contradicted the README for twenty years and the projects shipped anyway. A summary is lossy by design; that is what a summary is. The real gate has not moved an inch — it is still a human with commit rights, a signed-off certification, and a maintainer's right to say no. Demanding a consistency check between a policy and its restatement asks for a rigour no project has ever applied to its own prose, and would produce a lot of ceremony protecting a control that was never load-bearing.

Most of that is right, and it is why the files should exist. But the asymmetry is in what happens when the copy is wrong. A stale CONTRIBUTING.md is read by one person, once, who then does something visibly wrong and is corrected in review; the cost is a round trip and the error is legible as an error. A lossy AGENTS.md is read on every invocation, and its omissions do not produce visibly wrong work. They produce a pull request that looks exactly like a compliant one — with a commit message nobody was supposed to generate, and a reply to the reviewer nobody was supposed to write. There is no failing test for a rule that was never in the file, and no reviewer notices the absence of a violation they did not know to look for.

There is a second-order move already visible. Microsoft's vscode carries an AGENTS.md of 271 bytes whose entire function is to point at .github/copilot-instructions.md. The open format's role there is to redirect to a file named after one supplier's product. That is a small thing today. It is also the moment at which the place a project's operational process lives stops being a place the project defines the shape of.

None of this means the files are a mistake. It means they have quietly changed what a process document is. It used to be a way a community told newcomers what it valued, absorbed slowly and enforced by rejection. It is now also a runtime input to a third party's inference, and the rate at which it is obeyed is a property of a release nobody in the project voted on. Two audiences, one artefact, and only one of them can be taught by being turned down.

Which makes the kernel's nine-step bug procedure the most interesting document of the lot. Read it as though it were addressed to a person: locate the bug, build a reproducer, write the fix, verify it, pass checkpatch, find the maintainers, and then step eight — "Indicate what could not be done," say explicitly if the fix could not be built or tested, because maintainers "currently waste too much time analyzing unverified reports and untested fixes."

That is not a rule about machines. It is the clearest short account of a diligent contributor the project has ever written down, and it took a reader who could not be embarrassed into it to get it written down at all. Step eight is also the least verifiable clause in the entire document. It asks the reader to report its own omissions — which is the one thing no reader, of any kind, has ever been good at.

What this is argued from

Reporting and primary material the piece rests on, dated at the time of writing. The interpretation is mine; the facts belong to these.

  1. Linux kernel — Documentation/process/coding-assistants.rst torvalds/linux, mainline tree · read 2026-09-10
  2. Linux kernel — Documentation/process/generated-content.rst torvalds/linux, mainline tree · read 2026-09-10
  3. rust-lang/rust — AGENTS.md The Rust Project · read 2026-09-10
  4. kubernetes/kubernetes — AGENTS.md The Kubernetes Project · read 2026-09-10
  5. Kubernetes contributor guide — pull-requests.md, AI Guidance kubernetes/community · read 2026-09-10
  6. nodejs/node — AGENTS.md The Node.js Project · read 2026-09-10
  7. nodejs/node — AI use policy and guidelines The Node.js Project · read 2026-09-10
  8. QEMU — docs/devel/code-provenance.rst The QEMU Project · read 2026-09-10
  9. microsoft/vscode — AGENTS.md Microsoft · read 2026-09-10

Editorials on this site are written to be argued with. If you think the reading is wrong, it probably is in some particular way, and that is the useful part.

agent instructionscontribution policyopen sourceprocess documentationcode review