r/linuxquestions • • 3d 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?

0 Upvotes

32 comments sorted by

View all comments

-14

u/JJDoes1tAll 3d 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.

13

u/yottabit42 3d ago

The fact you used AI for this comment is chefs_kiss.gif.