Phoronix's headline says Linus Torvalds is working on a hefty kernel improvement with Claude Code. It says nothing about whether your own AI-assisted patch would get merged. The kernel's rules were written around people, not tools, so what matters is who certifies the patch and who reviews it.
Beyond the headline, nothing about Torvalds's workflow is established, so this article does not describe it.
Does Torvalds using Claude Code mean AI patches are welcome?
Not automatically. A maintainer using a tool on his own work says nothing about how a stranger's patch will be treated, and the headline does not describe any change to contribution policy. Your patch still goes through the same gate as everyone else's: the subsystem maintainer, the mailing-list reviewers, and the tests.
The tool is also not the unit of trust. Reviewers extend trust to a person with a track record, and a newcomer has not built one yet. A patch that looks machine-generated and is poorly understood by its sender will likely meet more scepticism, not less. That is an inference from how kernel review works, not a quoted policy.
Does the Signed-off-by and DCO process allow AI-assisted patches, and who is accountable?
The kernel's submitting-patches document contains the Developer's Certificate of Origin 1.1. When you add a Signed-off-by line, you certify that you wrote the contribution or otherwise have the right to submit it under the applicable open source license. The other clauses cover work based on existing licensed code and work passed on from someone else who certified it. The last one says your submission and sign-off become a permanent public record.
That text never mentions tools, and a person makes the certification under a real name. An AI assistant cannot certify anything, so the human sender is on the hook. If the code turns out to be a licensing problem or a bug, your name is on the sign-off. This is a practical reading of the DCO, not legal advice, and how courts would treat AI-generated contributions remains unsettled.
Mailing-list discussion of guidance for AI coding assistants reportedly includes the idea that tools must never add Signed-off-by lines themselves. That is unconfirmed. Check the current in-tree documentation under Documentation/process/ (look for any file on tool-generated or AI-generated content) and search lore.kernel.org for recent threads. Whether such guidance exists in the tree as of October 2026 is something to verify, not assume.
Does the kernel community expect you to disclose AI tool use?
The general expectation of honesty is clear. Reviewers want to know what they are looking at, and a patch that hides how it was produced damages trust if the truth comes out later. Whether disclosure is formally required, and in what form, is the part to verify.
List discussion has reportedly explored a dedicated trailer tag for AI assistance, alongside existing ones such as Co-developed-by, which the submitting-patches document defines for human co-authors. Whether a specific tag has been finalised, and whether it is mandatory or merely recommended, is unconfirmed. Until you have checked the current documentation, put a plain sentence in the commit message or cover letter saying which tool helped and how. Disclosure costs you almost nothing, and non-disclosure can cost you a lot. This pairs well with see also: linux hot page promotion explained: where amd ibs fits.
What do maintainers care about most?
Correctness comes first. Kernel code runs in a context where a subtle locking mistake, a missed error path or a wrong memory-ordering assumption becomes a crash or a security hole. A plausible-looking patch can hide exactly those mistakes. Reviewers will ask why the code is written the way it is, and "the assistant suggested it" is not an answer.
Review burden comes second. Maintainers read a large volume of mail, and a large patch its author cannot explain wastes their time. Small, focused changes with clear commit messages respect that limit however they were produced. See is gstack worth using? a decision aid and 1-hour trial: the details for additional background.
Licensing comes third. The kernel is under GPL-2.0, with the conventions described in the license rules, and your sign-off asserts you have the right to submit the code. If an assistant reproduces code from a project with an incompatible license, you cannot cleanly make that certification. How often that happens, and how to detect it, is an open question. Treat it as a risk to manage, not one to dismiss.
Which kinds of kernel work are sensible to try with AI help?
Low-risk uses keep you in the driver's seat. You might ask an assistant to explain an unfamiliar function, summarise a call chain, suggest where to look in a crash log, or draft a first pass of a commit message. In each case you verify the output against the source. Catching typos in documentation or rephrasing comments works the same way.
Risky uses are the ones where you cannot judge the result. For a newcomer, that means locking, RCU, memory management, scheduler changes, architecture-specific code and anything security-sensitive. Large refactors that touch many files are also hard for a first-time contributor to defend in review, with or without a tool. A good rule: if you could not explain the change line by line to a maintainer who disagrees with it, do not send it.
Also read: context: fix ea app games on linux: switch proton versions in steam
What should you do before sending an AI-assisted patch?
Work through this list before you run git send-email.
- Understand every line. Be ready to defend each design choice without referring to the tool.
- Build and test on the configuration and hardware you can actually reach, and say plainly what you did and did not test.
- Run
scripts/checkpatch.plon the patch and fix what it reports. Usescripts/get_maintainer.plto find the right recipients. - Check the license. Confirm the code is original enough for you to certify, and that new files carry the proper SPDX identifier.
- Disclose the tool in the commit message or cover letter, following whatever tag convention the current documentation specifies.
- Add your own Signed-off-by only after steps 1 to 5. Never let a tool add it.
- Keep the patch small, and expect to answer review questions personally and promptly.
Where do you verify each concern?
| Concern | Where to check | Still unsettled |
| --- | --- | --- |
| DCO and accountability | submitting-patches | Legal treatment of AI-generated contributions |
| Licensing | license-rules | How to detect copied training material |
| Disclosure | Documentation/process/ in your tree, plus lore.kernel.org threads on AI assistants | Exact tag, and whether it is mandatory |
| Review | Subsystem maintainer notes and the MAINTAINERS file | Whether individual subsystems set stricter rules |
Does Torvalds's use of Claude Code mean the kernel has relaxed its standards?
No. The headline says a tool is in use, not that review, accountability or licensing expectations have changed. Every patch still needs a human who stands behind it, and that human is the one the DCO names.
The better reading is that tools are acceptable as assistants while responsibility stays where it was. Use one if it helps you understand and test code faster, then do the same work you would do without it. If the assistant lets you skip understanding the patch, it is working against you.
