Google engineers release “Sashiko”, an AI code review system for Linux kernel

An AI system has appeared that automatically reviews the code quality of Linux kernels. Sashiko was developed by Roman Gushchin, an engineer on Google’s Linux kernel team, and was officially announced on March 17, 2026 on the LKML (Linux Kernel Mailing List). It is implemented in Rust and was built using the Gemini CLI. The GitHub repository (sashiko-dev/sashiko) is published on Apache 2.0.

The name “Sashiko” comes from a Japanese embroidery technique. The name suggests that automatic review strengthens the quality of the kernel, similar to sashiko reinforcing cloth.

Linux kernel development and mailing list

Linux kernel development is done on a mailing list basis, rather than on a mechanism like GitHub’s pull requests. Developers post patches (code changes) via email, and other developers reply and review them via email. An archive of this exchange is available at lore.kernel.org.

Sashiko automatically obtains patches from lore.kernel.org. The NNTP protocol is used for acquisition. NNTP is a protocol originally designed for Usenet (an electronic bulletin board network that has been around since the 1980s), and is a mechanism for efficiently distributing and subscribing to large numbers of posts. Since lore.kernel.org supports access via NNTP, Sashiko uses this to detect new patch postings in real time.

Flow from patch acquisition to review

graph TD
    A[開発者がパッチをメールで投稿] --> B[lore.kernel.orgに<br/>アーカイブされる]
    B -->|NNTP経由で<br/>新着パッチを検知| C[Sashiko]
    C --> D[カーネルリポジトリから<br/>関連コードを取得]
    D --> E[パッチ + 周辺コードを<br/>LLMに送信]
    E --> F[4段階のレビュー実行]
    F --> G[結果をSQLiteに保存]
    G --> H[sashiko.devとCLIで<br/>結果を閲覧]

If you set up a subsystem to monitor (memory management, network, etc.), patches posted to the corresponding mailing list will be automatically added to the queue. You can also manually import patches from your local git repository.

After acquiring a patch, Sashiko retrieves the surrounding context (related functions, type definitions, commit history) from the kernel repository and incorporates it into the prompt. Since it is difficult for the AI to understand the context if only the patch diff is used, the design is designed to increase the accuracy of the review by including surrounding code.

4 level review

Reviews consist of multiple perspectives similar to those seen by human reviewers.

Review stage	Main detection targets
Architecture Verification	Is the design intent of the patch appropriate and does it conflict with existing design principles?
Security Audit	Memory Safety/Privilege Escalation/Buffer Overflow
Resource management analysis	Memory leaks, file descriptor leaks, lock acquisition and release
Concurrency analysis	Race conditions, deadlocks, and memory ordering issues

Each subsystem has a different emphasis, so use dedicated prompts accordingly. These are maintained by Chris Mason in a separate repository (masoncl/review-prompts).

The output is saved in a JSON structure as a list of issues with severity (critical/high/medium/low).

Assumption of bug detection rate of 53.6%

There is an important premise behind the bug detection rate of 53.6% cited in the announcement.

The test target was 1,000 Linux kernel commits with the “Fixes:” tag (randomly sampled without filters). The “Fixes:” tag is a marker that says “this commit fixes a previous bug,” meaning it identifies the commit that contained the bug. We ran Sashiko on the patch at the time the bug was introduced and measured how many bugs it was able to detect.

The point is that all of these bugs were merged after passing human code review. In other words, Sashiko detected 53.6% of the problems that human reviewers missed.

Another number is listed in the README: 45.2% (less than 20% false positive rate). Gushchin acknowledges that results vary depending on measurement conditions, and adds that there are some types of bugs that are inherently difficult to detect with static code reviews, such as build errors and performance issues.

Compatible with both Gemini and Claude

In production environments, Gemini is used and paid for by Google, but it also supports Anthropic Claude.

Settings	Gemini	Claude
Provider environment variables	SASHIKO_AI__PROVIDER=gemini	SASHIKO_AI__PROVIDER=anthropic
API key	GOOGLE_API_KEY or LLM_API_KEY	ANTHROPIC_API_KEY
Model example	gemini-3.1-pro-preview, Gemini Flash	claude-sonnet-4-5
Context window	—	200K tokens (180K safety margin setting)

On the Claude side, prompt caching (TTL 5 minutes) and automatic retry when rate limit is implemented.

Rust implementation and build

Requires Rust 1.86 or higher.

git clone --recursive https://github.com/sashiko-dev/sashiko.git
cargo build --release

The storage is SQLite, which manages patch metadata and review results. Review results can be viewed from both the sashiko.dev web interface and CLI.

The project has over 687 commits and over 13 contributors, including Linux kernel maintainers and networking experts (including prompt repository contributors).

Reaction with LKML and Linux Foundation transfer

The LKML announcement (Message-ID: 7ia4o6kmpj5s.fsf@castle.c.googlers.com) received an immediate response, with prominent kernel developers including Lorenzo Stoakes, SeongJae Park, and Chris Mason joining the discussion.

The project is scheduled to be transferred to the Linux Foundation. Ownership becomes independent from individuals and specific companies.

The roadmap includes integration with b4 (mailing list patching tool) and hkml (kernel mailing list client). Additionally, a feature is planned that will allow review results to be sent directly via email as a reply to patch submissions.

This would allow patch authors to receive review results in near real time. Furthermore, Sashiko clearly states that “the output is probabilistic,” and it is positioned as a complementary tool for human reviewers.