Fork It or Use It: Linus Torvalds on AI

We have become very good at turning tools into ideologies.

AI discussions collapse almost instantly into camps — "pro-AI" and "anti-AI," believers and resisters, revolution and threat. You're expected to pick a side before you're allowed an opinion. Engineering problems rarely benefit from that framing. And this summer, the most demanding software project on Earth showed what the alternative looks like.

What happened on the kernel list

Since March, an agentic review system called Sashiko — built by Google engineer Roman Gushchin — has been reviewing every patch sent to the Linux kernel mailing lists. In benchmarks against 1,000 recent upstream commits that later needed fixes, it caught roughly 53% of the bugs. Unimpressive, some said — until you remember that 100% of those bugs had already passed human review and made it into the tree. (LWN's coverage of the announcement; the project on GitHub.)

In July, a proposal to link Sashiko with Patchwork — the tool maintainers use to track patch submissions — reopened a familiar argument: should the project restrict LLMs, or reject them altogether? Linus Torvalds ended the ambiguity in one line:

> "AI is a tool, just like other tools we use. And it's clearly a useful one."

Not a revolution. Not a religion. Not a threat. A tool — which means it gets evaluated the way tools always have. Does it work? Where does it fail? Can we build systems around it so the useful parts outweigh the harmful ones?

That is a much more interesting conversation. And it's the one I want to unpack, because I've sat in the enterprise version of this exact thread more times than I can count.

Usefulness is no longer the question

What strikes me most in that line is the second half. Clearly useful.

Linus concedes the "clearly" might not have held even a year ago — but today, in his view, the question is settled. There are still open questions around AI, he notes, like what its economics will ultimately look like. But "is it useful" is no longer one of them. Anybody who doubts it, he adds, hasn't actually used it.

Whatever you think of that assessment, the source matters. This is a project famous for its skepticism — a community that resists hype by reflex and has spent three decades saying no to things that didn't prove themselves. When "is AI useful" moves from open question to closed one there, the debate everyone else is still having quietly changed shape. The interesting arguments now start one level up.

Which doesn't mean the tool is perfect — and Linus doesn't pretend otherwise. Compilers have bugs, static analyzers flood you with false positives, reviewers miss defects. Tools aren't valuable because they're flawless; they're valuable because, used correctly, they improve the overall system. His point is blunt: anybody pointing at AI's flaws had better be looking in the mirror at the same time, because natural intelligence isn't exactly flawless either.

The useful question is never whether a tool can fail. It's what happens when it fails:

🔍 Can the failure be detected?
💸 How expensive is it?
👤 Who has to deal with it?
⚖️ Does the productivity gained elsewhere compensate for that cost?

These are engineering questions. Engineering questions can be measured. Ideological questions cannot — which is precisely why they never end.

The water is rising — and so are the boats

The most important part of Linus's response isn't his defense of AI. It's his recognition of what AI does to the people downstream of it.

He acknowledges openly that these tools can be painful for maintainers: more generated code, more reports, more patches — more work for the humans responsible for reviewing everything. That is a legitimate problem, and it's tempting to read it as an argument for turning the tap off.

But that's not what's happening. The water level is rising for everything at once. Yes, AI produces more submissions to review — and it also produces better ways to review them. Sashiko itself is the proof: the same class of technology that swells the patch queue also catches bugs that every human reviewer missed. Bigger inflow, bigger filters, and — if the system is built right — bigger results at the end. The volume of the problem and the capacity of the solution scale together.

Linus's conclusion follows directly:

> "The solution is to make sure those LLM tools help maintainers instead of just causing them pain."

There's a large difference between "AI creates problems, therefore we should not use AI" and "AI creates problems, therefore we need to solve those problems — with the same rising capability." The second is how engineers approach every other technology: improve the filters, strengthen the validation, remove the noise before a human ever sees it.

The only losing position is the boat that refuses to float — absorbing the rising inflow with yesterday's capacity. The problem is not philosophical. It is architectural.

Accountability never moves

For all the freedom Linus grants on tools, one thing stays fixed: the submitter owns the patch, assisted or not. A generated explanation doesn't make a bug real; a polished description doesn't prove the change was understood. No tool signs off on code in place of the person sending it. Automation accelerates the work — it does not transfer ownership.

That fixed point is what makes everything else safe. Because responsibility stays fully human, the tools become a private matter. Nobody is forced to use AI, and nobody gets to prevent others from using it. You don't have to be an enthusiast to write software, and you don't have to be a skeptic either.

The goal is an excellent patch — regardless of the means. If an LLM helped produce one, objecting to the tool gains nothing. If AI was used to produce garbage, reject the garbage.

The quality of the work is the standard. Not the purity of the process that produced it.

Pragmatism is not optimism

One distinction worth protecting: being pragmatic about AI does not mean being optimistic about it.

You can believe much of the industry is overhyped. You can question the economics — Sashiko itself runs on compute Google donates today, and as LWN pointed out, that kind of generosity has a history of ending. (The sovereign-AI version of that question is the one I work on daily: usefulness now is not the same as dependency-free usefulness later.) You can worry about code quality and about reviewers drowning in generated noise.

Linus separates all of that from the narrower question of whether the technology is useful — a question he considers settled. You don't have to agree with every part of his assessment. But the method is worth preserving: separate the questions, and never let one legitimate concern become an argument against an entire class of technology.

Because once tool choices become moral statements — once using an LLM supposedly says something about you — evaluating the technology itself becomes nearly impossible.

The better question

We'll spend years debating what AI means for software engineering. There will be brilliant uses and absurd ones, developers transformed by these tools and developers who find little in them. That's fine. Technology does not require consensus. It requires evaluation.

The most interesting thing about Linus's response is not that he defended AI. It's that he refused to treat AI as something that needs to be believed in.

Don't worship tools. Don't fear them. Use them, understand where they fail, improve the systems around them, and judge the results.

If the most conservative, most scrutinised codebase in the world can hold that line, "our environment is too critical for AI" just lost its best example.

Where is your organisation still asking people to believe — and where has it started measuring instead?

Sources: Linus Torvalds' message on the linux-media list · The Sashiko patch-review system (LWN) · Development tools: Sashiko, b4 review, and API specification (LWN) · Sashiko on GitHub · Roman Gushchin's original announcement · The Register's coverage