Attribution in the Age of AI Assistants: What the Linux Kernel's 'Assisted-by' Tag Means for Your Git Workflow

The Linux kernel has formally adopted new Git trailer tags, including 'Assisted-by', to acknowledge AI assistance in patch contributions. The update, pushed through the maintainer chain in mid-2025, requires human accountability for AI-assisted work and is expected to influence CI pipelines, corporate policies, and the definition of authorship in software development.

Originally published on tamiz.pro. When Greg Kroah-Hartman pushed a handful of new trailer keywords into the Linux kernel's Sign-off conventions — including Assisted-by , Inspired-by , Referenced-by , Reviewed-by , and Acked-by variants — most people scrolled past. But for developers who regularly pair with AI, this was a quiet inflection point. The kernel, one of the most process-driven open-source projects in the world, formally acknowledged that AI assistance is now part of the collaborative chain. What happens next in your Git workflow matters more than you might think. In mid-2025, the kernel maintainers updated Documentation/process/submitting-patches.rst and the scripts/get maintainer.pl infrastructure to recognize a new class of trailer tags. Previously, git commit messages could include Reported-by , Tested-by , Reviewed-by , Suggested-by , Acked-by , and Signed-off-by . The new additions fill a gap: | Trailer Tag | Purpose | |---|---| Assisted-by: Name <email | A person or entity provided substantive help in writing, debugging, or shaping the patch including AI tools | Inspired-by: Name <email | The idea came from someone else's work, code, or discussion | Referenced-by: Name <email | Material was cited or quoted from another source | Tested-by: Name <email | Validated on real hardware / in real conditions | The Assisted-by tag is the significant one. It doesn't require disclosure of which tool was used, but it does require human accountability — the tag is placed by a person, not generated autonomously. This mirrors how Reviewed-by and Acked-by already function: they are social contracts, not machine outputs. Linus Torvalds himself didn't champion this. It was pushed through the maintainer chain as a practical acknowledgment that developers were already using AI, and the existing trailers didn't cover the contribution accurately. The decision was pragmatic, not ideological. The Linux kernel isn't just any project — it's the most visible example of a large-scale, high-integrity software effort with rigorous provenance standards. When it adopts a convention, it ripples outward. Here's what changes for your daily workflow: Attribution is no longer optional. If you're using Copilot, Cursor, Claude, or any AI pair-programmer to draft, debug, or refine code, the kernel's decision says: tag it. Not because the law requires it, but because the social contract of collaborative development requires accurate provenance. CI pipelines will adapt. Tools like checkpatch.pl , git-log , and maintainer scripts already parse trailers for filtering and statistics. Assisted-by entries will eventually feed into code intelligence dashboards, blame views, and license/compliance audits. Ignoring them now means retrofitting later. Corporate policies are catching up. Companies with AI-use policies for developers are already updating their contribution guidelines. If you submit patches to external projects or work on internal codebases with review gates, you may be required to disclose AI involvement. The kernel sets a tone that echoes in enterprise repos. The definition of "author" is shifting. Signed-off-by certifies that you vouch for the code. Assisted-by doesn't transfer that responsibility — it just records where help came from. Understanding this distinction is critical for anyone who reviews or lands patches. Here's how to operationalize this without turning your commit history into an attribution registry: When AI materially contributes — not just a one-line suggestion, but a function draft, a refactor, or a debug strategy — add the tag. The format is straightforward: Assisted-by: YourName <you@company.com Or, if you want to note the tool optional, but increasingly common : Assisted-by: Claude Anthropic via Cursor <you@company.com The second form is not yet official kernel policy, but it's the direction the community is moving. Keep it consistent within your team. Assisted-by with Signed-off-by This is the most important distinction. Signed-off-by is your legal and ethical sign-off — you own the code. Assisted-by is attribution for help received. If an AI drafts 80% of a function and you rewrite the remaining 20%, both tags belong in the commit: Assisted-by: Claude Anthropic via Cursor <you@company.com Signed-off-by: You <you@company.com If you blindly accept AI output without review, only Signed-off-by is appropriate — and you should reconsider your workflow. The friction of remembering to add trailers is why most developers won't adopt this voluntarily. Integrate it into your tooling: Assisted-by to commit messages when it generates substantive content. Most modern AI editors support commit message templates. detect.ai or model-based heuristics and injects the trailer automatically. git config --global alias.ai-commit ' f { git diff --cached | ai-summarize | xargs -I{} git commit -m "$1" -m "Assisted-by: AI < "; }; f' If you maintain a team or company repo, update CONTRIBUTING.md or DEVELOPMENT.md to reflect the new convention. A minimal addition: AI Assistance Disclosure When AI tools materially assist in writing or refining code included in a commit, add an Assisted-by: trailer to the commit message. The Signed-off-by: trailer remains the developer's certification of the code. See kernel.org Documentation/process/submitting-patches.rst for the official trailer specification. The kernel's adoption raises several questions that the community hasn't fully resolved: What counts as "assistance"? A prompt that generates a single function is clear. But what about using GitHub Copilot's tab completions, or asking Claude to explain an error message? The kernel's approach — human judgment call — is deliberately vague. Expect friction here. Can you tag an AI directly? The current convention requires a human email address. This prevents spammy auto-attribution but also obscures which tool was used. A future extension may allow Assisted-by: Claude-3.5-Sonnet <ai@anthropic.com as a formal variant. How does this interact with open-source licensing? If AI-assisted code enters a GPL-2.0-only kernel tree, the licensing implications are unchanged — you're signing off on it. But corporate IP policies may differ. Check with your legal team if you're contributing AI-assisted work to external projects. Will git blame surface these tags? Not today. git blame shows author and committer , not trailers. Some tooling like Sourcegraph or kgit-blame variants already surfaces trailer metadata, but this isn't universal. Expect plugins and IDE integrations to add AI-attribution badges in the near term.The Assisted-by tag isn't just about hygiene — it's about building a sustainable model for human-AI collaboration in professional software development. The kernel maintainers made a understated but profound choice: they didn't ban AI, they didn't ignore it, and they didn't treat it as equivalent to human authorship. They created a third category — assistance — that preserves accountability while acknowledging reality. For developers, the practical takeaway is simple: start using Assisted-by now, even if your project doesn't require it. The conventions that feel premature today will be baseline expectations within 18 months. Projects that adopt early will have cleaner histories, better tooling, and fewer compliance surprises. The future of git workflows isn't about choosing between human and AI authorship. It's about accurately mapping the contribution chain — and the kernel just gave us the vocabulary to do it. Q: Do I need to add Assisted-by for every AI interaction, even small ones? No. The convention is for material assistance — when AI meaningfully shapes the code, not just provides a nudge. Use your judgment. If you'd describe the code to someone and mention the AI's role, add the tag. Q: Can I use Assisted-by for AI tools my team doesn't endorse? Yes. The tag is attribution, not endorsement. It records what happened, not what policy says should have happened. If your company has specific AI-use requirements, follow those separately. Q: Will this change how code review works? Not fundamentally, but reviewers should be aware that Assisted-by tags signal AI involvement. This shouldn't change the review criteria — the code is still judged on its merits — but it does mean reviewers should be extra vigilant about understanding why the AI suggested something, especially for complex logic.