Linux Kernel AI Coding Rules: Attribution, Sign-Off and Review

The Linux kernel accepts tool-assisted contributions under its existing development and licensing requirements, with additional expectations for transparency. Using AI does not transfer responsibility for a patch away from the person submitting it, and it does not guarantee acceptance.

Consult the current kernel documentation and the target subsystem's requirements before submitting. The attribution format has changed between documentation versions, so an older example may no longer match the current guidance.

AI assistance and human sign-off are different

The AI Coding Assistants documentation says AI agents must not add Signed-off-by tags. The human contributor reviews the work, checks licensing and adds their own certification under the Developer Certificate of Origin (DCO).

A sign-off is not a promise that code contains no possible bugs. It certifies the contribution under the DCO's terms; read those terms before signing. Do not substitute an AI product name for the responsible person.

The current unversioned AI-assistant documentation gives this attribution format:

Assisted-by: LLM [TOOL1] [TOOL2]

The bracketed items represent optional specialized analysis tools; they are not literal text to include. Ordinary tools such as an editor, Git or a compiler are not listed there. The documented example is:

Assisted-by: LLM coccinelle sparse

Use that example only if those tools were actually involved. Older versioned documentation uses an agent-and-model format, so follow the guidance relevant to your submission rather than copying a historical tag.

What assistance should be disclosed?

The guidelines for tool-generated content distinguish meaningful generated contributions from trivial assistance. Generated functions, substantial code later edited by hand, and generated or translated changelogs are covered. Basic completion, spelling fixes, formatting and purely mechanical renaming are examples generally outside that scope.

Describe the affected portions and how the tool helped. If a short prompt produced much of the change, include it; for a longer interaction, summarize the assistance. Explain how the result was tested. When uncertain, provide enough information for reviewers to understand the contribution's origin.

A maintainer may ask for further explanation or testing, apply additional scrutiny, or decline the patch. Disclosure is useful context, not a substitute for understanding the submitted work.

Review the patch as a complete contribution

Follow the kernel patch-submission guide, including any subsystem-specific process. Explain the user-visible problem, keep each patch focused and describe why the proposed change addresses it.

• Review the diff for unintended changes and compatibility effects.
• Provide evidence for performance claims instead of repeating a model's estimate.
• Check style and explain any remaining exceptions.
• Identify the appropriate maintainers and lists rather than sending the patch indiscriminately.
• Document the tests actually performed and any limitations.

For a suspected bug, distinguish a plausible explanation from a demonstrated failure. An AI-generated assertion alone should not be presented as a confirmed vulnerability. Use the kernel's security-reporting procedure where applicable.

Choosing a coding tool does not change the rules

The same responsibility applies whether an assistant runs in an editor, a terminal or a web chat. This comparison of AI coding assistants explains different workflows; contributors still need to understand the resulting code.

For background on the project, see Linus Torvalds and the origins of Linux. For contribution decisions, rely on the current kernel documentation rather than commentary about individual developers or predictions about AI's future.