On July 15, 2026, Linus Torvalds declared in an email concerning Linux kernel development policy that Linux "will not be an anti-AI project." He stated flatly that participants who cannot accept the use of AI have the option, in the open-source tradition, to fork the project or leave it.
Taken at face value, the strong wording looks like an ultimatum from the pro-AI camp against dissenters. But the debate didn't start from a proposal to fully open the door to AI-generated code. The real question was: to whom should the findings from the AI review system "Sashiko" be sent, and who should confirm the false positives? What Linux ran into was the allocation of human time that remains even after generation speed increases.
Torvalds's answer isn't to hand judgment over to AI either. Linux's current rules require that a human read AI-generated code, verify its licensing, and take it on under their own signature. The entry point stays open. But the exit point for responsibility doesn't move from the human.
The Spark: Whose Inbox Should Sashiko Connect To?
The originating thread, "Linking Patchwork with Sashiko?", began on the Linux Media Mailing List on May 30. Patchwork is a system that tracks patches arriving via email; linking it to Sashiko's review results would let authors and maintainers process findings within the same workflow. But when it came to deciding who the automated emails should be addressed to, efficiency and consent collided.
Longtime kernel developer Laurent Pinchart argued that before Sashiko's findings are sent to an author, any maintainer who wants to use it should first screen the content and confirm its correctness—also respecting the wishes of authors who don't want to receive communications from AI. As grounds for this, he cited the first two items in a recommendation published by the Software Freedom Conservancy (SFC) on June 18.
Roman Gushchin countered that inserting a human in that step would defeat Sashiko's purpose of "helping the maintainer." If a serious defect is found, should the maintainer really have to check whether the author has opted out, and then manually forward it by hand? Torvalds joined in on this side, stating that AI is clearly a useful tool and he would not accept arguments that obstruct other people's use of it.
Each option shifts different work away and moves different work elsewhere.
| Operation | First recipient | Benefit gained | Burden remaining on humans |
|---|---|---|---|
| Auto-send to author | Patch author and public list | Skips relaying, lets fixes start sooner | Author must screen out false positives |
| Maintainer pre-checks | Subsystem maintainer | Low-quality findings don't reach the author | Maintainer must read every single one |
| Opt-in operation | Only authors/areas who chose to use it | Easier to respect individual choice | Notification paths and exception handling grow complex |
Whichever row of this table you choose, the verification work itself doesn't disappear. Whether AI adoption succeeds comes down to whether that work is actually reduced by the machine, or simply shifted to a different person's inbox.
How to Read That 53.6% Self-Assessment
Sashiko is an open-source project under the Apache License 2.0, belonging to the Linux Foundation. Its public service monitors the Linux Kernel Mailing List (LKML), with Google providing the compute resources and LLM tokens. Rather than a mechanism that simply calls a model once and has it jot down impressions, it's an agent-based review system combining kernel-specific prompts with a multi-stage verification process.
The public README describes an 11-stage pipeline. It first reads the purpose and design of a change, and checks whether the implementation matches the commit message. It then traces execution paths, resource management such as memory, and locking/concurrency, examining safety and hardware-specific constraints. After that, it consolidates duplicate findings, cross-checks them against counter-evidence, assigns severity, and converts the result into an email. Subsystem-specific prompts are also used.
The project reports, in a public benchmark using Gemini 3.1 Pro, that it detected 53.6% of known bugs across 1,000 past upstream commits containing known bugs. Judging is done by a separate AI judge, which compares the review output against descriptions of known issues. False positives, based on limited manual verification, were reportedly within 20%. However, the README itself acknowledges the latter figure is a reference value that is "hard to measure," explicitly noting that results can vary even for the same input.
The 53.6% figure is a recall rate—how many already-fixed bugs it managed to rediscover. Moreover, AI is involved in the judging itself as well. It's unknown, in actual email exchanges, how many false positives an author has to read—and how many minutes they spend—before arriving at a single correct finding. The premises also differ by subsystem. To measure real-world operational value, you need not just the detection count but also the precision per finding and the time spent on verification.
Figures presented on linux-mm in March illustrate this distinction well. Maintainer Andrew Morton reported that, among emails including Sashiko reviews, authors acknowledged a needed fix in 22 cases, judged no fix necessary in 2 cases, found 1 case undeterminable, and left 10-15 cases unanswered. In response, another developer pointed out that if you treat the unanswered cases as 10, that comes to 22 out of 35, or about 63%—but this is merely "the rate at which at least one finding per patch hit the mark," and tells us nothing about the signal-to-noise ratio across all findings. Usefulness can be confirmed. The validity of automatic distribution still has to be measured separately.
Humans Sign Off, and Take on the Responsibility
The official Linux kernel document "AI Coding Assistants" clearly sets out the terms of acceptance. AI agents must not add a Signed-off-by. Only a human can legally certify the Developer Certificate of Origin (DCO); the submitter must review the generated code, verify compatibility with GPL-2.0-only, add their own signature, and bear full responsibility for the contribution.
Nor is hiding AI assistance the assumption here. The recommended record is Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]. Who ultimately bears responsibility is fixed via Signed-off-by, while which model and specialized tools were involved is tracked via Assisted-by. It's a design that separates disclosure of provenance from legal accountability into distinct tags.
For bug reports, an even stricter standard of verification is demanded. The official Security bugs document instructs that issues discovered with AI assistance be treated as public information. This is because there have been repeated cases of multiple investigators using the same tool reporting the same issue on the same day. Reporters must identify the affected versions and actually run the reproduction steps. They must explain the impact in light of Linux's threat model, and, where possible, attach a tested fix as well.
This same issue surfaced again in the Linux 7.1-rc4 announcement on May 17, 2026. Torvalds explained that duplicate AI reports had made the private security list "nearly unmanageable." Time was being consumed forwarding and cross-checking issues that had already been fixed, and because the list is private, reporters couldn't see each other's submissions. The fact that Linux's official documentation treats AI-assisted discoveries as public information and requires reproduction, impact explanation, and a fix aligns with this operational effort to curb duplication and verification costs.
Reconciling Individual Refusal with a Shared Workflow
The SFC recommendation cited here is not a document calling for a blanket ban on AI. While it supports the self-determination of those who refuse AI, it also asks that contributors who use AI not be excluded either. Before submission, a human must read the work thoroughly, and the model used and the nature of its involvement should be recorded in a machine-readable form. Submissions not reviewed by a human should be confined to locations explicitly designated by the project for that purpose. It even acknowledges that strategic use of proprietary AI may be justified when it can significantly advance FOSS.
What was actually in conflict was the freedom of an individual to refuse AI, versus how that refusal should be reflected within a shared development workflow. Theodore Tso argued that the SFC recommendation primarily assumes generated code, and that the situation differs for code review, bug analysis, and backporting to long-term support versions. An operational model where a maintainer has to re-read and rephrase Sashiko's report every single time an author refuses AI eats into already-limited maintenance time.
In a follow-up email, Torvalds assessed that AI review can sometimes catch non-obvious problems that checkpatch misses. At the same time, he wrote that just as checkpatch, over years of tuning, came to add more value than pain, Sashiko needs that same kind of improvement. This statement is not a declaration of unconditional trust in current output. It's a stance of using the tool while measuring its technical track record and reducing bad notifications.
His own personal usage history follows the same line. Torvalds had Google Antigravity write a Python visualization tool for his personal project "AudioNoise." However, he describes that same project as a toy for learning digital audio processing. He draws a distinction between trying something out to judge its performance, and bringing that same degree of delegation into the Linux kernel.
Not Pushing the Cost of False Positives Outside the Workflow
In Sashiko's public service, Google covers the inference costs. But Google doesn't cover the time spent reading reports to determine whether they're correct or not. If sent directly to the author, the author pays that cost; if the maintainer serves as the gate, the maintainer pays it. In open source, this human time is precisely the resource in shortest supply.
For that reason, future evaluation needs more granular operational metrics than just the bug detection rate. It should measure the false-positive rate by subsystem, the number of emails after deduplication, and the proportion of findings actually adopted by authors. It should further compare the number of minutes authors and maintainers spend before arriving at a single fix. The threshold for sending only serious findings directly, and the routing that aggregates findings to a dedicated list rather than the author, should also be decided based on these numbers.
What Linux has closed off this time is the entry-point debate over "whether to use AI at all." What remains open is verifying whether Sashiko can actually reduce human workload. If email volume and the adoption rate of its findings improve, and there remains an accountable human behind every Assisted-by, AI review could become a standard tool of kernel development. If the burden merely shifts to a different inbox, then no matter how high that 53.6% recall figure is, the operation won't be sustainable for long.