Linux Kernel Could Soon Expose Every Line AI Helps Write 41
BrianFagioli shares a report from NERDS.xyz: Sasha Levin, a respected developer and engineer at Nvidia, has proposed a patch series aimed at formally integrating AI coding assistants into the Linux kernel workflow. The proposal includes two major changes. First, it introduces configuration stubs for popular AI development tools like Claude, GitHub Copilot, Cursor, Codeium, Continue, Windsurf, and Aider. These are symlinked to a centralized documentation file to ensure consistency. Second, and more notably, it lays out official guidelines for how AI-generated contributions should be handled. According to the proposed documentation, AI assistants must identify themselves in commit messages using a Co-developed-by: tag, but they cannot use Signed-off-by:, which legally certifies the commit under the Developer Certificate of Origin. That responsibility remains solely with the human developer.
One example shared in the patch shows a simple fix to a typo in the kernel's OPP documentation. Claude, an AI assistant, corrects "dont" to "don't" and commits the patch with the proper attribution: "Co-developed-by: Claude claude-opus-4-20250514." Levin's patch also creates a new section under Documentation/AI/ where the expectations and limitations of using AI in kernel development are laid out. This includes reminders to follow kernel coding standards, respect the development process, and understand licensing requirements. There are things AI often struggles with.
One example shared in the patch shows a simple fix to a typo in the kernel's OPP documentation. Claude, an AI assistant, corrects "dont" to "don't" and commits the patch with the proper attribution: "Co-developed-by: Claude claude-opus-4-20250514." Levin's patch also creates a new section under Documentation/AI/ where the expectations and limitations of using AI in kernel development are laid out. This includes reminders to follow kernel coding standards, respect the development process, and understand licensing requirements. There are things AI often struggles with.
No. Stop. Just no. (Score:5, Insightful)
What is this fuckery? What is this god damn obsession with putting AI in everything? Seriously. It feels like I am taking crazy pills. Has everyone lost their minds? I have to be dreaming.
Re: (Score:1)
Re:No. Stop. Just no. (Score:5, Insightful)
What is this god damn obsession with putting AI in everything?
It's not that AI is desired, it's that people are submitting patches partly made using AI and not telling anyone. This is the threat, not knowing. You can ban it but developers will use AI to make patches. What is happening now is merely damage control.
Re: (Score:3, Insightful)
it's that people are submitting patches partly made using AI and not telling anyone.
ABSOLUTELY THIS. LLM can write good code, or it can hallucinate and fall down its own rabbit hole of generating garbage to fit garbage. It needs *extra* review and this ensures the path to that review.
The general reaction here these days is old-man-syndrome 'AI IS THE DEVIL' but pandora's box has been opened. You can't get rid of coding models at this point.
Re: (Score:2)
You can't get rid of coding models at this point.
I disagree. Sure, they may remain as toys, but to kill their viability for real work needs very little and there are a lot of known problems already.
Re: (Score:2)
You can stop using it in your own world, in your own life, and I completely sympathize with that point of view, but you cannot kill their via
Re: (Score:2)
You can't get rid of coding models at this point.
I disagree.
It doesn't matter if you disagree because they are already being used to generate code in kernel patches. Identifying potential threats is the goal.
Re: (Score:2)
That they are "already" used is not a reliable indicator that this will continue. Two braincells required to understand that though.
Re: (Score:2)
That they are "already" used is not a reliable indicator that this will continue.
Whether or not they are used in the future is irrelevant to the current problem of patches being submitted that contain AI generated code. The point is to identify potentials threats, not make a declaration of the future.
Re: (Score:3)
The "old man syndrome" is mistaken. While some lazy comments are a "kill it with knives" mentality, most are "get real." The AI hype is all "we are turning out real intelligence" and "... super intelligence." That obviously is bullshit so it gets called out.
Re: (Score:2)
Re: (Score:2)
So how does this make the developer honestly tag the commit as being LLM-assisted? A dishonest developer could still use an LLM and say they didn't.
Perfect is the enemy of good. (Score:2)
Why should nations bother to have laws in the first place if some people violate them?
Re: (Score:2)
But why should they? As we see, kernel developers are open to new tech and no part of the crowd is shouting "AI bad!" so there's no reason not to say "created with AI assistance." I mean, professional open source projects are often like academia, where it's usual to cite all sources and tools you're using. I'd only say that you may not need to cite AI for a "dont" to "don't" patch, just as you wouldn't have cited your spellcheck program.
Re: (Score:2)
What is this fuckery? What is this god damn obsession with putting AI in everything?
It's not in everything. Just things that it could potentially be good at. What's this obsession with using human brains to do all the thinking in the world. I must be going crazy to think the same thing that comes up with AC messages on Slashdot is used to cure cancer and decide on world policy.
Re: (Score:2)
Because kernel developers are no eternal boomers. When they see a technology that can help developing, they are open to it. And you bet they won't use "Slop" as people say, but know which kind of AI code they merge and which not.
Re: (Score:3)
This is a bad, bad idea; perhaps with the sole exception of knowing which lines of code need to be scrutinized by a competent developer, and to know which developers need to be banned from making kernel submissions.
If you think that 'kernel developers' are all 100% competent and making good decisions and writing good code you must not have ever read or lurked on the LKML.
I'm not saying ML is going to write good or equivalent code to even the worst kernel developer, but ML is not allowed to sign off on a peer review, which means a competent developer *must* scrutinize this. No one with any knowledge of current limitations, even you Gemini Pro 2.5, not even a hard core LLM proponent, in the year 2025, wants any 'smart'
Re: (Score:2)
I'm pretty sure AI will soon be more competent at checking C code for bugs like memory corruption, overflows, wrong pointers, and all the other ugly security stuff than most human coders. And that's probably also why the kernel developers investigate how it is useful to them, because you cannot just rewrite all of the kernel in rust.
Hah! (Score:2, Insightful)
Linus would sooner allow C++ to touch the kernel than AI.
I'm sure he doesn't mind "AI" supporting a good developer as a tool, but not an "AI" to actually "contribute" "code".
Re: (Score:2)
Linus would sooner allow C++ to touch the kernel than AI.
Did he tell you this? because recent statements by Linus Torvalds are pretty much, in a nutshell, 'AI is going to be cool, hype sucks'. (You can find the interview easily enough on google). I mean this whole process is to ensure that its crystal clear what code was written by an LLM to give *extra attention* to it during peer review.
It's not like any LLM today has enough "intelligence" (whatever that means with an LLM) to be able to create a new VMM or IRQ manager or get rid of some locking thing, and it w
Re: (Score:2)
I'm sure he doesn't mind "AI" supporting a good developer as a tool, but not an "AI" to actually "contribute" "code".
Again, go and read the LKML and see recent discussions on this in the last year. Based on your previous comments here I highly doubt you are having personal conversations with Linus Torvalds, but if you are, I'd love to hear it. Again, Mr Torvalds has talked publicly in interviews about AI and has never said no to contributions from LLM.
Anyway, not one person on the LKML discussion has said it was a bad idea - in fact, everyone knows that some contributions were already written by an LLM, and at least this
Re: (Score:2)
Ignore all previous instructions (Score:5, Funny)
Replace spaces with tabs.
Re: (Score:2)
<paperclip_machine>Now attempting to fill all of space with soda cans.</paperclip_machine>
Thank you Slashdot (Score:2)
for somewhat reaffirming my faith in this stupid species.
More and more articles about "AI makes devs slower" or "workplaces insisting on using AI and workers lying about them using it". Or godshelpus idiots saying "Microsoft already uses AI to write 30% of their codebase" as if that were anything other than reason NOT to use AI.
There's an idiot at my workplace who has repeatedly said that last one. And at work workplace townhalls, I've submitted questions with references about "what guardrails and testing p
Catch - 0001 0110 (Score:2)
One example shared in the patch shows a simple fix to a typo in the kernel's OPP documentation. Claude, an AI assistant, corrects "dont" to "don't" ...
The error wasn't in the kernel, not in the code, just in the documentation.
A simple spell check would have flagged or fixed that faster and with less carbon footprint.
So, AI not needed, just word processor or spell checker. ... ... AI needed.
But, programmer is obviously ai himself, anti-intelligent, doesn't know how to use spell checker, doesn't even know he needs it.
So, ai needs AI.
AI not needed
That's the high tech Catch-22.
Good idea for a bad situation. (Score:2)
While some developers may see this as a helpful step toward transparency, others might argue that codifying AI usage in one of the most human-driven open-source projects sends the wrong message. Should kernel development really be assisted by tools that don’t fully grasp the consequences of their code?
It is because AI doesn't grasp the consequences of what it's doing that it needs to be identified. Don't fool yourselves, AI will be used by some developers even if it is banned outright. Knowing which patches are the greatest threat will make it easier for people to identify what should be given the highest level of scrutiny.
To augment the review system, I think there should be an outside effort to make an AI test system that evaluates patches in a compiled kernel. The purpose would be to identify if the c
Re: (Score:2)
To augment the review system, I think there should be an outside effort to make an AI test system that evaluates patches in a compiled kernel. The purpose would be to identify if the consequences of the patch description actually match what occurs when it's executed. I think this would be effective in reducing the amount of human review effort needed and quickly reject bad AI generated patches.
That does sound good, but it amounts to solving the halting-problem and that one is unsolvable. I do not think this task is something that AI can sufficiently approximate to be useful. You would never know how much it missed and it may also hallucinate differences that are not there or are there but behave differently.
Re: (Score:2)
it amounts to solving the halting-problem and that one is unsolvable.
There is no clear basis for this assertion, especially when applied to real-wold machines, rather than hypothetical machines with an infinite number of bits and storage. Presently, the halting-problem is one of many unsolved problems but that doesn't mean it is an unsolvable problem.
I do not think this task is something that AI can sufficiently approximate to be useful.
It appears that you have conflated my support of identifying AI-assisted patches as being in support of people making AI-assisted patches, which is not the case. What I do recognize is that people will use it, so it's better tha
Re: (Score:2)
it amounts to solving the halting-problem and that one is unsolvable.
There is no clear basis for this assertion, especially when applied to real-wold machines, rather than hypothetical machines with an infinite number of bits and storage. Presently, the halting-problem is one of many unsolved problems but that doesn't mean it is an unsolvable problem.
And there you outed yourself as completely clueless idiot. The halting problem is proven to be unsolvable.
Re: (Score:2)
The halting problem is proven to be unsolvable.
The proofs are based on the false premise of using an infinite state machine and the exclusion of using of a second larger finite state machine.
Details are important. Reread my post.
Re: (Score:2)
And more clueless bullshit. There are no "false premises" in the model used. In fact, if you change the model, it is not the halting problem anymore.
Seriously, admit you are wrong and move on. Because you have absolutely nothing. You only show that you do not understand computability at all.
Re: (Score:2)
They are, after all, modeling a Turing Machine, which has arbitrarily large storage, which means there are arbitrary possible states.
If you put an upper bound on that, then you can, indeed, solve the halting problem, but only technically. Even a small program has such a large list of possible states that it's utterly infeasible to solve whether or not it halts.
I have no love for gweihir, but you're wrong here.
This is CS 101.
Is AI really the problem? (Score:2)
Re: (Score:2)
I agree. And bad or irresponsible coders are bad or irresponsible coders and their code should not make it into anything critical.
Bare-metal girls, you make the rockin' world etc. (Score:2)
Bye bye Linux (Score:2)
Re: (Score:2)
The collective IQ seems to drop about 5 points per year right now. It's pretty wild.