Linus Torvalds merged something quietly significant into the Linux kernel tree: an official document titled AI Coding Assistants. It's not a policy debate. It's not a blog post. It's a .rst file sitting in Documentation/process/ right next to coding-style.rst and submitting-patches.rst.
The world's largest open-source project — 30+ million lines of code, thousands of contributors — just formally defined how AI can (and can't) participate in kernel development.
This isn't a niche Linux story. It's a blueprint that every engineering team dealing with AI-assisted code will eventually need.
What the Guidelines Actually Say
The document is short, deliberate, and very Linux. Here's the breakdown:
AI Follows the Same Rules as Humans
AI tools must follow the existing kernel development process. No shortcuts:
- Documentation/process/development-process.rst — how development works
- Documentation/process/coding-style.rst — how code should look
- Documentation/process/submitting-patches.rst — how to submit contributions
AI doesn't get a pass. If your LLM-generated patch doesn't follow kernel coding style, it gets rejected like any other bad patch.
Licensing Is Non-Negotiable
All contributions must comply with GPL-2.0-only. AI-generated code is no exception. If an AI model was trained on proprietary code and reproduces it, that's still a licensing violation. The human submitter owns the legal risk.
Signed-off-by: Humans Only
This is the most important rule in the document:
AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).
The DCO is a legal certification that says "I have the right to submit this code under the kernel's license." An AI can't legally certify anything — it can't hold copyright, it can't enter legal agreements, and it can't take responsibility.
The human submitter is responsible for:
- Reviewing all AI-generated code
- Ensuring licensing compliance
- Adding their own
Signed-off-bytag - Taking full responsibility for the contribution
A New Tag: Assisted-by
The document introduces an attribution convention for AI contributions:
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Example:
Assisted-by: Claude:claude-3-opus coccinelle sparse
This is elegant. It's not mandatory disclosure in a legal sense — it's a tracking mechanism. The kernel community wants to understand how AI is being used over time. The Assisted-by tag creates a paper trail without creating legal ambiguity.
Basic tools (git, gcc, make, editors) don't get listed. Specialized analysis tools (coccinelle, sparse, smatch, clang-tidy) do. This distinction matters — it separates "I used an IDE" from "I used an AI agent to generate this patch."
Why This Matters Beyond Linux
The Linux kernel is often where development culture gets codified first. Coding standards, code review processes, branch management strategies — many of the practices we take for granted in software engineering were either invented or refined in the kernel community.
This AI coding guidelines document is likely to follow the same pattern. Here's why:
1. It Establishes the "Human-in-the-Loop" Principle
The kernel community isn't banning AI. They're not embracing it unconditionally either. The position is: AI can assist, but a human must certify and own the output.
This is the pragmatic middle ground that most organizations will eventually adopt. Full AI autonomy in code contributions creates legal and quality risks. Banning AI entirely creates productivity disadvantages. The kernel found the line.
2. It Creates Attribution as a Social Norm
The Assisted-by tag is a social invention. It lets the community track AI usage patterns without stigmatizing it. Over time, maintainers can see which subsystems benefit most from AI assistance, which models produce the best patches, and where AI-generated code tends to introduce bugs.
This is data that every engineering org should want.
3. It Sidesteps the Copyright Debate Pragmatically
Rather than trying to answer "can AI-generated code be copyrighted?" (a question courts are still fighting over), the kernel says: the human certifies the DCO, and the human is responsible. The AI's role is acknowledged but legally irrelevant.
This is how you ship software while the lawyers argue.
What This Means for Your Team
You don't need to be contributing to the Linux kernel to learn from this. Here's how to apply the same thinking:
For Engineering Leads
- Write down your AI coding policy. If the Linux kernel needs one, your team does too. It doesn't need to be long — the kernel's is ~70 lines of RST.
- Define who's responsible. If an AI generates a bug, a security vulnerability, or a licensing violation, who owns it? (The kernel's answer: the human who signed off.)
- Create attribution norms. Track where AI is being used in your codebase. Not for surveillance — for understanding.
For Individual Developers
- Never blindly submit AI-generated code. The kernel guidelines require human review of all AI output. This is good practice everywhere, not just in kernel contributions.
- Understand the licensing implications. If you're using AI to generate code, you're responsible for ensuring it doesn't reproduce copyrighted material or violate license terms.
- Use AI as a force multiplier, not a replacement. The kernel community's stance implies that AI is most valuable when it handles the tedious parts (finding bugs with static analysis, generating boilerplate, suggesting refactorings) while humans handle the design and review.
For Open-Source Maintainers
- Consider adopting the
Assisted-byconvention. It's a lightweight way to track AI usage in your project without creating heavy compliance burdens. - Clarify your DCO stance on AI contributions. Does your project require human sign-off? Say so explicitly.
The Bigger Picture
The kernel's guidelines are a sign of maturity in the AI-assisted development space. The initial hype phase — "AI will write all our code!" — is fading. What's replacing it is a more nuanced understanding: AI is a powerful tool, but it's a tool that needs rules, accountability, and human oversight.
The fact that Torvalds himself merged this into the mainline tree (rather than it living in some fork or RFC document) signals that the kernel community takes AI contributions seriously enough to regulate them properly.
That's the real lesson. Not "AI is bad" or "AI is great" — but "AI is here, and here's how we handle it responsibly."
Source: Documentation/process/coding-assistants.rst in the Linux kernel tree.
FAQ
Can AI tools contribute code to the Linux kernel?
Yes, but with strict rules. AI-generated contributions must follow the standard kernel development process, comply with GPL-2.0 licensing, and be reviewed and certified by a human who adds a Signed-off-by tag.
What is the Assisted-by tag in Linux kernel commits?
It's an attribution tag that tracks AI involvement in a contribution. Format: Assisted-by: AGENT_NAME:MODEL_VERSION [tools]. It helps the community understand how AI is being used without creating legal obligations for the AI.
Why can't AI add a Signed-off-by tag?
The Signed-off-by tag certifies the Developer Certificate of Origin (DCO) — a legal statement that the contributor has the right to submit the code. AI systems can't hold copyrights, enter legal agreements, or take responsibility, so only humans can sign off.
Should my team adopt similar AI coding guidelines? If the Linux kernel — with its 30M+ lines of code and thousands of contributors — needs explicit AI coding rules, your team probably does too. Start with three things: define human accountability, create attribution norms, and make licensing compliance explicit.
Does this mean the kernel community is pro-AI or anti-AI? Neither extreme. The guidelines are pragmatic: AI is acknowledged as a useful tool, but human responsibility and legal accountability are non-negotiable. It's a balanced stance that most organizations are likely to converge toward.