Linus Torvalds has reportedly drawn a hard line in the Linux kernel’s mounting dispute over AI-assisted code review: the project is not going to become anti-AI, and contributors who cannot accept that direction are free to fork the code or leave. The immediate issue is Sashiko, an automated patch-review system whose findings have exposed a familiar problem for maintainers: a tool can find real defects and still create an exhausting volume of false alarms.
Neowin reported Torvalds’ intervention on July 15 after a debate over whether Sashiko-generated review comments should be delivered directly to patch authors. For Windows users and administrators, this is not distant community drama. Linux kernel development feeds the infrastructure beneath WSL, Azure-hosted Linux workloads, containers, networking appliances, drivers, Android devices, and much of the software supply chain that Windows environments increasingly touch.
The practical dispute is not whether an LLM can write code. It is whether an LLM should become an active participant in the already crowded process of deciding which kernel patches are safe to merge.
Sashiko reviews patches submitted to Linux mailing lists and can flag suspected defects before a maintainer accepts a change. The attraction is obvious: kernel maintainers have too much code to inspect and too few expert reviewers, while an automated system can examine every patch without fatigue.
The concern is equally concrete. Krzysztof Kozlowski, a kernel developer, objected in a May mailing-list thread after Sashiko attached a
Roman Gushchin, one of Sashiko’s developers, paused the use of the tag and said the intent had been to let maintainers know that automated review had completed with no findings. That is a sensible status signal, but it is not the same as a human review. The argument over the tag may sound procedural, yet it gets at a core engineering question: who owns the judgment when automation says a patch is safe?
Laurent Pinchart, a long-time kernel contributor and media subsystem maintainer, made the more consequential point. Human reviewers can improve through feedback and become trusted participants in a subsystem over time. An LLM review system, by contrast, can operate at vastly larger scale without joining that social and technical learning loop. Its underlying service may improve, but each individual automated comment does not develop accountability or domain intuition.
Pinchart did not argue that maintainers should be banned from using the tool. He argued that authors should not be forced to respond to automated reviews, especially where a subsystem has concluded that the signal-to-noise ratio is poor.
That distinction matters. Linux kernel review is not just a bug-finding exercise; it is the mechanism through which maintainers establish that someone understands a change well enough to repair it later.
The ext4 filesystem developers, for example, experimented with sending Sashiko output only to patch authors and maintainers. Theodore Ts’o, the ext4 maintainer, said the group concluded its false-positive level was low enough to make wider distribution worthwhile for ext4 patches. Pinchart acknowledged that such decisions have historically been made subsystem by subsystem, even while objecting to a project-wide expectation that every contributor must process machine-generated feedback.
That local control is likely the only workable compromise for a kernel as broad as Linux. The review value of an AI system will vary dramatically between a narrowly scoped driver fix, a memory-management change, a filesystem patch, and a security-sensitive refactor. A generic model can notice suspicious patterns, but maintainers still have to decide whether a warning is meaningful in the context of an API, hardware quirk, regression history, or subsystem convention.
Torvalds’ reported position appears to be that AI tools may remain part of the process, but they do not replace maintainer responsibility. That is a much narrower claim than the rhetoric around the dispute suggests. It also aligns with a position he has voiced before: generative AI can accelerate early-stage work, while long-term maintenance and review demand context that automated tools frequently lack.
The project’s recent handling of AI-generated security reports reinforces that line. Kernel developers have pushed back against bulk, low-quality LLM reports that arrive without sufficient validation. Automation that locates a reproducible fault can help; automation that turns private security reporting into a delivery channel for unverified prose does the opposite.
Godot described precisely that imbalance when it tightened its contribution policy on June 30. The open-source game engine said it was overwhelmed by incoming pull requests, while its supply of qualified reviewers had not grown to match. Godot’s new approach rejects autonomous AI agents and substantial AI-authored code, requires disclosure for limited assistance, and continues to require human review before a merge.
The RPCS3 PlayStation 3 emulator project took a similarly blunt stance in May, telling contributors to stop submitting AI-generated code that they do not understand. Both projects are reacting to a maintenance economics problem: generating a plausible patch now takes minutes, but validating it, testing it across configurations, and supporting it after release can take days or months.
Linux is approaching the same problem from the opposite direction. Rather than prohibit an AI reviewer, the kernel is trying to determine where automated analysis produces enough useful signal to justify the added traffic. The risk is that making AI review mandatory for every patch author turns the supposed time-saving tool into another queue of work.
That risk will be familiar to Windows IT professionals. Endpoint-management alerts, SIEM detections, code-scanning dashboards, and vulnerability scanners all fail when their output is treated as an instruction rather than evidence. A detection tool earns trust through precision, transparency, reproducibility, and a clear escalation path—not because it produces more messages.
But a fork is rarely a practical answer for a contributor who maintains a driver, subsystem, or architecture-dependent feature. Forking Linux means duplicating an enormous maintenance burden and losing the collaboration that makes the upstream kernel valuable. In that sense, the phrase is a declaration of project direction, not a realistic alternative for most developers.
The better test will be whether Linux can establish boundaries that preserve contributor trust while keeping useful automation. That starts with not presenting bot output as a human sign-off, allowing maintainers to tune or reject low-value review traffic, and expecting humans—not models—to validate findings before they become release-blocking work.
Sashiko’s future inside Linux will therefore depend less on Torvalds’ broad endorsement of AI than on mundane, measurable outcomes: how often it finds bugs humans missed, how many false positives it creates, and whether maintainers still believe the tool saves more time than it consumes.
Neowin reported Torvalds’ intervention on July 15 after a debate over whether Sashiko-generated review comments should be delivered directly to patch authors. For Windows users and administrators, this is not distant community drama. Linux kernel development feeds the infrastructure beneath WSL, Azure-hosted Linux workloads, containers, networking appliances, drivers, Android devices, and much of the software supply chain that Windows environments increasingly touch.
The practical dispute is not whether an LLM can write code. It is whether an LLM should become an active participant in the already crowded process of deciding which kernel patches are safe to merge.
Sashiko’s usefulness is being judged against its noise
Sashiko reviews patches submitted to Linux mailing lists and can flag suspected defects before a maintainer accepts a change. The attraction is obvious: kernel maintainers have too much code to inspect and too few expert reviewers, while an automated system can examine every patch without fatigue.The concern is equally concrete. Krzysztof Kozlowski, a kernel developer, objected in a May mailing-list thread after Sashiko attached a
Reviewed-by tag to a patch. In the Linux workflow, that trailer is more than decoration; it signals that someone has reviewed the change and accepts a degree of responsibility for it. Kozlowski argued that a bot cannot make that human statement of judgment, particularly when the tool produces misleading findings and false positives.Roman Gushchin, one of Sashiko’s developers, paused the use of the tag and said the intent had been to let maintainers know that automated review had completed with no findings. That is a sensible status signal, but it is not the same as a human review. The argument over the tag may sound procedural, yet it gets at a core engineering question: who owns the judgment when automation says a patch is safe?
Laurent Pinchart, a long-time kernel contributor and media subsystem maintainer, made the more consequential point. Human reviewers can improve through feedback and become trusted participants in a subsystem over time. An LLM review system, by contrast, can operate at vastly larger scale without joining that social and technical learning loop. Its underlying service may improve, but each individual automated comment does not develop accountability or domain intuition.
Pinchart did not argue that maintainers should be banned from using the tool. He argued that authors should not be forced to respond to automated reviews, especially where a subsystem has concluded that the signal-to-noise ratio is poor.
That distinction matters. Linux kernel review is not just a bug-finding exercise; it is the mechanism through which maintainers establish that someone understands a change well enough to repair it later.
The kernel is choosing subsystem judgment over a universal ban
The existing discussion shows the Linux project has already landed on a more nuanced model than either “AI everywhere” or “AI nowhere.” Different subsystems can decide how much value they see in Sashiko’s output and how publicly that output should be distributed.The ext4 filesystem developers, for example, experimented with sending Sashiko output only to patch authors and maintainers. Theodore Ts’o, the ext4 maintainer, said the group concluded its false-positive level was low enough to make wider distribution worthwhile for ext4 patches. Pinchart acknowledged that such decisions have historically been made subsystem by subsystem, even while objecting to a project-wide expectation that every contributor must process machine-generated feedback.
That local control is likely the only workable compromise for a kernel as broad as Linux. The review value of an AI system will vary dramatically between a narrowly scoped driver fix, a memory-management change, a filesystem patch, and a security-sensitive refactor. A generic model can notice suspicious patterns, but maintainers still have to decide whether a warning is meaningful in the context of an API, hardware quirk, regression history, or subsystem convention.
Torvalds’ reported position appears to be that AI tools may remain part of the process, but they do not replace maintainer responsibility. That is a much narrower claim than the rhetoric around the dispute suggests. It also aligns with a position he has voiced before: generative AI can accelerate early-stage work, while long-term maintenance and review demand context that automated tools frequently lack.
The project’s recent handling of AI-generated security reports reinforces that line. Kernel developers have pushed back against bulk, low-quality LLM reports that arrive without sufficient validation. Automation that locates a reproducible fault can help; automation that turns private security reporting into a delivery channel for unverified prose does the opposite.
The open-source argument has shifted from authorship to review capacity
The most important lesson from the Sashiko dispute is that the kernel community’s problem is not simply whether AI-generated code is correct. It is that generative tools lower the cost of submitting code, bug reports, and review comments faster than they lower the cost of verification.Godot described precisely that imbalance when it tightened its contribution policy on June 30. The open-source game engine said it was overwhelmed by incoming pull requests, while its supply of qualified reviewers had not grown to match. Godot’s new approach rejects autonomous AI agents and substantial AI-authored code, requires disclosure for limited assistance, and continues to require human review before a merge.
The RPCS3 PlayStation 3 emulator project took a similarly blunt stance in May, telling contributors to stop submitting AI-generated code that they do not understand. Both projects are reacting to a maintenance economics problem: generating a plausible patch now takes minutes, but validating it, testing it across configurations, and supporting it after release can take days or months.
Linux is approaching the same problem from the opposite direction. Rather than prohibit an AI reviewer, the kernel is trying to determine where automated analysis produces enough useful signal to justify the added traffic. The risk is that making AI review mandatory for every patch author turns the supposed time-saving tool into another queue of work.
That risk will be familiar to Windows IT professionals. Endpoint-management alerts, SIEM detections, code-scanning dashboards, and vulnerability scanners all fail when their output is treated as an instruction rather than evidence. A detection tool earns trust through precision, transparency, reproducibility, and a clear escalation path—not because it produces more messages.
“Fork it” is governance language, not an engineering solution
Torvalds’ reported “fork it” response follows a longstanding open-source principle: contributors cannot demand that a project adopt their preferred governance or tooling rules. The Linux kernel has a maintainer hierarchy, and top-level technical direction is not decided by a universal opt-out mechanism.But a fork is rarely a practical answer for a contributor who maintains a driver, subsystem, or architecture-dependent feature. Forking Linux means duplicating an enormous maintenance burden and losing the collaboration that makes the upstream kernel valuable. In that sense, the phrase is a declaration of project direction, not a realistic alternative for most developers.
The better test will be whether Linux can establish boundaries that preserve contributor trust while keeping useful automation. That starts with not presenting bot output as a human sign-off, allowing maintainers to tune or reject low-value review traffic, and expecting humans—not models—to validate findings before they become release-blocking work.
Sashiko’s future inside Linux will therefore depend less on Torvalds’ broad endorsement of AI than on mundane, measurable outcomes: how often it finds bugs humans missed, how many false positives it creates, and whether maintainers still believe the tool saves more time than it consumes.
References
- Primary source: Neowin
Published: 2026-07-15T21:52:01+00:00
"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: as.com
Loading…
as.com