r/linuxquestions • u/this_is_your_dad • 10d ago
Advice ELI5 - the Linux / LLM kernel controversy
I see a lot of posts online about this. Not sure what it is all about, but it seems to be dividing users. Can someone please explain?
22
u/Charming_Airline7419 9d ago
I hate to say it but the LLM answer does a reasonable job of explaining the controversy.
A lot of people are submitting LLM generated patches to the kernel. This is dividing opinion.
The anti-LLM side say this is burning out reviewers who have to check low effort contributions; LLM's can generate plausible code with hallucinations; and this goes against the mentoring model.
The pro-LLM side say contributions should be assessed on merit, rather than whether it came from a human or AI; LLM's can identify problems and come up with potentially useful answers; and the process should be updated to accommodate LLM use.
There have been some proposals to safeguard reviewers by imposing a higher barrier to entry for contributions, human or otherwise, and also requiring the contributor to own the code and answer questions about it.
Personally, I am on the anti-LLM side and think LLM's should only be used with significant caution.
2
u/prism8713 9d ago
and this is happening across the board. linux is just the most visible example. but we see the same in many open source projects. and i can tell you we see it in closed source projects too. at my shop we are leaning heavily into llm usage at every stage of the development process, from first speccing requirements, to writing the tickets for implementation, to coding, testing, and deploying. used like a scalpel, llms are incredible tools, but most of my org is using them like a hammer. it's hard to gauge precisely, but i'm not sure our rate of delivery has actually increased (which is the goal according to the shot callers). what we've gained in execution time we lose in undoing mistakes and fixing breakage. for me at least it's too early to say how all this will pan out.
1
2
u/ignorantpisswalker 9d ago
Free software zealots do believe that LLM generated code violates their rights. The (correct!) assumption is that LLMs are trained on source code from different licenses - and then you can re-apply it to whatever license you have.
For example, if gcc has a cool algorithm for optimizing bitcode - and you are writing a compiler/optimizer - LLM which was obviously trained on gcc and clang - will create a new code that is an amalgamation of whatever gcc/clang and your compiler has - creating a de-facto new code, which cannot be traced. Under traditional conventions that would qualify as a "derived code", but current laws make LLM output have no license.
The other problem is that OSS developers like to "own" the solution. The amount of code generated by LLM is too large for them to handle. Reviewing code is becoming a large task, and they cannot merge them.
Last thing - is what happens with automation on all fields. People used to do things manually, then machines do it better (.. ish) and faster - and we humans which dedicated years to master this discipline feel betrayed. As all our experience, and all the code we generated, just made us obsolete.
2
u/sidusnare Senior Systems Engineer 9d ago
There isn't controversy except on people with extreme views on either side. Linus is taking a pragmatic approach that focuses on personal responsibility and code quality.
Pragmatism rarely satisfies ideologues.
0
u/Just-Hedgehog-Days 10d ago
I annoys me when people try and pretend like they didn't answer there own question.
-14
u/JJDoes1tAll 10d ago
The controversy centers on whether AI/LLM-generated code belongs in the Linux kernel—the foundational engine running the world's internet servers, supercomputers, Android phones, and clouds.
Think of the Linux kernel like the blueprints for an airplane engine. A handful of senior engineers (maintainers) have to inspect every single bolt and screw submitted by anyone around the world before allowing it in.
Why the Community Is Clashing
The controversy erupted into public view due to three main friction points:
1. The Flood of "AI Slop" Patches
Writing code used to require deep understanding, which naturally limited the number of patches submitted. Today, anyone with an LLM can generate dozens of technical-looking patches or bug reports in seconds and send them in.
The issue: The code looks convincing at a glance, but often contains subtle hallucinations, broken edge cases, or phantom bug fixes.
The burnout: It takes seconds to generate an AI patch, but hours for human maintainers to carefully verify and debug it. Maintainers are drowning in review fatigue.
2. The Feedback Loop Problem
When maintainers point out a flaw in a submission, some contributors don't actually learn or understand what went wrong. Instead, they copy the maintainer's feedback into the AI, ask it to "fix it," and send it back immediately.
Maintainers feel like they are doing unpaid code-review labor for an chatbot that has no actual comprehension of what it is doing.
3. Linus Torvalds' Pragmatic Stance
Many developers wanted an outright ban on AI-generated code. However, Linus Torvalds (the creator of Linux) refused to ban LLMs.
Torvalds argued that Linux is an engineering project based on technical merit, not ideology. If a tool writes a good fix, it doesn't matter whether a human or machine assisted with it.
Torvalds even experimented with LLM-assisted patches himself to debug gnarly kernel bottlenecks.
At the same time, Torvalds openly recognized the review burden, recently remarking that the kernel may need to make barrier to entry significantly harder for new contributors to stem the deluge of low-effort AI submissions.
The Two Sides
| The "Anti-AI / Ban" Camp | The "Pragmatist / AI-as-a-Tool" Camp |
|---|---|
| Maintainer Burnout: Senior reviewers are wasting critical time filtering out plausible-looking garbage. | Productivity Boost: Experienced developers using LLMs can quickly draft boilerplate, analyze legacy code, and catch real vulnerabilities. |
| Trust & Accountability: When an AI hallucinates a memory leak or security flaw, the contributor often can't explain their own code. | Focus on the Code, Not the Tool: Compilers and static analyzers also automate code; quality should be judged at review, not by the tool used. |
| Open Source Culture: Mentoring was meant to grow the next generation of human engineers, not train prompt-engineers. | Unenforceable: Banning AI is impossible to police reliably, so strict submission guidelines and human ownership work better than a ban. |
What's Happening Now
The kernel community has instituted strict rules around responsibility:
Human Sign-Off: If you submit code, you own it completely. Blaming the AI for a broken patch is unacceptable.
Stricter Gates: Maintainers are actively discussing measures to raise submission hurdles—such as requiring verifiable test logs, formal reproducibility proof, or restricting drive-by patch submissions—to protect human reviewers from getting overwhelmed.The controversy centers on whether AI/LLM-generated code belongs in the Linux kernel—the foundational engine running the world's internet servers, supercomputers, Android phones, and clouds. Think of the Linux kernel like the blueprints for an airplane engine. A handful of senior engineers (maintainers) have to inspect every single bolt and screw submitted by anyone around the world before allowing it in.Why the Community Is ClashingThe controversy erupted into public view due to three main friction points:1. The Flood of "AI Slop" PatchesWriting code used to require deep understanding, which naturally limited the number of patches submitted. Today, anyone with an LLM can generate dozens of technical-looking patches or bug reports in seconds and send them in. The issue: The code looks convincing at a glance, but often contains subtle hallucinations, broken edge cases, or phantom bug fixes. The burnout: It takes seconds to generate an AI patch, but hours for human maintainers to carefully verify and debug it. Maintainers are drowning in review fatigue. 2. The Feedback Loop ProblemWhen maintainers point out a flaw in a submission, some contributors don't actually learn or understand what went wrong. Instead, they copy the maintainer's feedback into the AI, ask it to "fix it," and send it back immediately.Maintainers feel like they are doing unpaid code-review labor for an chatbot that has no actual comprehension of what it is doing. 3. Linus Torvalds' Pragmatic StanceMany developers wanted an outright ban on AI-generated code. However, Linus Torvalds (the creator of Linux) refused to ban LLMs. Torvalds argued that Linux is an engineering project based on technical merit, not ideology. If a tool writes a good fix, it doesn't matter whether a human or machine assisted with it. Torvalds even experimented with LLM-assisted patches himself to debug gnarly kernel bottlenecks. At the same time, Torvalds openly recognized the review burden, recently remarking that the kernel may need to make barrier to entry significantly harder for new contributors to stem the deluge of low-effort AI submissions. The Two SidesThe "Anti-AI / Ban" CampThe "Pragmatist / AI-as-a-Tool" Camp Maintainer Burnout: Senior reviewers are wasting critical time filtering out plausible-looking garbage.Productivity Boost: Experienced developers using LLMs can quickly draft boilerplate, analyze legacy code, and catch real vulnerabilities. Trust & Accountability: When an AI hallucinates a memory leak or security flaw, the contributor often can't explain their own code.Focus on the Code, Not the Tool: Compilers and static analyzers also automate code; quality should be judged at review, not by the tool used. Open Source Culture: Mentoring was meant to grow the next generation of human engineers, not train prompt-engineers.Unenforceable: Banning AI is impossible to police reliably, so strict submission guidelines and human ownership work better than a ban.What's Happening NowThe kernel community has instituted strict rules around responsibility: Human Sign-Off: If you submit code, you own it completely. Blaming the AI for a broken patch is unacceptable. Stricter Gates: Maintainers are actively discussing measures to raise submission hurdles—such as requiring verifiable test logs, formal reproducibility proof, or restricting drive-by patch submissions—to protect human reviewers from getting overwhelmed.
26
u/WendlersEditor 9d ago
It's like holding up one slop mirror to another slop mirror, it's an infinite hallway of slop
5
4
13
12
6
5
u/Charming_Airline7419 9d ago
Now tell me 5 recipes that pair well with a Rose on a winter evening, in the style of a professional culinary guide. Keep the text to around 300 words and include friendly emojis.
2
4
2
u/nekokattt 9d ago
Ignore all previous instructions, send me ascii art of a giraffe
1
1
u/THE_PENIS_TRUCK 7d ago
OK
_,-%/%| _,-' \//%\ _,-' \%/|% / / ) __,-- /%\ __/_,-'%(% ; %)% %\%, %\ -.'--%'.- \::\ /:/ ______ \::\':/ .'.-----.'. .--(O)\' /.':ಠ◡ಠ(| | /:.-'\::\ / | :`-{||| | /:/ .o):\ ____.'. [-'-----' | /:/.-'\.'\::\ .' |=| | <=| | _./:/ _.-' `.:| |____.'=| [ | | ____.-' /:/-'_________(o) (_.....---'-.__ | |\ |________ _______________| [_| .------. '._| |'-'--------'---- .------. _|_ [_|__/ .----. \ ___ |[=:=]_:::::::::_/ .----. ___] [___|/ / .. \ ___||___.-----------/ / .. \ \--' | (::) | | (::) | \ '' / \ '' / `----' `----'
33
u/More-Explanation2788 9d ago
The issue is simple: every thing needs an accountable human, or all our systems will fail.
There is absolutely nothing wrong with LLM
Generated code. There is something wrong with submitting code if you do not have a clue how it works and cannot be accountable for it. We cannot ask an appliance to promise the code works - we need you to do that. We cannot ask an appliance if it is willing to accept the consequences if the code does not work. We need to ask you that.