"Either fork it or leave", Linus hits back at AI opponents: Linux will not go "anti-AI"

From dismissing AI as "90% marketing hype" to openly acknowledging it as a valid tool, Linux creator Linus Torvalds' stance on artificial intelligence has undergone a notable shift.

However, reviewing his public statements over the past two years reveals that Linus has never truly opposed AI itself. His objections have consistently targeted unvetted code, low-value bug reports, and individuals who offload review costs onto open source maintainers.

Linus Torvalds, Linux founder and top-level kernel maintainer, has once again laid down clear boundaries for AI's role in the Linux kernel community in his signature uncompromising style.

During a Linux Kernel Mailing List discussion on July 14, in response to some developers' resistance to large language model tools, Linus explicitly stated that Linux is not an "anti-AI project."

Those who disagree with this direction can fork the kernel in the traditional open source way, or simply leave.

"Linux is not one of those anti-AI projects. If people have issues with that, they can fork the project the open source way,"

"Or just leave."

Linus emphasized that he is willing to "take a firm stand" on this issue in his role as the Linux kernel's top maintainer. In his view, AI is first and foremost a tool, no different from compilers, static analyzers, or code search utilities. It is not perfect and creates new problems, but by today, whether it is useful is no longer a debatable point.

A Debate Centered on AI Code Review 

The mailing list controversy revolved around a project called Sashiko.

According to its official description, Sashiko is an agent-based review system designed specifically for Linux kernel code changes. It can read patches from the kernel mailing list or Git repositories, analyze the code using Linux kernel-specific prompts, protocols, and tools, and generate review feedback. The project is not tied to any single model provider and can be configured to work with different large language models.

The dispute began when Linux developer Laurent Pinchart argued that if maintainers intended to act on review results generated by Sashiko, they should first filter and verify those results themselves before contacting the original patch author. He also cited recommendations from the Software Freedom Conservancy (SFC) regarding LLM-assisted open source contributions.

Another developer, Roman Gushchin, disagreed with this position.

He argued that if maintainers using Sashiko were required to fully verify every AI-generated comment before contacting authors, the system's original goal of "helping maintainers" would become nearly unachievable. The issue should not be framed as how to add verification steps to every use case, but rather addressed directly: Is Linux fundamentally a project that opposes large language models?

It was in this context that Linus delivered his firm response: No, Linux does not take an anti-AI stance.

Notably, the SFC recommendations drawn into the debate are far from a simple "AI ban."

The SFC does state that open source communities should support developers who choose to completely reject LLMs, that no one should be pressured into using AI by employers or projects, and that projects can decide not to accept AI-generated contributions based on their maintainer capacity.

But the same document also emphasizes that open source projects should not exclude contributors who use AI. Before submitting AI-assisted or AI-generated code, submitters must spend sufficient time reviewing it, truly understand the code, and disclose which model was used, its version, and how AI was involved. For scenarios that can significantly accelerate open source software improvement, the SFC even describes using proprietary AI tools as an acceptable "strategic compromise."

Thus, the real disagreement is not simply "pro-AI versus anti-AI," but rather who should bear the verification responsibility for AI outputs, and how that responsibility should be distributed between tool developers, patch submitters, maintainers, and original code authors.

Linus Acknowledges AI's Utility, But Does Not Give It Full Green Light 

While Linus used strong language in his email, he did not advocate for unconditional acceptance of AI-generated code in the Linux kernel.

His core judgment is that AI has become a genuinely effective engineering tool. It can increase maintainers' workload and uncover embarrassing bugs, but the solution is not to pretend these tools don't exist, nor to impose principled bans preventing others from using them. Instead, processes should be designed so that LLMs truly help maintainers rather than merely creating more work for them.

"We're not forcing anybody to use it," Linus stated, but he similarly has no patience for people who try to stop other developers from using AI.

To critics who point out that AI makes mistakes, he offered his characteristically sharp wit: AI is not perfect, but those who complain about its flaws should look in the mirror, because "natural intelligence isn't always that great either."

Linus then reframed the issue around the long-standing principle of the Linux project: The Linux kernel is first and foremost a technical project.

In his view, the social relationships, community identity, and public value generated by open source collaboration are all important and can motivate participants, but they are secondary benefits of the project—not the primary reason Linux exists.

The Linux kernel community chose open source because it produces better technology, not out of quasi-religious devotion. Therefore, decisions involving AI should be based primarily on technical outcomes, not fear of new tools.

This is the key to understanding Linus's position. He did not argue about whether AI companies use open source code appropriately, nor did he deny the environmental, copyright, and employment issues AI raises. He simply refused to let those broader controversies automatically translate into a blanket rejection of AI tools by the Linux kernel project.

In fact, the Linux kernel has already established fairly clear rules for AI contributions.

Linux kernel documentation specifies that using AI to assist kernel development must still comply with normal kernel development workflows, coding standards, and patch submission requirements. AI agents cannot add the "Signed-off-by" tag on their own, as that tag represents the submitter's legal affirmation of the Developer Certificate of Origin and can only be provided by a human.

Submitters must review all AI-generated code, verify license compatibility, and take full responsibility for their contributions. When AI assistance is involved, the documentation also recommends using an "Assisted-by" tag to note the AI tool name, model version, and related professional analysis tools. In short, Linux allows AI to participate in development, but ultimate responsibility cannot be delegated to AI.

From "90% Hype" to Recognizing AI's Unignorable Value 

Interestingly, Linus's current vocal praise for AI's value stands in stark contrast to his public assessment of AI back in 2024.

As reported by The Register, in October 2024, during an interview at the Open Source Summit in Vienna, Linus admitted AI was interesting and potentially world-changing, but said he strongly disliked the hype the tech industry was generating around it.

At that time, he estimated that roughly 90% of AI narratives in the market were marketing, with only about 10% representing real value. Because the hype was so excessive, he chose to ignore AI temporarily, believing it might take five years for people to see its actual use in real workloads.

Linus also compared the AI boom of that era to the previous cryptocurrency wave. In his view, products like ChatGPT could produce impressive demos and had entered some use cases, but those facts still did not justify the vast majority of the marketing claims.

Less than two years later, Linus is saying that whether AI is useful is now "beyond doubt," and people who question it probably haven't actually used it themselves.

By 2026, AI has begun delivering verifiable results in kernel bug discovery, patch checking, and code review. Linus still dislikes hype and will still reject low-quality AI outputs, but he no longer considers "is AI useful" an open question.

Linus is not alone in his changed perspective on AI; Linux stable maintainer Greg Kroah-Hartman expressed similar sentiments in March this year.

Greg noted that AI-generated bug reports were very low quality for a long time—often just "garbage" that wasted maintainers' time. But in early 2026, things changed. AI began submitting genuine, reproducible, high-quality bug reports, a shift seen not just in the Linux kernel but in security teams across multiple open source projects.

Greg tested related tools and got about 60 issues and potential fixes. Roughly one-third of the fixes were incorrect in their approach, but still pointed to a real underlying problem; the other two-thirds of the patches were largely correct.

Of course, those patches still require human cleanup, verification, and proper integration following kernel processes.

AI's Bug Discovery Speed Is Outpacing Maintainers' Processing Capacity 

Linus is not blind to the burden AI places on maintainers. Just two months before these recent comments, he publicly criticized AI-generated duplicate reports and unnecessary patches.

In May this year, Linus noted that Linux kernel's private security mailing list was being flooded with issues discovered by AI tools. The same vulnerability could be reported repeatedly by different people and different tools, making the mailing list designed for handling sensitive security issues nearly unmanageable.

His advice was simple: People who find issues using AI should not just dump raw outputs onto maintainers. Reporters should read the documentation, understand the problem, check whether it has already been reported, and ideally attempt to write a patch. Submitters must add human value on top of AI results, rather than submitting "drive-by reports."

During another kernel release candidate cycle, Linus also criticized some trivial fixes triggered by AI code review. He argued that while these changes might be locally correct, they did not need to enter the kernel late in the release cycle. Even seemingly simple modifications could introduce regression risks. Submitters needed to answer not "did AI find a piece of code that could be changed," but whether the issue is serious, whether it causes a real regression, and whether the fix is worth making at the current stage.

Taken together, these statements outline Linus's fairly complete view of AI: AI can find bugs, inspect code, and assist development, but discovering a theoretical problem does not equal producing a bug report worth submitting; generating a compilable change does not equal creating a patch worth merging.

AI expands the scope of search, but humans must still judge whether the problem is real, whether the fix is necessary, whether the modification is safe, and whether it aligns with the project's current development rhythm.

This is the contradiction facing the entire open source industry today. AI has lowered the cost of finding suspicious code, writing reports, and generating patches, but it has not proportionally reduced the cost for maintainers to verify, communicate, and take responsibility.

Taking the curl project as an example, maintainer Daniel Stenberg has observed that obviously low-quality AI garbage reports have decreased, while more credible AI reports requiring serious verification have increased. The latter, while higher quality, are also far more time-consuming. AI makes reports faster, but that doesn't mean maintainers can reproduce, assess risks, and implement fixes just as quickly.

Thus, what AI brings to the open source community may not just be an "overabundance of garbage content," but a more challenging situation: most reports are not completely wrong, yet each one requires human time to determine how much of it is actually valid.

Community Debate: "The Tool Exists" Does Not Mean The Problem Is Solved 

Across communities like GamingOnLinux and Reddit, Linus's remarks have received widespread support while also drawing considerable criticism.

GamingOnLinux user minus9 believes Linus's attitude is as pragmatic as ever. Even if one doesn't like AI, "the genie is out of the bottle," and people can no longer pretend it doesn't exist. Still, he says he's glad he doesn't have to clean up the mess AI might create.

Another user, pb, said that if one must find an acceptable use case for AI, making code review easier is probably the most reasonable scenario. The problem is that many people are using AI the other way around: not to help humans review code, but to mass-produce code with AI and offload the review pressure onto others.

User wytrabbit takes a more conditional stance. He does not oppose AI in general, and supports its use for scientific research, high-risk work, and code vulnerability detection—but objects to corporations chasing profits at ordinary people's expense and the abuse of AI for mass surveillance. In code development, he can accept AI helping to find bugs, but does not want LLMs to directly generate final patches.

Reddit user PlacidTurbulence argues that some media headlines like "Linus tells AI opponents to fork off" exaggerate the hostility of the email.