Linus Torvalds has made it clear that Linux kernel development will not adopt a broadly anti-artificial intelligence stance. Linux’s creator believes large language models have already proved useful for finding bugs and reviewing code, although their use must genuinely help maintainers rather than overwhelm them with additional work.
The key points about artificial intelligence in Linux in 20 seconds
- Torvalds says Linux will not adopt an anti-AI policy.
- The discussion began around Sashiko, an agentic review system for kernel patches.
- Nobody will be forced to use these tools, but developers will not be allowed to prevent others from doing so.
- The test will be practical: AI must reduce workloads rather than flood maintainers with false positives.
His intervention came during a public discussion on the Linux kernel mailing lists about Sashiko, a tool that uses language models to analyse proposed changes. Some developers argued that every AI-generated warning should be manually verified before being sent to the patch author. Others believed that such a requirement would remove much of the value offered by automation.
Torvalds sided with the latter group and used particularly direct language. His position does not mean Linux will automatically accept AI-generated code or require developers to use assistants. His message is narrower: the project will not reject a tool merely because it uses artificial intelligence, and its contribution will be judged on technical merit.
Sashiko reviews kernel patches with specialised agents
Sashiko is an agentic review system designed specifically for changes to the Linux kernel. Contrary to how it has been described in some reports, it is not an official Google tool. The project supports several model providers, including Gemini, Claude, GitHub Copilot, OpenAI-compatible services and platforms such as Amazon Bedrock or Vertex AI.
Its workflow attempts to reproduce a review carried out by several specialists. Instead of sending a patch to one model with a generic instruction, Sashiko divides the analysis into stages covering the purpose of the change, code execution, memory management, concurrency, security and hardware interaction.
| Review stage | What it attempts to detect |
|---|---|
| Purpose of the change | Conceptual errors or compatibility issues |
| Implementation | Differences between the code and its stated objective |
| Execution flow | Error paths, ignored return values and logic flaws |
| Resource management | Leaks, double frees and use-after-free bugs |
| Concurrency | Locking faults, races and RCU violations |
| Security | Buffer overflows, out-of-bounds access and data leaks |
| Hardware | DMA, register, memory-barrier and state-machine errors |
| Final verification | Duplicate removal and severity assessment |
The system can monitor mailing lists, receive changes from local repositories and analyse pull or merge requests from GitHub and GitLab. After completing 11 stages, it generates a report using the format normally found in a Linux Kernel Mailing List, or LKML, reply.
Sashiko’s developers say the tool detected 53.6% of the bugs present in a sample built from the latest 1,000 changes that later required a correction identified with a Fixes tag. The test used Gemini 3.1 Pro.
The figure is striking because those defects had already passed human review and reached the mainline kernel. However, it does not mean Sashiko can find half of all Linux bugs. The evaluation set consists of problems already known in hindsight, and the methodology comes from the project itself.
False alarms must also be considered. Its developers estimate that the false-positive rate remains below 20%, based on limited manual review, but acknowledge that this metric is harder to measure. Some warnings also fall into a grey area where there is no unequivocal answer.
Torvalds supports the tool, but not the removal of human review
Torvalds said Linux “is not one of those anti-AI projects” and added that anyone unable to accept that direction can fork the kernel or walk away. The forcefulness of the response has attracted much of the attention, although the core of his argument concerns technical usefulness.
Linux’s lead maintainer argues that it may still have been reasonable a year ago to question whether language models delivered enough value, but he considers that debate settled. These systems find real bugs and sometimes identify problems that human reviewers missed.
That does not mean he sees their results as infallible. Torvalds acknowledged that AI can be a painful tool, both because of false positives and because of its ability to uncover embarrassing defects in code that had already been reviewed.
His position is that the answer lies in improving the tools and how they are integrated. Linux will not force anyone to use AI, but it will not allow general opposition to the technology to prevent other developers from adopting it.
| What Torvalds supports | What he has not announced |
|---|---|
| Using AI when it delivers useful results | Autonomous kernel development |
| Analysing patches with language models | Automatic acceptance of changes |
| Judging tools on technical merit | Mandatory use of AI assistants |
| Improving false-positive filtering | Replacing maintainers |
| Making reviews easier | Blind trust in generated reports |
Responsibility ultimately remains with authors and maintainers. A model may flag a possible race condition or memory error, but a person must determine whether the problem is real, whether the proposed correction is appropriate and whether it introduces side effects.
Torvalds’s position also does not yet amount to a complete policy on AI-generated contributions. The discussion focused on automated patch review, not on allowing an agent to write and submit changes without supervision.
The real conflict is over maintainers’ time
The disagreement began when Laurent Pinchart proposed applying the first recommendations published by the Software Freedom Conservancy to Sashiko and other free-software contributions assisted by language models.
Those recommendations argue that nobody should be forced to use AI, that generated contributions require thorough review before submission and that projects may reserve specific areas for automated contributions. They also call for disclosure of which model was used and for interaction records to be retained.
The Software Freedom Conservancy does not propose an outright ban. Its document acknowledges that models can accelerate improvements to free and open-source software and accepts their use as a strategic choice in some circumstances. Its main concern is preventing the cost of an automated contribution from being transferred to maintainers who already have limited time and resources.
The problem can be reduced to one question: who should spend the time verifying that an AI-generated report is correct?
Pinchart argued that a maintainer interested in using a Sashiko review should verify it before bothering the patch author. Roman Gushchin replied that requiring this preliminary review would make the tool’s main objective, helping maintainers, impossible to achieve.
| Usage model | Advantage | Risk |
|---|---|---|
| Verify every warning before sending it | Reduces noise and false alarms | Preserves a heavy manual workload |
| Send reports automatically | Makes greater use of automation | May overwhelm authors and mailing lists |
| Filter by severity and confidence | Balances usefulness and volume | Depends on reliable classification |
| Run Sashiko only on request | Gives maintainers control | Reduces coverage |
| Use it alongside human reviewers | Adds another layer of analysis | May duplicate observations |
Torvalds opposes allowing broad recommendations to become a practical barrier to using these tools. However, he agrees with the central goal: models should help maintainers rather than create additional problems.
This distinction will be decisive. The kernel receives thousands of changes and relies on a distributed process in which each subsystem has its own maintainers. Even a moderate false-positive rate could produce a large volume of messages if every patch were reviewed automatically.
Sashiko attempts to limit that problem through several stages of consolidation, contradiction resolution and verification. Even so, its output is probabilistic: it may find different defects when analysing the same code again, or fail to reproduce a warning it previously generated.
Linux opens the door to AI without changing its core rules
Torvalds’s intervention reinforces a trend already visible across other major software projects. Language models are moving beyond generating code fragments and are beginning to review changes, navigate repositories, run tests and search for vulnerabilities.
Within Linux, their adoption will have to coexist with rules built around individual responsibility. Authors are expected to understand and defend the changes they submit, regardless of which tools were used to write or review them.
There are also privacy and intellectual-property questions. Sashiko may send a patch, related files and parts of the kernel’s history to an external provider in order to give the model enough context. Linux code is public, but the same tool applied to private repositories would require additional controls over confidentiality, permissions and data retention.
Cost is another factor. An 11-stage review can consume a considerable number of tokens, particularly when it needs to inspect files, history and dependencies. The project warns that users are responsible for monitoring API expenditure.
Torvalds’s statement does not solve all these issues or establish how AI-assisted contributions should be identified. It does, however, draw a political line within the project: Linux will not adopt a broadly anti-AI position.
Acceptance will depend on results. A tool that finds important defects, filters its mistakes and respects the review process will have a place. One that generates large volumes of imprecise or unverifiable reports will eventually be ignored, regardless of how advanced its underlying model may be.
Frequently asked questions
Does Linus Torvalds want AI to write the Linux kernel?
No. His intervention supports the voluntary use of useful tools, particularly for code review. He has not proposed accepting patches generated without human supervision.
Is Sashiko a Google tool?
No. It is a kernel-focused project that can work with several providers. Gemini is one compatible model, alongside Claude, GitHub Copilot and other services.
How accurate is Sashiko at finding bugs?
The project says it found 53.6% of the known defects in a sample of 1,000 changes that were later corrected. The test is internal, and its false-positive estimate is based on limited manual review.
Will contributors be required to use artificial intelligence?
No. Torvalds explicitly said nobody will be forced to use it, although he will not support attempts by some developers to prevent others from working with these tools.
Sources:
- Linus Torvalds, kernel mailing-list intervention on Sashiko and Linux’s position on AI.
- Sashiko, documentation, workflow, supported models and bug-detection tests.
- Software Freedom Conservancy, recommendations for free-software contributions assisted by language models.