Direct Answer
Linus Torvalds did say Linux is not an anti-AI project and that people who cannot accept that may fork it or walk away. He did not announce that AI can merge kernel code, replace maintainers, or bypass the project's standards. His narrower argument was that a general ethical objection cannot veto technically useful review tools for everyone else.
The immediate subject was Sashiko, an open-source agentic system that reviews proposed kernel patches. That matters because AI review is a different risk category from unattended AI authorship. A reviewer can generate hypotheses that a human verifies; a submitted patch changes software used by billions of devices and requires an accountable owner.
Watch Theo's Analysis
Video credit: Theo - t3.gg. Watch the original video on YouTube. The video includes a paid Macroscope sponsorship; this article has no relationship with the sponsor. Torvalds' position, Sashiko's design, and the contribution rules were checked against the mailing-list archive, project repository, and official kernel documentation on 3 August 2026.
What Actually Happened
A kernel mailing-list discussion about Sashiko moved from implementation details into a broader dispute over whether generative AI has an ethical place in free and open-source software. Laurent Pinchart argued for stronger human triage of automated reviews and raised Software Freedom Conservancy guidance. Sashiko creator Roman Gushchin responded that the position had become generally anti-LLM rather than a proposal about this tool's measurable behavior.
Torvalds then drew the governance boundary. He rejected making Linux an anti-AI project, called AI a useful tool, acknowledged that it can create maintainer pain, and said the engineering task is to make the tools help maintainers rather than overload them. In a follow-up exchange, he treated personal ethical refusal as valid for the individual but not binding on the rest of the project.
| Layer of the dispute | Question | Who decides? |
|---|---|---|
| Personal | Do I use an LLM in my own work? | The contributor |
| Submission | Is this patch understood, disclosed, tested, and defensible? | The submitter and subsystem maintainer |
| Automation | May a bot post reviews to this list or repository? | The project or subsystem |
| Upstream governance | Does Linux adopt a blanket anti-AI rule? | Top-level and subsystem maintainers through project governance |
| Alternative policy | Can a community run Linux under stricter rules? | Yes, through a fork or downstream policy |
Torvalds' Position, Without the Headline Compression
The primary-source message makes five claims. First, Linux will not define itself as anti-AI. Second, AI is already useful, even if its economics and wider effects remain open questions. Third, imperfect AI should be compared with imperfect human processes, not with an imaginary error-free baseline. Fourth, no contributor is being forced to use it. Fifth, Linux makes upstream decisions primarily on technical merit.
The sharpest line - "fork it" - gets the clicks. The most operational line comes later: the solution is to make LLM tools help maintainers instead of causing them pain. That standard is measurable. Does a review arrive early enough to improve a patch? Does it include a reproducer? How many findings are correct? How many minutes of maintainer work does it create or remove? Can the submitter answer questions about it?
What He Did Not Say
| Viral interpretation | What the record supports |
|---|---|
| "Linux is switching to vibe coding." | No. The thread concerned AI-assisted review, and the kernel still requires accountable submissions and maintainer review. |
| "AI output is presumed correct." | No. Sashiko calls its own output probabilistic, and the kernel guidelines explicitly warn that tool output may be incorrect or inappropriate. |
| "Maintainers must accept AI patches." | No. Individual maintainers can reject them, ask for extra testing, lower their review priority, or require the submitter to explain the work. |
| "Technical criticism of AI is banned." | No. Torvalds rejected a blanket ethical veto; his stated decision rule is technical merit, which requires technical criticism. |
| "Forking proves critics have no voice." | No. Forking is the freedom to pursue a different policy, but healthy upstream governance still benefits from evidence-based dissent. |
How Sashiko Reviews a Kernel Patch
Sashiko is an Apache-2.0 project under the Linux Foundation. Its public service is funded by Google, and the repository says it can use multiple providers. It ingests patches from public mailing lists or local Git, assembles relevant kernel context, and runs a staged protocol rather than asking one model for a generic review.
| Review stage | Examples of what it checks |
|---|---|
| Intent and architecture | Main goal, conceptual correctness, UAPI breakage, and architectural flaws |
| Implementation | Whether the code fulfills the commit message, API contracts, and side effects |
| Execution flow | Error paths, return checks, off-by-one errors, and control flow |
| Resources | Leaks, use-after-free, double frees, queues, timers, and object lifecycles |
| Concurrency | Deadlocks, locking, RCU rules, and thread safety |
| Security and hardware | Bounds, information leaks, TOCTOU, DMA, memory barriers, and register access |
| Consolidation | Deduplication, conflict resolution, severity estimation, and final report generation |
This architecture is the real lesson. The model is not asked to be a mystical senior engineer. It is given separate lenses, relevant repository context, a consolidation pass, and a verification pass. Sashiko still does not merge code. It produces review findings that humans can challenge, test, ignore, or use.
The repository also names two costs that the video moves past quickly: patch data and surrounding history may be sent to a third-party model provider, and automated multi-stage review can incur significant compute or API expense. Public kernel patches reduce confidentiality concerns for the hosted instance; private codebases need an explicit data-sharing decision.
What the 53.6% Result Proves - and What It Does Not
Sashiko reports finding 53.6% of bugs in a test built from the last 1,000 upstream commits carrying Fixes: tags, using Gemini 3.1 Pro. It estimates false positives within a 20% range based on limited manual review and says much of that boundary is gray. The project is commendably explicit that repeated runs are probabilistic.
The result supports a modest conclusion: a specialized LLM review pipeline can recover many known defect patterns from historical kernel changes. It does not establish that Sashiko catches 53.6% of future defects, that every finding would help a live maintainer, or that the system is "above human level." Retrospective evaluation benefits from a dataset selected because a fix is already known; live review includes novel design questions and incomplete context.
| Metric to add | Why it matters |
|---|---|
| Precision by severity | One correct critical finding may justify more noise than dozens of cosmetic concerns. |
| Novel-bug recall | Known historical fixes are easier to evaluate than unseen failure modes. |
| Time to first useful review | Fast pre-review can save a maintainer from opening a patch that is not ready. |
| Maintainer minutes per accepted finding | Measures workload instead of celebrating raw report volume. |
| Duplicate rate | Repeated automated reports can overwhelm private or fragmented channels. |
| Fix acceptance and regression rate | A plausible finding is not the same as a correct, maintainable fix. |
The Kernel's Real AI Policy Is Accountability
The official Kernel Guidelines for Tool-Generated Content are more useful than either side's slogans. They apply when a meaningful amount of a contribution was not written by someone in the Signed-off-by chain. They also treat tool-assisted problem detection and testing as part of the development record.
- Understand the entire submission. A contributor must be ready to answer review questions and defend every change.
- Disclose meaningful tool use. Name the tools, affected portions, relevant prompts or prompt summaries, and testing method.
- Expect proportional scrutiny. More generated content can justify more testing, lower priority, or outright rejection.
- Preserve maintainer discretion. The person responsible for a subsystem decides how to handle the contribution.
- Do not submit what you cannot defend. Tool output does not transfer responsibility away from the signer.
That is not an AI-first policy. It is a provenance-and-ownership policy broad enough to cover AI, Coccinelle, automated fixers, generated source files, and future tools. It protects the review process without pretending every tool has the same risk.
The Strongest Counterargument Is About Labor and Consent
Theo strongly endorses Torvalds' rejection of ethics as an upstream veto. The better counterargument is not that AI can never find a bug. It is that maintainers are a scarce human resource, proprietary tools create licensing and data questions, and automation can move work from the submitter to people who never consented to receive it.
The Software Freedom Conservancy's recommendations are more nuanced than a blanket ban. They support people who refuse LLMs, oppose mandatory use, ask contributors to curate and disclose assisted work, and recommend that unattended contributions go only to explicitly designated areas. The same document also says projects should not shun AI-assisted contributors and that using powerful tools can be an appropriate strategic compromise when they materially improve FOSS.
Torvalds and the Conservancy therefore share more ground than the argument suggests: no forced personal use, no unowned output, project-level governance, transparency, and technical evaluation. They disagree most sharply about how much ethical concern should shape upstream policy and how welcoming projects should be to unattended automation.
What "Fork It" Means in Open-Source Governance
A fork copies the source and establishes a separate line of development. It is the constitutional escape hatch of open source: a group that rejects upstream policy can maintain a downstream patch set, distribution, or independent kernel. The license permits that freedom; the engineering and community cost determine whether it survives.
Forking is not free. A serious kernel fork must track security fixes, hardware support, subsystem changes, toolchains, and upstream interfaces. That cost is why most disagreements are resolved through subsystem rules or downstream configuration rather than a permanent split. "Fork it" is therefore both a genuine freedom and a reminder that governance includes responsibility for the alternative.
A Responsible AI Review Workflow for Real Projects
| Gate | Required evidence | Failure behavior |
|---|---|---|
| 1. Scope | Repository, subsystem, data-sharing rule, model, budget, and allowed output channel | Do not run outside the approved boundary |
| 2. Local pre-review | Patch, tests, nearby code, project rules, and a structured finding schema | Keep uncertain findings private |
| 3. Verification | File and line, execution path, reproducer or failing test, severity, and confidence | Discard findings without concrete evidence |
| 4. Human ownership | A named contributor who understands the issue and proposed fix | No autonomous public report |
| 5. Disclosure | Tool, model, assistance summary, affected content, and test record | Return the submission for provenance |
| 6. Maintainer review | Normal project review plus any additional scrutiny requested | Maintainer may defer or reject |
| 7. Feedback loop | Accepted findings, false positives, duplicates, time saved, and regressions | Tighten prompts or pause automation when burden rises |
The highest-value starting point is pre-submit review for the author. It improves patches before scarce maintainer attention is consumed. Public automated comments should come later, after the project has measured precision, established deduplication, defined rate limits, and made a named person responsible for escalation.
A Short Policy Teams Can Adopt
AI assistance is allowed, but responsibility cannot be delegated.
1. Contributors must understand and defend every submitted change.
2. Meaningful AI assistance must be disclosed with the model, scope, and tests.
3. AI findings must include concrete evidence: code path, reproducer, or failing test.
4. Unattended public issues, patches, and review comments are prohibited unless a maintainer opts in.
5. A named human owns follow-up, deduplication, and correction.
6. Maintainers may request extra testing, lower review priority, or reject the contribution.
7. The project will measure accepted findings and maintainer time, not output volume.
8. Private code may be sent only to approved providers under the project's data policy.This policy is intentionally tool-neutral. It allows Sashiko, Codex, Claude Code, static analyzers, or future systems to compete on evidence while keeping the social contract human.
Claim Audit
| Claim from the video or headline | Assessment | Context |
|---|---|---|
| Torvalds told anti-AI developers to fork Linux or walk away. | Confirmed, with nuance | He rejected a project-wide anti-AI position; he did not require personal AI use. |
| Linux is using an agentic review system called Sashiko. | Confirmed | Sashiko is public, open source, and actively reviews kernel mailing-list submissions. |
| Sashiko found 53.6% of bugs in its test. | Project-reported | The benchmark used 1,000 historical fixed commits and Gemini 3.1 Pro; it is not a universal recall figure. |
| Sashiko is already above human level. | Not established | Historical recovery after human review is interesting but does not create a controlled human-versus-agent comparison. |
| AI bug reports went from junk to legitimate. | Maintainer observation | Greg Kroah-Hartman reported a sharp quality improvement while also warning that volume still increases review work. |
| The kernel has abandoned review standards because AI is useful. | False | Official guidance requires understanding, disclosure, testing, ownership, and maintainer discretion. |
| Every technically strong developer will eventually adopt AI. | Opinion | This is Theo's forecast, not a fact established by the Linux discussion. |
Video Chapters
| Time | Topic | Why it matters |
|---|---|---|
| 00:00 | Torvalds' anti-AI line | The headline and Theo's thesis. |
| 01:29 | Macroscope sponsorship | Paid segment about review dashboards and automated summaries. |
| 02:40 | Sashiko | Architecture, benchmark, and probabilistic output. |
| 04:23 | AI as additional verification | Review, test generation, and disposable validation code. |
| 05:20 | Maintainer reports | Greg Kroah-Hartman's account of improving AI findings and growing volume. |
| 09:01 | Torvalds' mailing-list response | The primary governance argument. |
| 11:44 | Helping maintainers | Why output quality alone is not enough. |
| 14:15 | Ethics and open-source policy | The most contentious part of the exchange. |
| 16:43 | TypeScript analogy | Theo's argument that tools can raise the quality floor. |
| 20:29 | AI as a floor-raising tool | Working outside a developer's specialty. |
| 22:14 | Practical closing | Generate more verification, not more unowned slop. |
Bottom Line
Torvalds' position is not "AI good, critics leave." It is closer to: Linux will evaluate tools by technical results, nobody is forced to use them, and personal opposition cannot automatically prohibit useful assistance for everyone else. The project still expects the person in the Signed-off-by chain to understand and defend the result.
Sashiko makes a credible case for specialized AI review. Its staged prompts, kernel context, consolidation, and verification are more serious than a generic chatbot pass. Its 53.6% result deserves attention and further independent evaluation, not a victory lap about replacing humans.
For ordinary teams, the winning pattern is less dramatic: put AI before scarce human review, require evidence, measure false positives and time saved, disclose meaningful assistance, and keep a human owner. The future of AI in open source will be decided by whether it reduces maintainer burden without erasing contributor responsibility.
Sources and Useful Links
- Theo - t3.gg: Linus is so based for this
- Theo - t3.gg on YouTube
- Linus Torvalds' response in the kernel mailing-list archive
- sashiko-dev/sashiko on GitHub
- Sashiko public review service
- Linux kernel guidelines for tool-generated content
- Linux kernel researcher guidelines
- Software Freedom Conservancy recommendations for LLM-assisted FOSS contributions
- The Register interview with Greg Kroah-Hartman on AI-assisted kernel reports