Linus Torvalds, Linux, and AI: Pragmatism Over Fear

Linus Torvalds has just clarified his position on the use of artificial intelligence in Linux kernel development. As is often the case with him, the message is blunt: Linux will not become a project that's anti-AI on principle.

People who categorically refuse to use these tools are free not to use them. They can also leave the project or create their own fork. What they can't do, however, is impose that refusal on the entire community.

Behind the provocative soundbite picked up by several outlets, his actual position is far more interesting and much more nuanced.

Linux is not an anti-AI project

Linus Torvalds isn't claiming that AI is perfect. He acknowledges that it can produce bad bug reports, mediocre code, and a significant amount of extra noise for maintainers to deal with.

But he now sees it as a genuine development tool.

Not that long ago, Torvalds was far more skeptical. Back in 2024, he felt that much of the discourse around AI was mostly marketing hype. Today, his view has shifted: these tools are useful, even if they remain imperfect and sometimes a pain to manage.

His position ultimately boils down to one simple idea: a contribution should be judged on its technical merit, not on anyone's personal feelings about AI.

And on that point, I think he's right.

He sets the direction for the project he created

Linux today is a massive collaborative project. Thousands of developers, maintainers, and companies contribute to the kernel.

So it wouldn't be accurate to describe Linux as Linus Torvalds' personal property. But he remains its creator and lead maintainer. His role is precisely to make the final calls and set the overall technical direction of the project.

When he says Linux won't turn into an anti-AI project, he's owning that responsibility.

You're free to disagree with his stance. That's also the whole point of open source: the code can be studied, modified, and forked. But you can't demand that the main project adopt an ideological line that contradicts the one set by its maintainer.

Open source isn't the absence of direction. It also rests on clearly owned responsibilities.

Sooner or later, AI will be part of Linux development

In my view, the debate isn't really about whether AI will be used to develop Linux anymore.

It probably already is, directly or indirectly, for analyzing code, hunting down regressions, drafting reports, reviewing patches, or spotting certain anomalies.

The real question is how far its use will be allowed to go, and under what conditions.

AI isn't suddenly going to replace kernel maintainers. But it could gradually take on a bigger role in several areas:

• static code analysis

• vulnerability detection

• regression identification

• generating or improving tests

• preliminary patch review

• searching through commit history

• analyzing complex interactions between different subsystems

It would be pretty surprising for the Linux project to permanently pass up these capabilities, given that the kernel contains tens of millions of lines of code and is constantly evolving.

Torvalds seems to have grasped this: ignoring these tools won't make them go away. It's better to learn to use them properly and set rules solid enough to keep them from becoming yet another burden.

But Linux isn't just any project

That openness to AI still needs to come with a healthy dose of caution. Linux is everywhere.

You'll find it in servers, cloud infrastructure, Android smartphones, routers, connected devices, supercomputers, industrial systems, networking equipment, and countless critical systems.

A bug in an ordinary app might affect a handful of users. A bug in the Linux kernel can have far-reaching consequences.

That's exactly why using AI in such a sensitive project can't follow the logic of "vibe coding," where code gets accepted simply because it looks like it works.

A model can generate a change that's convincing, well-structured, and perfectly plausible while still introducing a flaw that's hard to catch. It might also misread some long-standing behavior, overlook a rare hardware constraint, or offer a fix that works on one architecture but causes a regression on another.

With the Linux kernel, plausible-looking code just isn't enough. It has to be understood, tested, reviewed, and someone has to take responsibility for it.

Humans must remain accountable

This is probably the most important point of all.

It doesn't matter whether a patch was written entirely by hand, suggested by an AI, or produced with the help of several tools: the person submitting it has to remain accountable for its content.

AI can't become an excuse.

A developer should never be able to respond to a regression or a vulnerability with, "I don't know, the model wrote that."

Whoever signs off on a contribution needs to be able to explain it, defend it, and fix it if necessary.

This also means maintainers need tools to flag questionable contributions, strengthen testing, and confirm that AI is actually cutting down their workload rather than just shifting it over to the review stage.

Torvalds himself says as much: the goal should be making sure tools built on large language models help maintainers, instead of dumping extra artificial work on them.

Neither blanket rejection nor blind trust

I understand the concerns coming from part of the open-source community.

Auto-generated reports, opportunistic contributions, and code submitted without ever really being understood can wear maintainers down fast. It's a real problem, and it shouldn't be brushed aside.

But rejecting any use of AI on principle doesn't strike me as the right answer either.

On the flip side, blindly accepting code just because a model churned it out quickly would be just as dangerous.

The most sensible position lies somewhere in between: use AI as a tool, without handing it the technical responsibility.

That, in the end, is the core of Linus Torvalds' message.

Artificial intelligence is neither an authority nor an enemy. It's just another tool. It can catch mistakes, but it can also create them. It can save time, but it can also waste a huge amount of it.

In a project as central as Linux, its adoption strikes me as inevitable. But it will need to happen under a stricter standard than anywhere else.

Because Linux is everywhere, and when the kernel gets it wrong, the fallout goes way beyond the workstation of the developer who submitted the commit.