Rules for AI code in the Linux kernel: What do programmers need to know?
The official Linux kernel has issued guidelines for AI-rich code. Learn about three key principles and the responsibilities of programmers when using AI.
After months of intense debate, Linus Torvalds and the Linux kernel maintainers have officially released the first set of rules regarding the use of AI in source code contributions.
This policy reflects Torvalds' familiar pragmatic approach: embracing AI as a useful tool, but still maintaining extremely rigorous kernel quality standards.
The core principles when using AI to write code.
The new regulations revolve around three key principles that every programmer needs to understand.
First of all, AI is not allowed to sign code. In the Linux ecosystem, the 'Signed-off-by' tag is a legal commitment related to the license and source code origin (DCO – Developer Certificate of Origin). This means that even if the code is 100% written by AI, the submitter is still credited and fully responsible.
Secondly, all code that uses AI must be declared. Programmers need to add an 'Assisted-by' tag, clearly stating which model, agent, or tool was used. This is not intended to negatively 'label' the process, but rather to increase transparency and support the review process.
Ultimately, the responsibility lies with the human. The person submitting the patch must thoroughly check the code, ensuring it doesn't violate copyright and that there are no bugs or security vulnerabilities. If a problem occurs, the AI is not responsible — you are.
AI is just a tool, not a co-author.
One notable point is that the Linux kernel does not consider AI as a 'co-author,' but merely as a supporting tool.
Initially, the community debated whether to use tags like 'Generated-by' or 'Co-developed-by'. However, they ultimately chose 'Assisted-by' to accurately reflect the role of AI: assisting, rather than creating independently.
This decision also stems from the fact that most AI currently is used for tasks such as code suggestion, refactoring, or test creation, rather than completely replacing programmers.
Furthermore, according to Greg Kroah-Hartman, a maintainer of the Linux stable kernel, the quality of AI tools has improved significantly, to the point where they can generate truly useful security reports, rather than the 'illusory' ones of the past.
Lessons from community debate
This policy did not emerge randomly, but was forged from real-world controversies.
A prime example is when Nvidia engineer Sasha Levin submitted a patch entirely created by AI (including changelogs and tests) without notifying reviewers. Although he did review the code, the lack of transparency provoked a strong backlash within the community.
It is precisely from incidents like these that the Linux community realizes the need for clear regulations to avoid future risks.
Interestingly, the Linux kernel doesn't rely on AI detection tools for code quality control. Instead, it still trusts traditional methods: technical expertise, pattern recognition, and manual review.
The reason is simple. Junk code is easy to spot. But the most dangerous are pieces of code that look reasonable, compileable, and styled correctly, but contain subtle bugs or make long-term maintenance difficult.
This is where AI is currently limited — and also why humans cannot be replaced in the review process.
Transparency is more important than absolute control.
The new policy is not aimed at catching every violation, but rather focuses on creating consequences significant enough to deter dishonest behavior.
In the Linux community, submitting poor-quality or fraudulent code can permanently damage your reputation. And those who have been criticized by Torvalds understand just how serious that is.
The official introduction of AI regulations by the Linux kernel is a significant milestone. It demonstrates that AI has become an integral part of software development, but also clearly affirms that AI does not replace the responsibilities of programmers.
In the open-source world, transparency, accountability, and quality remain top priorities—no matter how much the tools change.