The AI contribution label belongs in the commit, not the meeting notes

Updated October 23, 2026: the Linux kernel is removing its Assisted-by tag requirement. The kernel paragraph, the policy table, and a new section on what the kernel learned reflect that change. The case for keeping AI help out of Co-authored-by and away from Signed-off-by hasn't changed.

You run git log on a clean morning and the last line of the newest commit reads:

Co-authored-by: Claude <noreply@anthropic.com>

Then you open the PR on GitHub and there it is in the contributors strip, a little avatar sitting next to yours, as if a teammate named Claude joined the project overnight and shipped some code with you.

It didn't. Nobody hired it, nobody can put it on a reviewer rotation, and nobody can ask it to certify that it had the right to submit the change. The line looks like a name tag. It's doing the job of a provenance record. Closing that gap is the entire job here.

The question the footer is actually trying to answer isn't "who else is on the team." It's narrower and more useful: did AI materially help write this change, and where is that written down so the next person doesn't have to guess?

A tiny line, debated in public

Artsy, the art-market company, ran exactly this argument in the open. On May 27, 2026, they opened an RFC titled "disclose LLM usage in commits or PRs", and merged it on June 8. The proposal is deliberately small: adopt a lightweight convention for marking commits, or PRs, that were produced with significant LLM assistance, recording the provider and optionally the model.

The first draft reached for Co-authored-by, because that's the trailer everyone already knows. The discussion talked them out of it. By the time it merged, the example in the PR body had become:

Assisted-by: Claude:Opus-4.5

Joey Aghion made the case for the switch plainly in the thread: Assisted-by was compelling because it keeps responsibility visibly and exclusively with the human contributor, even though GitHub's UI doesn't count it as a contributor. That last clause is the feature, not the bug. The whole point is that the tool does not get an avatar. He also argued for merging it so the team could start to see how much trouble, or value, it actually provides, which is a refreshingly honest way to adopt a convention.

What I like about the thread is that nobody pretended it was clean. The team poked at the real edges:

• Commit or PR? A trailer per commit is precise but noisy. A note on the PR is easier but blurs which change the AI touched.
• What about Cursor's auto mode, where the tool picks a model and never tells you which one? You can't record a model string you were never given.
• Won't people just automate it with a Claude hook or a shell alias, so the trailer appears whether or not the help was significant?
• Aren't nearly all our commits AI-assisted now anyway? If the label is always on, does it still mean anything?

Those aren't reasons to skip it. They're the actual design problem, and they're the same four questions every team will hit the week they try this.

Why a trailer, and why this one

A git trailer isn't a vibe. Git supports structured key: value lines at the foot of a commit message on purpose, and documents how to parse them. That's the difference between disclosure you can grep and disclosure that lives in a sentence somewhere in a PR description nobody reads twice. A trailer is queryable. Six months from now you can actually answer "which commits in this release had AI help" without spelunking through review threads.

The reason Co-authored-by is tempting is that GitHub already documents it for commits with multiple authors. It's right there, it works, it renders nicely. But it was built for people, and it makes a person-shaped claim. Bence Ferdinandy put the objection bluntly back in December: "Don't abuse Co-authored-by for marking AI assistance." Co-authorship says this entity shares authorship and accountability. A model can't hold accountability, so the claim is false the moment you write it.

And this is not the signature conversation. GitHub will mark a commit verified when a cryptographic signature checks out. That tells you a key vouched for the commit. It tells you nothing about whether a model helped write it. Signature is "who stands behind this." Provenance is "what went into this." Keep them in separate drawers.

Artsy isn't alone

This isn't one company's house style. Open source has been sorting the same line out loud for months. James Fredley's All Things Open piece, "Assisted-by: How open source projects are drawing the line on AI contributions" from May 11, 2026, walks through a range of responses, from outright bans to enforced disclosure, and notes that the projects choosing to allow AI help with rules keep landing on the same trailer: Assisted-by:. The list of projects that had published guidance by then is not fringe. It included the Linux Kernel (which is now dropping its tag, more on that below), Fedora, Rocky Linux, OpenTelemetry, the Apache Software Foundation, LLVM, QEMU, and others.

The Linux kernel's version was the most spelled-out, and it has become the cautionary tale. The kernel's AI coding assistants guidance, added in the 7.0 release, asked for a tag in the form Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], later cut down to Assisted-by: LLM [TOOL1] [TOOL2]. On October 9, 2026, after the kernel Maintainers Summit agreed to deprecate the tag, Sasha Levin posted a patch removing the Assisted-by references from the documentation and from checkpatch.pl. A v2 on October 13 carries Reviewed-by tags from Kees Cook and Greg Kroah-Hartman, and Christian Brauner added his on October 21. As of October 23, the attribution section is gone from the linux-next documentation but still present in the mainline 7.3 docs, so the accurate word is "being removed," not "removed."

The kernel is keeping the hard line that mattered most: an AI agent must never add a Signed-off-by tag, because that tag certifies the Developer Certificate of Origin, and only a human can certify they had the right to submit the contribution. The removal patch leaves that rule in place. OpenTelemetry's examples look like Assisted-by: Claude Opus 4.5. Fedora and Rocky both recommend the trailer when assistance was significant.

Read across all of them and the consensus is quietly consistent: write down that AI helped, name the tool, optionally name the model, and keep every signature, certification, and ounce of accountability firmly on the human. The kernel's retreat doesn't undo that last part. It undoes the assumption that an optional tag will be used just because the docs ask for it.

A nutrition label, not a name tag

Here's the mental model worth keeping, because it tells you what to put on the label and, more importantly, what to leave off.

A name tag says I am a member of this team. That's what Co-authored-by: Claude accidentally claims, avatar and all.

A signature says I, a human with a key, vouch for this. That's the verified badge, and it stays human.

A nutrition label just lists what went into the thing. It doesn't vote, doesn't sign, doesn't join the team, and doesn't pretend the ingredients had opinions. It's information for whoever picks the change up next.

Assisted-by is the nutrition label. So the label should carry: that AI assistance was material to this change, which tool provided it, and, when the tool tells you, which model. It should not: turn the tool into a contributor, stand in for your sign-off, masquerade as a signature, or demand a model string the tool refuses to expose. If Cursor's auto mode won't say which model it picked, the honest label is the tool name and "auto," not a guess. A nutrition label that lists ingredients the cook never saw is worse than one that admits "proprietary blend."

The AI assistance trailer policy

You don't need a governance program to get the benefit. You need a half-page in the repo that says when the label goes on and what it says, so it's a habit instead of a debate per commit. Here's the shape. Fill in the right column for one repo and you're done.

Three rows do most of the work, and they're the three people skip. Trigger is where you decide what "material" means before you're arguing about it on a Tuesday, so the label means something instead of riding on literally everything. And Stays human is the row that keeps this honest: the trailer adds context, it never moves accountability off a person. Enforcement is the row the Linux kernel learned about the hard way. Everything else is formatting.

One nice side effect: once the trailer is consistent, git log --grep='Assisted-by' becomes a real answer to a real question, and your reviewers get a signal they can actually filter on.

What the kernel learned about Assisted-by

Example

The short version: an optional tag that nobody checks turns into noise. Either enforce it in CI, or ask for a few sentences of prose where reviewers already read.

The numbers are what moved the kernel. LWN's Maintainers Summit write-up counted 18,533 non-merge changesets in the 7.3 cycle through -rc7, and 1,884 of them, essentially 10%, carried an Assisted-by tag. Levin's v2 patch puts the problem plainly: actual LLM use "is far more widespread," so "its absence says nothing about how a patch was made." The patch frames the decision as a choice "between finding a way to enforce the requirement and dropping it," with "a strong, though not unanimous, consensus in the room to drop it." Information about how tools were used should go in the patch cover letter instead.

The people who once argued for the tag changed their minds in public. Greg Kroah-Hartman, who had supported keeping it, wrote on October 13 that "it didn't work out at all and maintainers are really annoyed by it." It wasn't unanimous. Steven Rostedt pushed back on the list, saying the reasoning belonged on the mailing list rather than in an LWN article and floating a stronger Vibe-coded-with: tag. Laurent Pinchart wrote in a mailing list post, reported by The Register, that he was "not happy removing the tag without adding another mechanism for required disclosure."

Our read, for a company repo rather than the kernel: you have an advantage the kernel doesn't. You own the CI, the PR template, and the merge button. If the AI label matters to you, make CI ask for it on every PR. If it doesn't matter enough to check, don't keep a rule that quietly measures who bothers to comply. Ask for prose in the PR description instead. We worked through that choice, and the free tools that can enforce it, in Linux is dropping Assisted-by: what AI disclosure needs.

Where the label sits

If you've read us before, this is downstream of the work, not another gate in front of it.

The AGENTOWNERS contribution policy is the door: it decides whether an AI-authored change gets into the repo at all, before anyone reads the diff. Review lanes decide who looks at the change once it's inside. Work receipts are the evidence trail for what an agent actually did on a job.

The Assisted-by trailer is a different beast. It's not a gate and it's not a receipt you file somewhere else. It's the label that travels with the change, baked into history, so it's still there long after the PR thread is archived and everyone who remembers the context has moved on. The door decides if the change gets in. The lanes decide who reads it. The trailer is what the change says about itself, forever.

Bring one repo

Don't write an AI disclosure framework. Add one trailer convention to one repo, the one where, a year from now, you'd actually want to know which changes had AI help.

Decide what counts as material. Pick commit-level or PR-level and commit to it. Decide how you'll check it, or choose prose instead of a trailer. Drop a commit template in the repo so the line is one keystroke, not a thing to remember. Write the auto-mode rule down so nobody fakes a model string. Then leave the certifying, signing, and owning exactly where it already lives: with the person who hit merge.

The next time you run git log and see a line at the foot of a commit, you want it reading like an ingredient list, not introducing a teammate who was never there.

If you want a hand turning that into something your team will actually keep, we'll help you write the convention for one repo, with the practical controls in AI workflow controls and the wiring in process automation.