Sashiko's 9-Stage Review Aims to Reduce Kernel Maintainer Overload

The Linux kernel's code review problem is a volume problem. Thousands of patches hit the mailing list every week, and the humans who review them are burning out. Roman Gushchin, a Google kernel engineer, has spent the last several months building a different kind of assistant — one that reads every patch, runs it through nine stages of specialized review, and posts findings directly to the list. He calls it Sashiko, after the Japanese reinforcement stitching technique.

Sashiko — announced on LinkedIn by Gushchin and first reported by The Register — monitors the Linux Kernel Mailing List via lore.kernel.org and processes every submission through a multi-stage protocol. It is written in Rust, licensed under Apache 2.0, and ownership is being transferred to the Linux Foundation. Google is funding the token costs for the public instance; the code itself lives at github.com/sashiko-dev/sashiko.

The nine-stage review protocol is the core technical contribution. Rather than running a patch through a generic LLM call, Sashiko breaks review into distinct stages: architectural analysis and UAPI breakage checks; implementation verification against the commit message; execution flow tracing for logic errors and missing return checks; resource management for memory leaks and use-after-free; locking and synchronization including RCU violations; security audit for buffer overflows and information leaks; a hardware-specific stage for driver and DMA code; cross-stage deduplication; and finally report generation as a polite, standard LKML-formatted email reply. Subsystem-specific prompts — initially developed by Chris Mason and available at github.com/masoncl/review-prompts — give the system domain knowledge about Linux kernel patterns rather than generic code review.

"In my measurement, Sashiko was able to find 53 percent of bugs based on a completely unfiltered set of 1000 recent upstream issues based on Fixes: tags (using Gemini 3.1 Pro)," Gushchin wrote. "Some might say that 53 percent is not that impressive, but 100 percent of these issues were missed by human reviewers."

That is the confidence theater question Sonny flagged. The number sounds good until you look at it sideways. Every one of those bugs had already passed human review — which means human reviewers caught the obvious stuff and Sashiko caught the subtler things that slipped through. That is genuinely useful. But it also means the system is finding bugs in code that experienced maintainers reviewed and approved. Whether that is a damning indictment of human review or a testament to the limits of any single pass through complex code is, as one Hacker News commenter put it, "not quite as clean a result as it first appears."

The false positive question is where the rubber meets the road for real-world usefulness. The project says its false positive rate sits "within 20 percent range" based on limited manual reviews, with most of that being gray zone findings. On thousands of patches per week, even a 20 percent false positive rate means a significant volume of noise landing in maintainer inboxes. "If human reviewers get spammed with piles of alleged bug reports by something like Sashiko, most of which turn out not to be bugs at all, that noise binds resources and could undermine trust in the usefulness of the system," a Hacker News commenter noted. The system is designed to deduplicate findings across stages and minimize low-confidence reports — stage eight explicitly attempts to logically prove or disprove findings before they surface — but how that holds up at scale against the full LKML patch volume is the open question.

The infrastructure around Sashiko is serious. Google is not just sponsoring compute; the project has been used internally at Google for some time. "We have been using it internally at Google for some time, and it helped to discover a large number of real issues," Gushchin told The Register. The Linux Foundation ownership means the project is not a Google-only asset — anyone can run their own instance, and the Apache 2.0 license means commercial use is permitted. The system supports Gemini and Claude as backends, with an open provider interface for others.

Chris Mason's review-prompts are the underappreciated piece here. Mason, a longtime kernel developer who created the Btrfs filesystem, has been building subsystem-specific review prompts for the kernel for some time. Sashiko did not invent the per-subsystem prompt approach — it built infrastructure around it. That distinction matters for anyone thinking about replicating this for other large codebases.

The HN discussion surfaced an interesting structural complaint about the web interface — one reviewer found the status column showing internal pipeline states more prominent than the actual findings, with critical and high severity bugs buried below the fold. That is a UX issue rather than a fundamental problem with the approach, but it is telling: the kernel community is actually looking at this and trying to use it.

What is not clear: whether the 20 percent false positive estimate holds at full LKML volume, how maintainers are responding to the automated emails in practice, and whether Google's funding commitment is long-term or a launch-phase push. The token costs of running a nine-stage LLM review pipeline against every kernel patch are not trivial.

The bigger framing: this is the Linux kernel, arguably the most scrutinized codebases on earth, still running largely on volunteer maintainer attention and a mailing list that predates most modern software tooling. If AI review can meaningfully reduce the number of bugs that reach users — without turning every patch queue into a confidence theater exercise — it changes the calculus for every other large open source project facing the same review bottleneck. That is worth watching.