Linus Torvalds Is Right: AI Coding Tools Aren't a Moral Crisis

I’ve been building PCs since middle school, back when you had to manually set jumpers on your motherboard just to get the thing to POST. If you spend enough time in the hardware weeds, you develop a healthy distrust of "magic" solutions. You learn that if a tool promises to do the heavy lifting for you, it’s usually hiding a trade-off under the hood.

That’s why the current panic over AI in the Linux kernel—the idea that it’s somehow "polluting" the purity of development—feels like the same old moralizing I’ve heard for years. Everyone is worried about the "soul" of the code. Meanwhile, I’m over here wondering if these tools can actually write a functional C function without nuking my memory allocation.

Recently, Linus Torvalds cut through the noise, effectively telling the community that AI is just another tool, not a moral crisis. The maintainer’s job is to protect the project, not the "purity" of the input. I wanted to see if he was right, so I put two of the heavy hitters—GitHub Copilot and Cursor—to the test against the Linux kernel coding style.

The "Cursor vs. Copilot" Showdown

If you’re a developer, you know the vibe: Copilot is the ubiquitous sidekick, integrated into VS Code like it’s always been there. It’s reliable, predictable, and occasionally frustratingly conservative. Cursor, on the other hand, is the new kid on the block—an IDE fork that bakes AI into the foundation of the editor, allowing it to index your entire codebase and "understand" context in a way that feels borderline clairvoyant.

When I pointed both at a task involving a custom kernel driver prototype, the differences were immediate.

Copilot acted like a decent junior dev who’s read the documentation but hasn't actually done the work. It suggested standard, boiler-plate-heavy C code that was syntactically correct but structurally uninspired. It was boring, which, frankly, is exactly what you want when you’re building a kernel. It’s the "boring-but-reliable" choice for a reason.

Cursor, however, was aggressive. Because it could "see" the surrounding headers and the specific way my struct members were laid out, it suggested far more idiomatic, context-aware patches. But that agility came with a cost: it occasionally hallucinated a function call that didn't exist in the current kernel version. It looked confident, but if I had just hit "Tab" and moved on, I would’ve spent the next hour chasing a compile error.

Why the Kernel’s "Filter" Matters

The anxiety surrounding these tools often boils down to a fear that the kernel will be flooded with AI-generated, bug-riddled garbage. And honestly? Yeah, the volume of noise might go up. But the maintainer hierarchy isn't a suggestion; it’s a meat grinder.

Whether a patch was generated by an LLM or typed by a human at 3:00 AM, it has to pass the same review process. The "human touch" in kernel development isn't about how the code was typed—it’s about the architectural oversight required to keep a monolith of this scale from collapsing.

When I tested these tools against the kernel’s specific needs, I found that AI is actually better at the tedious, low-level stuff than humans. I tasked both tools with writing a repetitive, switch-case-heavy error handling block. They nailed it. They didn't get bored, they didn't miss a bracket, and they followed the kernel's strictly defined indentation rules perfectly.

The Verdict: It’s Just a Text Editor Plugin

If you’re looking for a "game-changing" AI that will write your kernel modules for you, you’re going to be disappointed. Or worse, you’re going to be banned from the mailing list.

The reality is that AI tools are currently "mid" at high-level architectural decision-making. They struggle with the long-term, social, and structural complexities that Torvalds and his lieutenants manage daily. But for the repetitive, soul-crushing boilerplate that usually makes up the bulk of a driver update? They’re phenomenal time-savers.

The "moral crisis" is a distraction. The real challenge for the kernel maintainers is the same as it’s always been: ensuring the person sending the patch has done the work to verify it. Whether that person used a mechanical keyboard, a touchscreen, or an AI assistant is entirely secondary to whether the code holds up under stress.

My advice? Use the tools, but don't outsource your brain. If you’re not willing to look at the diff and understand exactly why the AI made a specific change, you don't belong in the kernel tree anyway. Treat AI like a new, slightly unreliable tool in your shed. Keep it for the repetitive tasks, double-check its math, and for heaven's sake, keep your eyes on the compiler output. The kernel’s been around for 30 years because it prioritizes what works over what's shiny. That hasn't changed.