Linux's kernel now has formal rules for AI-assisted patches. Linus Torvalds and kernel maintainers finalized the policy.

What the policy actually requires

The new policy spells out three plain rules for anyone who uses AI tools when writing kernel code. First: only humans may sign a patch's Developer Certificate of Origin, the DCO that certifies licensing. Second: any use of AI tools must be declared with an Assisted-by tag naming the model, agent and any auxiliary tooling. Third: the human who submits the patch keeps full responsibility for reviewing, testing and ensuring licence compliance.

This isn't a minor tweak — it changes the project's legal and submission process and alters how patches get merged into the tree.

The policy even shows the format to use: Assisted-by: Claude:claude-3-opus coccinelle sparse, which serves as a transparency flag and warns maintainers the patch may need closer checks.

And it's explicit about signatures: AI can't append a Signed-off-by tag. Only a named developer can certify the DCO, because the DCO is the project's legal mechanism for licensing and contributor responsibility.

Why maintainers pushed for rules

The move didn't come from nowhere. The kernel community faced a controversy after a high-profile AI-generated patch submission and earlier attempts to slip problematic code into the tree.

Sure, sasha Levin, an Nvidia engineer and long-time Linux kernel developer, submitted a patch generated by an AI model to Linux 6.15 that included changelog and tests, and he later advocated for formal transparency rules. Levin argued that contributors should disclose AI use rather than hide it — and he took that position in public discussions at the 2025 North America Open Source Summit and in a July 2025 draft proposal.

There was also a 2021 incident, when a pair of University of Minnesota students tried to introduce flawed code. The examples made maintainers nervous and fed the push for clear rules so reviewers know when they need to raise their guard.

How the Assisted-by tag works in practice

The Assisted-by tag is both a label and a review flag. It tells maintainers which model and tools were used, and it lets them decide whether the patch needs particular types of testing or code review. At the end of the day, maintainers decide whether a patch lands.

But the tag doesn't cut your workload — you still have to review, test and defend your changes. If you list an AI model, you're not transferring liability to an external service. You're admitting you used a tool, and you still have to explain and defend the code. You have to run tests. But you have to check licenses for any code the model may have incorporated, and you have to do the final review yourself.

The policy treats AI as a tool — comparable to a static analyzer or refactoring script — not as a co-author, and it keeps the human reviewer responsible.

Mastheads

But it also places a transparency burden on contributors, because openness helps reviewers spot AI-specific issues and patterns.

What this means for contributors and maintainers

For contributors: be upfront. If you use an AI-assisted workflow, add the Assisted-by tag and be prepared to show your work. If you don't, and you try to sneak code in, you're likely to face community backlash and risk burning bridges with maintainers.

For maintainers: the tag gives them a cue. Maintainers may choose to apply extra checks or ask for more extensive testing. They may also pay closer attention to patterns of similar mistakes that can emerge when code is generated by the same model or pipeline.

Linus Torvalds, the Linux creator and lead maintainer, and the collective of kernel maintainers formalized the policy after months of debate. Their approach favours a balanced, practical stance: accept modern developer tools, but keep human review and legal responsibility front and centre.

Potential trouble spots and open questions

There are still things the policy leaves to the community to resolve.

How strictly will maintainers enforce Assisted-by declarations? What range of tools counts as "AI-assisted" — a code suggestion inside an editor, a full patch drafted by a model, or both?

Expect those debates to play out on the LKML and in individual patch review threads, where maintainers set local norms. The policy gives a framework, but the community still needs to work out norms and enforcement practices in day-to-day review.

Also, legal and licensing worries remain front of mind. If a model reproduces licensed code, who's responsible for the licensing problem? The policy's answer is blunt: the human who signs the DCO remains responsible.

Why the kernel's stance matters

The Linux kernel is the largest open-source project for critical, low-level code. Its decisions ripple outward. Because the kernel is so central, its rules on human accountability and Assisted-by attribution will probably shape policies in other open-source projects.

That's not automatic. Other projects may choose looser or stricter rules. But the kernel's combination of transparency (the Assisted-by tag) and human liability (you sign the DCO) sets a clear standard: AI can help, but people must own the result.

If you want to contribute seriously to the kernel, you'll need to learn how to document AI help and run stricter tests. They'll need to learn how to document AI assistance, run better tests, and scrutinize any third-party code fragments the model might have suggested.

Practical steps for developers today

If you're a kernel contributor, start by updating your workflow. Keep detailed notes on AI prompts, model versions and any preprocessing you did. Include that information in your Assisted-by line. Run the kernel's usual test suites and consider adding extra static analysis focused on common AI-generation errors.

Plan to defend your changes in review threads; expect maintainers to ask detailed questions about any AI assistance. questions about why you used a model, what prompts you gave, and how you verified the output. The community will treat AI-assisted patches like anything else — judged on technical merit, clarity and testability.

Finally, be mindful of licensing: the policy makes clear that you, the submitter, are on the hook for any licensing issues introduced by the patch. That means if a model hallucinated copyrighted code fragments, the legal responsibility sits with the human who signed the DCO.

Related Articles

The policy requires an Assisted-by tag naming the model and tools—example: "Assisted-by: Claude:claude-3-opus coccinelle sparse."

This article was created with AI assistance.