Linus Torvalds has made Linux's AI position plain: the kernel won't ban AI-assisted work just because some contributors dislike it. For anyone building developer tools, that's a sharper signal than another polished product demo.
There is no piece of software more load-bearing than the Linux kernel. It runs much of the server world, sits under cloud infrastructure at AWS, Google, and Azure, and helps power the GPU clusters training the AI systems everyone is arguing about. So when Torvalds says Linux is not an anti-AI project, you should pay attention.
His July 15 mailing-list post was not subtle. According to The Register, Torvalds wrote that Linux is not one of those anti-AI projects, and that people who object can fork the kernel or walk away. He also said AI is a tool, like other tools used in development, and called it clearly useful.
That is not the voice of someone dragged into the room by vendor hype. In October 2024, Torvalds called 90% of AI "marketing hype" - The Register noted that too. Then by July 2026: use it properly. That shift matters because Torvalds is not selling Copilot seats, an agent platform, or a consulting deck designed to make a quarter's numbers look good before anyone has shipped anything real. He is defending the maintenance of a project where sloppy code becomes everyone's problem.
Sashiko is part of the reason this argument has become harder to dismiss.
Phoronix reported in March that Google engineer Roman Gushchin announced Sashiko as an agentic AI code-review system for Linux kernel patches. Gushchin is on Google's Linux kernel team, and the project is written mostly in Rust. The tool watches kernel mailing-list submissions, can review local git changes, and works with LLM providers including Gemini and Claude, according to its public documentation on docs.rs.
The useful number is 53.6%. Sashiko's own documentation says it found 53.6% of bugs in an unfiltered set of the last 1,000 upstream commits with Fixed tags when using Gemini 3.1 Pro. Phoronix reported the same benchmark in March, along with the important caveat: those were bugs that had already made it through human review.
That is not magic. It is still a retrospective benchmark, and false positives are harder to measure. But it is real enough to change the conversation.
The current Sashiko docs describe an eleven-stage review protocol, from analyzing the commit goal through resource management, locking, security review, hardware-specific checks, deduplication, severity estimation, and report generation. The details matter. A vague AI reviewer is easy to mock. A structured tool that points at kernel patches and produces checkable findings is harder to wave away.
The tool is useful, but the workload is real
Torvalds is not saying AI removes the need for maintainers. Frankly, that would be nonsense. The kernel's AI problem is not only whether tools can find bugs, but whether humans can absorb what the tools produce.
Tom's Hardware reported in May that Torvalds said duplicate AI-generated vulnerability reports had made the Linux private security mailing list "almost entirely unmanageable." The issue was not that AI found nothing. It was that different researchers, often using similar tools, kept surfacing the same issues and sending them into a system that depends on human triage.
Noise is work. Anyone who has maintained a busy repository knows this. A bug report that is technically interesting but duplicated, poorly routed, or sent without a useful reproducer still costs time. The Linux project has been pushing AI-detected issues toward public maintainers rather than private security handling when the bugs are not secret, according to the same Tom's Hardware report.
For startups selling AI developer tooling, that is the opening. Do not bother pitching raw bug-finding as if the market has never seen a warning before. The better product decides which findings matter, groups duplicates, gives maintainers enough context, and leaves a human accountable for the patch. Sashiko is already trying to do some of that. The broader market still has plenty to prove.
Accountability stays human
The strongest part of Torvalds' position is also the least fashionable one: the human still owns the code. Tom's Hardware's coverage of Linux AI contribution policy says AI-assisted work is allowed, but contributors must disclose help with an Assisted-by tag, and the person submitting the work remains responsible for it.
That is a standard you can actually use. It does not pretend AI output is pure. It does not treat the tool as radioactive either. You submit the patch, you understand the patch, and you take responsibility when it breaks something.
Plenty of senior engineers have spent the last two years treating AI-generated code as a badge of unseriousness. Some of that skepticism was earned. Vibe-coded pull requests, hallucinated bug reports, and lazy submissions have wasted real maintainer time. But a blanket ban is not engineering. It is identity dressed up as caution.
Linux is choosing the messier path because the useful path is usually messier. Use the tool. Demand disclosure. Keep humans responsible. Build filters for the noise. If you are building software in 2026, that is the position worth copying.
Also read: Apple is targeting a WWDC 2027 debut for its smart glasses and privacy is its sharpest weapon against Meta, AI companies have signed enough nuclear deals to power 7 million homes and uranium stocks are surging, Claude shared chats have been indexed by Google and anyone with a search bar can find them
