Linus Torvalds has drawn a hard line on artificial intelligence in Linux kernel development: contributors may choose not to use AI tools themselves, but they will not get a veto over colleagues who do. In a Linux Kernel Mailing List exchange this week, Torvalds said Linux is not an “anti-AI” project and told opponents they can fork the kernel or “just walk away.”
The Register first reported the exchange, which grew out of debate over AI-assisted maintenance workflows around Patchwork and Sashiko. The immediate practical result is not an AI mandate, nor an automated path into the kernel tree. It is a clear maintainer-level policy: AI use is permissible when it produces technically useful work, and ideological objections will not carry the day.
That distinction matters well beyond Linux. The kernel is the foundation beneath countless Windows-adjacent environments, from WSL deployments and developer workstations to Azure infrastructure, network appliances, Android devices, storage systems, and embedded products. Its contribution process remains a high-stakes test case for whether open-source projects can incorporate LLM-assisted work without surrendering code quality or overwhelming the people who review it.
Torvalds’ comments are blunt, but they do not announce that AI-generated patches are now trusted by default. Linux has always been governed by review, maintainership, subsystem ownership, testing, regression analysis, and a long history of contributors being asked to fix or rethink inadequate submissions. None of that has been replaced.
Instead, Torvalds is rejecting an effort to treat AI as categorically illegitimate. He described AI as another tool in the engineering workflow and said its usefulness is no longer seriously in doubt. The standard remains technical merit: does a report identify a real defect, does a patch solve it cleanly, can maintainers understand and validate it, and does the submitter take responsibility for the result?
That is a more consequential message than the headline-worthy “fork it” language. It tells contributors that the kernel’s governance is not likely to create a blanket anti-LLM rule, a prohibition on AI-supported review, or a cultural penalty for developers who use these tools responsibly.
For enterprises, that closely resembles the policy direction already emerging inside software organizations: prohibit unreviewed machine output from entering production, but do not prohibit developers from using assistance for search, analysis, drafting, test construction, or code comprehension. Linux is applying that philosophy in public, where every rough edge becomes a mailing-list dispute.
The failure mode is familiar to anyone managing a Windows estate with AI-assisted security tooling. A system that produces ten highly actionable alerts is useful. A system that produces 10,000 plausible-sounding but poorly evidenced alerts is a cost center disguised as automation.
Linux maintainers have already seen both sides of that equation. Earlier reporting from The Register described Torvalds complaining that AI-powered bug-hunting reports had made the Linux security mailing list difficult to manage. That was not an argument against detecting bugs with AI; it was an argument against dumping unvetted output on a finite pool of reviewers.
This week’s stance does not erase that concern. It clarifies where responsibility lies. The submitter, whether assisted by an LLM or not, is accountable for the report or patch. A generated explanation does not make a bug real. A polished patch description does not establish that a regression has been understood. And no tool gets to sign off on code in place of the person sending it.
That is the operating model IT teams should recognize: automation may accelerate discovery, but it does not transfer ownership.
The technical question is whether such tooling can reduce routine overhead: spotting related reports, checking patch context, helping maintainers summarize activity, or improving the initial quality of submissions. The cultural question is harder. Some kernel contributors fear that LLM-driven tools normalize low-effort participation, flatten expert judgment into generic prose, and encourage inexperienced developers to submit code they cannot maintain.
Those fears are not imaginary. “Vibe coding” has become shorthand for accepting generated code primarily because it appears to work, not because the developer understands its design, dependencies, licensing implications, security properties, or failure modes. That approach is particularly dangerous in kernel code, where errors can become privilege-escalation vulnerabilities, data corruption, boot failures, hardware instability, or obscure performance regressions.
But a blanket ban has its own problems. It would be hard to define, difficult to enforce, and likely to push usage underground rather than improve outcomes. Developers already use compilers, static analyzers, fuzzers, code search, documentation tools, and automated test systems. LLM assistance is disruptive partly because it spans several of those activities at once, but the kernel’s review process can still judge the output.
Torvalds’ intervention therefore amounts to a refusal to convert an engineering project into a referendum on AI vendors, AI labor concerns, model training practices, or broader cultural anxieties. Those debates may matter to individual contributors, but he is signaling that they are not the primary criteria for Linux kernel acceptance.
What has changed is not that Torvalds suddenly treats every AI claim as credible. It is that he appears to have concluded the tools now have enough direct, observable utility to be treated as part of normal engineering practice. The Register also pointed to March comments from senior Linux maintainer Greg Kroah-Hartman, who said AI-assisted reports and reviews had improved materially.
That should not be confused with evidence that all AI-generated contributions are improving. The Linux community’s own recent friction suggests the opposite: quality is uneven, and the volume of low-value material can be destructive. The more defensible conclusion is that the tool category has matured enough that maintainers do not want to exclude its useful cases simply because its worst cases are conspicuous.
In other words, Linux is not declaring victory for AI. It is declining to pretend that the technology can be wished away.
A workable policy has to preserve accountability:
The next test is whether the kernel community can turn that permissive stance into better maintainer workflows without opening a faster lane for unreviewed AI slop. That outcome will depend less on the model and more on the humans operating the inbox.
The Register first reported the exchange, which grew out of debate over AI-assisted maintenance workflows around Patchwork and Sashiko. The immediate practical result is not an AI mandate, nor an automated path into the kernel tree. It is a clear maintainer-level policy: AI use is permissible when it produces technically useful work, and ideological objections will not carry the day.
That distinction matters well beyond Linux. The kernel is the foundation beneath countless Windows-adjacent environments, from WSL deployments and developer workstations to Azure infrastructure, network appliances, Android devices, storage systems, and embedded products. Its contribution process remains a high-stakes test case for whether open-source projects can incorporate LLM-assisted work without surrendering code quality or overwhelming the people who review it.
The policy is permissive, not automatic
Torvalds’ comments are blunt, but they do not announce that AI-generated patches are now trusted by default. Linux has always been governed by review, maintainership, subsystem ownership, testing, regression analysis, and a long history of contributors being asked to fix or rethink inadequate submissions. None of that has been replaced.Instead, Torvalds is rejecting an effort to treat AI as categorically illegitimate. He described AI as another tool in the engineering workflow and said its usefulness is no longer seriously in doubt. The standard remains technical merit: does a report identify a real defect, does a patch solve it cleanly, can maintainers understand and validate it, and does the submitter take responsibility for the result?
That is a more consequential message than the headline-worthy “fork it” language. It tells contributors that the kernel’s governance is not likely to create a blanket anti-LLM rule, a prohibition on AI-supported review, or a cultural penalty for developers who use these tools responsibly.
For enterprises, that closely resembles the policy direction already emerging inside software organizations: prohibit unreviewed machine output from entering production, but do not prohibit developers from using assistance for search, analysis, drafting, test construction, or code comprehension. Linux is applying that philosophy in public, where every rough edge becomes a mailing-list dispute.
Maintainers still have the same problem: incoming work
Torvalds did not portray AI as painless. According to The Register’s account of the mailing-list discussion, he acknowledged that it can increase maintainer workloads and surface embarrassing bugs. That second point is worth taking seriously. Automated analysis can find legitimate issues at scale, but every claim still has to be triaged, reproduced, contextualized, and possibly fixed by a human being.The failure mode is familiar to anyone managing a Windows estate with AI-assisted security tooling. A system that produces ten highly actionable alerts is useful. A system that produces 10,000 plausible-sounding but poorly evidenced alerts is a cost center disguised as automation.
Linux maintainers have already seen both sides of that equation. Earlier reporting from The Register described Torvalds complaining that AI-powered bug-hunting reports had made the Linux security mailing list difficult to manage. That was not an argument against detecting bugs with AI; it was an argument against dumping unvetted output on a finite pool of reviewers.
This week’s stance does not erase that concern. It clarifies where responsibility lies. The submitter, whether assisted by an LLM or not, is accountable for the report or patch. A generated explanation does not make a bug real. A polished patch description does not establish that a regression has been understood. And no tool gets to sign off on code in place of the person sending it.
That is the operating model IT teams should recognize: automation may accelerate discovery, but it does not transfer ownership.
The Sashiko debate exposed a wider culture clash
The dispute reportedly centered in part on Sashiko, an AI-based maintenance support tool connected to Patchwork-style workflows. Patchwork is used in the kernel community to track patches and review status across mailing-list-based development, where the scale and fragmentation of incoming work can be substantial.The technical question is whether such tooling can reduce routine overhead: spotting related reports, checking patch context, helping maintainers summarize activity, or improving the initial quality of submissions. The cultural question is harder. Some kernel contributors fear that LLM-driven tools normalize low-effort participation, flatten expert judgment into generic prose, and encourage inexperienced developers to submit code they cannot maintain.
Those fears are not imaginary. “Vibe coding” has become shorthand for accepting generated code primarily because it appears to work, not because the developer understands its design, dependencies, licensing implications, security properties, or failure modes. That approach is particularly dangerous in kernel code, where errors can become privilege-escalation vulnerabilities, data corruption, boot failures, hardware instability, or obscure performance regressions.
But a blanket ban has its own problems. It would be hard to define, difficult to enforce, and likely to push usage underground rather than improve outcomes. Developers already use compilers, static analyzers, fuzzers, code search, documentation tools, and automated test systems. LLM assistance is disruptive partly because it spans several of those activities at once, but the kernel’s review process can still judge the output.
Torvalds’ intervention therefore amounts to a refusal to convert an engineering project into a referendum on AI vendors, AI labor concerns, model training practices, or broader cultural anxieties. Those debates may matter to individual contributors, but he is signaling that they are not the primary criteria for Linux kernel acceptance.
The apparent reversal is narrower than it looks
Torvalds’ new rhetoric will read as a sharp reversal to readers who remember his October 2024 dismissal of much of the AI industry’s messaging as hype. At the time, he said he intended to largely ignore the subject while predicting that the technology could look very different within several years.What has changed is not that Torvalds suddenly treats every AI claim as credible. It is that he appears to have concluded the tools now have enough direct, observable utility to be treated as part of normal engineering practice. The Register also pointed to March comments from senior Linux maintainer Greg Kroah-Hartman, who said AI-assisted reports and reviews had improved materially.
That should not be confused with evidence that all AI-generated contributions are improving. The Linux community’s own recent friction suggests the opposite: quality is uneven, and the volume of low-value material can be destructive. The more defensible conclusion is that the tool category has matured enough that maintainers do not want to exclude its useful cases simply because its worst cases are conspicuous.
In other words, Linux is not declaring victory for AI. It is declining to pretend that the technology can be wished away.
Windows developers and admins should read this as a governance lesson
For Windows professionals, the direct kernel-development consequences may be distant, but the management lesson is immediate. Organizations adopting GitHub Copilot, Microsoft 365 Copilot, security copilots, local code models, or AI-assisted ticket analysis need rules that are stricter than “use AI” and more realistic than “never use AI.”A workable policy has to preserve accountability:
- Developers should be able to explain, test, and maintain code regardless of whether AI helped draft it.
- Security teams should require reproducible evidence before escalating AI-generated vulnerability findings.
- Change-control processes should record the responsible human approver, not merely the tool used to produce a recommendation.
- Teams should measure whether automation reduces time to resolution rather than merely increases the number of tickets, alerts, or pull requests.
The next test is whether the kernel community can turn that permissive stance into better maintainer workflows without opening a faster lane for unreviewed AI slop. That outcome will depend less on the model and more on the humans operating the inbox.
References
- Primary source: finance.biggo.com
Published: 2026-07-16T02:06:48+00:00
Linus Torvalds to AI Critics in Linux Community: 'Fork It or Walk Away' — BigGo Finance
Linus Torvalds has drawn a hard line on artificial intelligence in Linux kernel development, declaring that Linux is not an 'anti-AI' project and…finance.biggo.com - Independent coverage: The Register
Published: 2026-07-15T16:54:00+00:00
Linus Torvalds tells AI haters to fork off
Linux supremo says contributors opposed to AI use can 'just walk away'www.theregister.com - Related coverage: techradar.com
Quote of the day by Linux creator Linus Torvalds: 'Nvidia has been the single worst company we've ever dealt with' — airing frustrations at walled gardens | TechRadar
The Linux creator had a particularly tough time with Nvidia throughout history – but things have changed dramatically since thenwww.techradar.com - Related coverage: neowin.net
"Fork it or leave": Linus Torvalds riles up Linux's AI luddites - Neowin
Linus Torvalds has little sympathy for Linux contributors pushing back against AI, telling those unhappy with the shift that they know where the door is.
www.neowin.net
- Related coverage: pcgamer.com
'The continued flood of AI reports has basically made the security list almost entirely unmanageable': Linus Torvalds laments how people are wasting the Linux team's time with LLMs | PC Gamer
Linux's creator isn't against the use of AI tools, he's just tired of folks using them and then doing nothing with what they've discoveredwww.pcgamer.com - Related coverage: tomshardware.com
Linux lays down the law on AI-generated code, says yes to Copilot, no to AI slop, and humans take the fall for mistakes — after months of fierce debate, Torvalds and maintainers come to an agreement | Tom's Hardware
After months of fierce debate, Linus Torvalds and the Linux kernel maintainers have laid down the law on AI-generated code.www.tomshardware.com