xref: /linux/Documentation/process/coding-assistants.rst (revision 1200d84f4c0a929a0780180d25063d93773be79c)
1.. SPDX-License-Identifier: GPL-2.0
2
3.. _coding_assistants:
4
5AI Coding Assistants
6++++++++++++++++++++
7
8This document provides guidance for AI tools and developers using AI
9assistance when contributing to the Linux kernel.
10
11AI tools helping with Linux kernel development should follow the standard
12kernel development process:
13
14* Documentation/process/development-process.rst
15* Documentation/process/coding-style.rst
16* Documentation/process/submitting-patches.rst
17
18Licensing and Legal Requirements
19================================
20
21All contributions must comply with the kernel's licensing requirements:
22
23* All code must be compatible with GPL-2.0-only
24* Use appropriate SPDX license identifiers
25* See Documentation/process/license-rules.rst for details
26
27Signed-off-by and Developer Certificate of Origin
28=================================================
29
30AI agents MUST NOT add Signed-off-by tags. Only humans can legally
31certify the Developer Certificate of Origin (DCO). The human submitter
32is responsible for:
33
34* Reviewing all AI-generated code
35* Ensuring compliance with licensing requirements
36* Adding their own Signed-off-by tag to certify the DCO
37* Taking full responsibility for the contribution
38
39Attribution
40===========
41
42When AI tools contribute to kernel development, proper attribution
43helps track the evolving role of AI in the development process.
44Contributions should include an Assisted-by tag in the following format::
45
46  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
47
48Where:
49
50* ``AGENT_NAME`` is the name of the AI tool or framework
51* ``MODEL_VERSION`` is the specific model version used
52* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
53  (e.g., coccinelle, sparse, smatch, clang-tidy)
54
55Basic development tools (git, gcc, make, editors) should not be listed.
56
57Example::
58
59  Assisted-by: Claude:claude-3-opus coccinelle sparse
60
61Procedure for finding and fixing bugs
62=====================================
63
64When an AI assistant is used to find and fix bugs, it **MUST** follow at least
65these steps:
66
671. Before starting, read the whole process documentation listed above, as well
68   as any other document mentioned in the request. Do not rely on isolated
69   parts found by keyword search.
702. Note the commit ID and Locate a bug as instructed.
713. For any bug found that is not trivial, verify that it looks real by
72   attempting to create a reproducer to demonstrate it. Lacking it may cause
73   the report to be ignored, as many unverified bug reports sent to maintainers
74   happen to be invalid. Stop here if it finally looks wrong.
754. Write a fix for the bug. This part is not optional: except in a few very
76   rare cases, an AI assistant able to find a bug is able to fix it. Note that
77   fixes written in the same session as used to find the bug will generally
78   lead to better and more accurate fixes as the LLM's reasoning context
79   remains present.
805. Build and verify that the fix works either using the reproducer or by
81   re-running a complete analysis; drop any fix that doesn't work and try
82   another one. The fix must not add build warnings and must pass the
83   checkpatch.pl checks (see submitting-patches.rst).
846. Commit the working fix with a detailed message describing the problem, the
85   solution and a Fixes tag. Do not add a Signed-off-by tag, and add an
86   Assisted-by tag, as described above.
877. Identify the maintainers and lists using scripts/get_maintainer.pl.
88   Documentation/process/security-bugs.rst shows how to do that.
898. Indicate what could not be done. If the fix could not be built or tested, or
90   if no reproducer could be produced, say so explicitly: maintainers currently
91   waste too much time analyzing unverified reports and untested fixes.
929. Read Documentation/process/threat-model.rst to determine whether the bug is
93   a vulnerability or a regular bug, and leave the result to the reporter for
94   review (the assistant must never send anything itself). Regular bugs are
95   submitted as described in Documentation/process/submitting-patches.rst,
96   vulnerabilities as described in Documentation/process/security-bugs.rst.
97