The Linux kernel team just stopped asking whether your patch was written by an LLM. But Linus has a very sharp warning for anyone hoping to vibe-code their way into mainline.
If you follow open-source software, you have probably witnessed the collective gasp that echoed across the developer world this month.
Linus Torvalds — the man famously known for dressing down sloppy code on mailing lists and calling the AI industry “90% marketing” just two years ago — has been actively using AI coding assistants to write kernel patches.
Predictably, the internet lost its composure. Comment sections filled with outrage, podcasters declared the Linux kernel was going “full AI slop,” and critics accused Linus of abandoning the principles that kept the world’s most critical operating system running for three decades.
If you felt a twinge of unease when you first saw the headlines, you are certainly not alone. Handing the keys of the global infrastructure to probabilistic autocomplete sounds, on the surface, like an accident waiting to happen.
But before you join the panic, here is the nuance you won’t find in the hot takes: Linus isn’t giving in to the hype. He is drawing a razor-sharp line between using a tool and becoming a nuisance. By the time you finish this short read, you will understand why the kernel maintainers just made a massive rule change regarding AI, and why Linus’s real battle isn’t with language models, but with “drive-by” contributors.
Table of Contents
The New Rule: Stop Telling Us You Used AI
Let’s start with the clearest sign that the tides have officially turned.
At the recent Linux Kernel Maintainers Summit in Prague, kernel developer Sasha Levin announced that maintainers have decided to officially deprecate the Assisted-by tag.
Up until now, kernel etiquette expected contributors to flag whether an AI model helped assemble a patch. That requirement is now gone. You no longer have to announce to the maintainers that Claude or Copilot held the flashlight while you worked on the plumbing.
Why would the strictest codebase on earth do that?
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
Because the maintainers realized something crucial: the origin of the diff doesn’t matter; the quality of the diff does.
As Torvalds explained to veteran tech journalist Steven J. Vaughan-Nichols:
“I think the whole ‘don’t use AI for commit messages’ kind of argument… maybe it’s well-intentioned, but I think it’s entirely misguided. I really think we want competent people to use AI as a tool.”
In other words, the kernel has never cared if you wrote your patch in Vim, Emacs, or on a vintage typewriter. It cares whether your logic breaks memory safety or causes cache line contention. If the patch is rock-solid, nobody cares which text editor or neural network helped you draft the syntax.
The Real Crisis: “Drive-By” Patches
So, if Linus is fine with AI, does that mean anyone can fire up an LLM and “vibe-code” their way into the Linux kernel?
Not a chance. In fact, Linus’s actual stance is the exact opposite.
Linus pointed out that the Linux community is facing two completely independent AI problems right now:
- A firehose of real bugs: AI analyzers are finding legitimate, long-hidden bugs in the kernel codebase, which heaps enormous triage pressure onto an already overworked core team.
- Clueless contributors generating patches: People who don’t understand the underlying C code are having LLMs generate quick patches, and then hurling them over the fence into LKML.
Linus called these out specifically as “drive-by patches”:
“The ‘clueless people using AI’ problem is different. I do think we want to discourage that. Not discourage the people who use AI and truly want to learn and truly want to become useful members of the kernel community — but discourage the drive-by patches, and discourage people who just want to feel like they sent a patch and never really wanted to become anything more.”
Think of the kernel codebase as a busy commercial kitchen. An experienced executive chef using a modern high-speed food processor is a massive productivity win. But someone wandering in from the street, pureeing random ingredients without knowing the recipe, and demanding that the kitchen staff serve it to the dining room is an active hazard.
When AI Actually Delivers in Open Source
To be fair to the technology, AI has already achieved genuine, practical victories inside Linux development.
Back in March, long-time maintainer Greg Kroah-Hartman noted a dramatic turning point: while the project was previously inundated with low-grade AI hallucinations, the tooling suddenly crossed a threshold. Today, automated bug hunters are delivering genuine, verifiable reports across open-source repositories.
Even better, developers are using AI to solve historical headaches that humans simply didn’t have the time to fix.
Take Christian F.K. Schaller, Red Hat’s director of software engineering. While building a driver for an old slide scanner, he created an open-source project called hw-harness. It uses AI to reverse-engineer how proprietary Windows binary drivers interact with hardware, automating the tedious, microscopic work needed to write a native Linux driver. That solves a thirty-year-old thorn in the side of the Linux desktop.
When used by people who grasp the physics of what they are doing, AI isn’t slop. It’s an exoskeleton.
The Inevitable Shift
Whenever a revolutionary tool enters an industry, there is an initial wave of resistance.
The early 19th-century Luddites smashed mechanized textile looms because the machines threatened their way of life. Today, people still weave fabric by hand as an artisan craft, but the modern textile world is overwhelmingly mechanized.
Software engineering is passing through the exact same inflection point right now. As Vaughan-Nichols notes, by 2030, writing every single line of production software strictly “by hand” without machine assistance will likely look as quaint as hand-weaving cloth.
Linus himself hasn’t lost his love for the craft. As he noted at Open Source Summit Europe, “vibe-coding” can be a wonderful gateway drug that brings people into the joy of software creation.
The distinction is simply where that code goes. If you are learning, experimenting, or automating a hobby project, let the model run wild. But when you are touching the foundational operating system of the internet, you have to be ready to own every single byte you submit.
What This Means for You
If you have been wondering how to navigate the AI wave without looking like an amateur, Linus’s advice offers a straightforward blueprint:
- Use the tool, but own the diff. Never submit a single line of code to a repository — open source or at your day job — that you cannot defend, explain, and debug yourself when something catches fire.
- Respect the reviewer’s time. Generating a patch in thirty seconds doesn’t make you a contributor. Taking thirty minutes to verify that your patch doesn’t create collateral damage is what makes you an engineer.
- Don’t hide behind labels. Clean code that works reliably doesn’t need an apology or an
Assisted-bydisclaimer.
Linus Torvalds hasn’t sold out, and the Linux kernel hasn’t turned into a dumpster fire of unverified slop. The rules of the playground remain exactly what they have always been: excellence is the only currency that counts. The tools change, but the standards don’t.
