Linus Torvalds has drawn a firm line in the Linux kernel’s AI debate: Linux is not an anti-AI project, and contributors who want a blanket ban on AI-assisted development should fork the kernel or leave the project. The message, posted this week to the Linux Kernel Mailing List, matters well beyond the Linux desktop: it signals that AI-assisted analysis is becoming an accepted part of the engineering pipeline behind servers, cloud platforms, embedded devices, WSL distributions, and much of the infrastructure Windows administrators work alongside.
As first reported by Ars Technica and corroborated by Phoronix, Torvalds was responding to debate over Sashiko, an LLM-driven review system developed by Google engineer Roman Gushchin. Torvalds did not announce that AI-generated patches will be accepted without scrutiny, nor did he require developers to use AI. Instead, he defended the freedom to use capable tools where they improve code review and bug finding.
That distinction is the center of the story. Linux is not adopting vibe coding as a release process. It is deciding that an ideological objection to AI tools will not override evidence that some tools can uncover bugs missed by conventional review.
The immediate trigger was Sashiko, an open-source, Rust-written system that reviews Linux kernel patches using large language models. It monitors kernel mailing lists and analyzes submitted changes; it does not merge code, approve patches, or act as an autonomous kernel maintainer.
According to Sashiko’s documentation and reporting from LWN.net, the project’s developers tested it against 1,000 recent upstream fixes and said it identified 53.6% of the underlying bugs when using Gemini 3.1 Pro. Those bugs had already passed human review before being fixed later. The project also estimates a false-positive rate within roughly 20%, although that number is harder to validate and should be treated as a project claim rather than an independent benchmark.
For Linux maintainers, the useful metric is not an AI leaderboard score. It is whether a review comment points to a reproducible issue, provides enough context to investigate it, and saves more time than it costs. A system that files vague, inaccurate, or repetitive reports merely converts compute into maintainer workload. A system that catches a subtle filesystem, memory-management, driver, or concurrency bug before merge has obvious value.
Torvalds acknowledged that LLM tools can create pain for maintainers, including by finding what he called embarrassing bugs. But he rejected the idea that ignoring the tools solves the operational problem. The goal, he argued, is to make them help maintainers rather than burden them.
That is a considerably tougher standard than simply allowing AI to participate. It puts the onus on tool authors and contributors to produce useful review output, not on kernel developers to clean up automated noise.
The policy requires contributors to understand their submission, comply with licensing requirements, and take full responsibility for the result. AI systems cannot meaningfully certify a Developer Certificate of Origin, explain a design decision under review, or accept responsibility for a regression in a production storage driver. The person submitting the patch still must.
That makes Linux’s policy pragmatic rather than permissive-by-default. A developer can use Copilot, Claude, Gemini, a locally hosted model, a static analyzer, a compiler, a fuzzing system, or Sashiko-style review tooling. But the code and its provenance must still survive review, testing, licensing checks, and maintainer judgment.
The project has also published guidance for tool-generated content more broadly. The point is not to police every keystroke; it is to make a patch understandable and reviewable. That matters because a maintainer reviewing code for a PCIe driver, a scheduler change, or an ARM platform fix cannot safely accept a contribution simply because an AI generated a plausible explanation beside it.
In that sense, Torvalds is defending tools without erasing the old rules. Linux remains a human-governed project, and acceptance remains a human decision.
Generated code can introduce licensing uncertainty, hidden defects, security flaws, unnecessary complexity, or code that the submitter cannot properly maintain. Those risks increase if contributors treat an LLM as an authority rather than a fallible assistant. The Linux contribution rules answer that by requiring a responsible human to stand behind the patch.
Automated review introduces a different problem: volume. A review bot that comments on every patch can detect issues at scale, but it can also overwhelm developers with low-value findings. The burden moves from writing code to sorting machine-generated objections, many of which may be technically possible but irrelevant to the patch at hand.
This is why the Sashiko dispute is more consequential than the inevitable arguments over whether AI output is “real programming.” Linux already relies on extensive automation: compilers, build farms, static-analysis tools, fuzzers, CI systems, test harnesses, and scripts. AI review is an attempt to add another imperfect layer to that tooling stack.
The difference is that an LLM can produce natural-language feedback that appears authoritative even when its reasoning is weak. Maintainers therefore need concise reports, concrete evidence, and a way to reject noise quickly. A model’s ability to notice anomalies is useful; its confidence is not proof.
Torvalds’ stance says the kernel community should improve that workflow, not prohibit it.
But Linux development has direct relevance to a large slice of the Windows ecosystem. Windows Subsystem for Linux depends on Linux distributions and user-space software. Azure runs extensively on Linux infrastructure. Hyper-V hosts Linux workloads, enterprise developers build cross-platform applications with WSL, and Windows administrators routinely manage Linux servers, containers, Kubernetes clusters, network appliances, and NAS systems.
The practical implication is that kernel bugs may increasingly be found by AI-assisted review before they reach downstream distributions and enterprise deployments. That is not a guarantee of better security or fewer outages; the kernel’s complexity ensures there will be regressions and hard-to-detect failures regardless of tooling. But it does mean the upstream project is willing to use AI where it can improve the odds.
For developers working across Windows and Linux, the more immediate lesson is procedural. AI assistance is becoming compatible with serious upstream engineering only when the human operator can explain, test, maintain, and legally vouch for the output. The useful skill is not prompting a model to emit a patch. It is being able to prove that patch belongs in a codebase.
Developers remain free not to use LLMs. Maintainers can still reject low-quality reports, poorly documented patches, or unreviewable generated code. Subsystems can develop workflows suited to their own risk and review capacity. What Torvalds has ruled out is a project-wide anti-AI identity.
That may frustrate developers who see AI as primarily a source of spam, copyright risk, and careless automation. Those concerns have not disappeared, and Linux’s own documentation implicitly recognizes them. But the kernel’s top maintainer has made the decision criterion clear: technical merit and maintainer outcomes, not a blanket refusal of new tooling.
Sashiko and similar systems will now face the harder test. They must demonstrate, patch by patch, that they can find real problems without becoming another problem for the people responsible for shipping Linux.
As first reported by Ars Technica and corroborated by Phoronix, Torvalds was responding to debate over Sashiko, an LLM-driven review system developed by Google engineer Roman Gushchin. Torvalds did not announce that AI-generated patches will be accepted without scrutiny, nor did he require developers to use AI. Instead, he defended the freedom to use capable tools where they improve code review and bug finding.
That distinction is the center of the story. Linux is not adopting vibe coding as a release process. It is deciding that an ideological objection to AI tools will not override evidence that some tools can uncover bugs missed by conventional review.
Sashiko Turned an Abstract Argument Into a Maintainer Problem
The immediate trigger was Sashiko, an open-source, Rust-written system that reviews Linux kernel patches using large language models. It monitors kernel mailing lists and analyzes submitted changes; it does not merge code, approve patches, or act as an autonomous kernel maintainer.According to Sashiko’s documentation and reporting from LWN.net, the project’s developers tested it against 1,000 recent upstream fixes and said it identified 53.6% of the underlying bugs when using Gemini 3.1 Pro. Those bugs had already passed human review before being fixed later. The project also estimates a false-positive rate within roughly 20%, although that number is harder to validate and should be treated as a project claim rather than an independent benchmark.
For Linux maintainers, the useful metric is not an AI leaderboard score. It is whether a review comment points to a reproducible issue, provides enough context to investigate it, and saves more time than it costs. A system that files vague, inaccurate, or repetitive reports merely converts compute into maintainer workload. A system that catches a subtle filesystem, memory-management, driver, or concurrency bug before merge has obvious value.
Torvalds acknowledged that LLM tools can create pain for maintainers, including by finding what he called embarrassing bugs. But he rejected the idea that ignoring the tools solves the operational problem. The goal, he argued, is to make them help maintainers rather than burden them.
That is a considerably tougher standard than simply allowing AI to participate. It puts the onus on tool authors and contributors to produce useful review output, not on kernel developers to clean up automated noise.
Linux Has Already Written Rules for AI-Assisted Contributions
The Linux kernel’s position is more structured than Torvalds’ blunt “fork it or walk away” formulation suggests. Kernel documentation introduced earlier in 2026 explicitly permits AI coding assistants, while keeping accountability attached to the human contributor.The policy requires contributors to understand their submission, comply with licensing requirements, and take full responsibility for the result. AI systems cannot meaningfully certify a Developer Certificate of Origin, explain a design decision under review, or accept responsibility for a regression in a production storage driver. The person submitting the patch still must.
That makes Linux’s policy pragmatic rather than permissive-by-default. A developer can use Copilot, Claude, Gemini, a locally hosted model, a static analyzer, a compiler, a fuzzing system, or Sashiko-style review tooling. But the code and its provenance must still survive review, testing, licensing checks, and maintainer judgment.
The project has also published guidance for tool-generated content more broadly. The point is not to police every keystroke; it is to make a patch understandable and reviewable. That matters because a maintainer reviewing code for a PCIe driver, a scheduler change, or an ARM platform fix cannot safely accept a contribution simply because an AI generated a plausible explanation beside it.
In that sense, Torvalds is defending tools without erasing the old rules. Linux remains a human-governed project, and acceptance remains a human decision.
The Fight Is About Review Capacity, Not Just Generated Code
Much public discussion around AI in open source collapses two separate issues into one: AI-generated code and AI-assisted code review. They create different risks.Generated code can introduce licensing uncertainty, hidden defects, security flaws, unnecessary complexity, or code that the submitter cannot properly maintain. Those risks increase if contributors treat an LLM as an authority rather than a fallible assistant. The Linux contribution rules answer that by requiring a responsible human to stand behind the patch.
Automated review introduces a different problem: volume. A review bot that comments on every patch can detect issues at scale, but it can also overwhelm developers with low-value findings. The burden moves from writing code to sorting machine-generated objections, many of which may be technically possible but irrelevant to the patch at hand.
This is why the Sashiko dispute is more consequential than the inevitable arguments over whether AI output is “real programming.” Linux already relies on extensive automation: compilers, build farms, static-analysis tools, fuzzers, CI systems, test harnesses, and scripts. AI review is an attempt to add another imperfect layer to that tooling stack.
The difference is that an LLM can produce natural-language feedback that appears authoritative even when its reasoning is weak. Maintainers therefore need concise reports, concrete evidence, and a way to reject noise quickly. A model’s ability to notice anomalies is useful; its confidence is not proof.
Torvalds’ stance says the kernel community should improve that workflow, not prohibit it.
Windows Users Will Feel This Indirectly
For most Windows users, this is not a reason to expect a sudden visible change in Windows 11. The Linux kernel is not the Windows kernel, and Sashiko is not being inserted into Windows Update or Microsoft’s Patch Tuesday process.But Linux development has direct relevance to a large slice of the Windows ecosystem. Windows Subsystem for Linux depends on Linux distributions and user-space software. Azure runs extensively on Linux infrastructure. Hyper-V hosts Linux workloads, enterprise developers build cross-platform applications with WSL, and Windows administrators routinely manage Linux servers, containers, Kubernetes clusters, network appliances, and NAS systems.
The practical implication is that kernel bugs may increasingly be found by AI-assisted review before they reach downstream distributions and enterprise deployments. That is not a guarantee of better security or fewer outages; the kernel’s complexity ensures there will be regressions and hard-to-detect failures regardless of tooling. But it does mean the upstream project is willing to use AI where it can improve the odds.
For developers working across Windows and Linux, the more immediate lesson is procedural. AI assistance is becoming compatible with serious upstream engineering only when the human operator can explain, test, maintain, and legally vouch for the output. The useful skill is not prompting a model to emit a patch. It is being able to prove that patch belongs in a codebase.
Torvalds Has Made the Governance Call
Torvalds’ language was intentionally uncompromising because the disagreement had become a governance question: should individual contributors be able to stop other contributors or maintainers from using AI tools? His answer is no.Developers remain free not to use LLMs. Maintainers can still reject low-quality reports, poorly documented patches, or unreviewable generated code. Subsystems can develop workflows suited to their own risk and review capacity. What Torvalds has ruled out is a project-wide anti-AI identity.
That may frustrate developers who see AI as primarily a source of spam, copyright risk, and careless automation. Those concerns have not disappeared, and Linux’s own documentation implicitly recognizes them. But the kernel’s top maintainer has made the decision criterion clear: technical merit and maintainer outcomes, not a blanket refusal of new tooling.
Sashiko and similar systems will now face the harder test. They must demonstrate, patch by patch, that they can find real problems without becoming another problem for the people responsible for shipping Linux.
References
- Primary source: zamin.uz
Published: 2026-07-17T15:53:27+00:00
Linus Torvalds and AI: Linux founder responds sharply to critics – Zamin.uz, 17.07.2026
Linus Torvalds, the founder of the Linux operating system, has responded unexpectedly and sharply to community members opposing the… – Zamin.uz, 17.07.2026zamin.uz - Independent coverage: PC Guide
Published: 2026-07-17T09:06:52+00:00
Linus Torvalds says Linux is not an anti-AI project, and if you don't like that, then "fork it or just walk away" - PC Guide
The founder of Linux has made his thoughts on AI tools clear, and he's fully on board. He says the Linux kernel does not fear new tools.www.pcguide.com - Independent coverage: finance.biggo.com
Published: 2026-07-17T06:45:32+00:00
Linux Creator Torvalds Draws Hard Line: Kernel Is Not 'Anti-AI' — Fork It or Leave If You Disagree — BigGo Finance
Linux kernel lead maintainer Linus Torvalds issued a forceful statement on the community mailing list, making it clear that Linux is not an "anti-AI"…finance.biggo.com - Independent coverage: GIGAZINE
Published: 2026-07-17T04:41:00+00:00
Linus Torvalds expressed his views on the use of AI in Linux kernel development, stating that 'Linux is not anti-AI' and 'if you don't like it, you can fork it.' - GIGAZINE
The news blog specialized in Japanese culture, odd news, gadgets and all other funny stuffs. Updated everyday.gigazine.net - Independent coverage: Tom's Hardware
Published: 2026-07-16T16:59:13+00:00
Linus Torvalds rebukes anti-AI stances in the Linux kernel code review process, says 'Linux is not one of those anti-AI projects' — creator embraces AI as just a tool and 'clearly a useful one' | Tom's Hardware
The flashpoint was the Sashiko code review tools.www.tomshardware.com - Independent coverage: ZDNET
Published: 2026-07-16T12:12:00+00:00
Linus Torvalds puts his foot down, tells anti-AI programmers to 'fork it'
'AI is a tool, just like other tools we use. And it's clearly a useful one.'www.zdnet.com