Kernel patch review with an 11-step specialist jury

What it does

Sashiko ingests Linux kernel patches from mailing lists, GitHub, GitLab, or local git repositories and reviews them using a fully self-contained Rust application. It coordinates multiple passes with an LLM—Gemini, Claude, Copilot CLI, or others—to evaluate code changes. The end product is a polite, inline-commented email reply formatted for the Linux Kernel Mailing List.

The interesting bit

Instead of a single generic prompt, Sashiko runs an 11-stage protocol that mimics distinct reviewer personas: architectural reviewer, execution-flow tracer, resource-management checker, concurrency auditor, security analyst, and even a hardware engineer scrutinizing register accesses and DMA mappings. Stages 8 through 10 handle deduplication, conflict resolution, and false-positive filtering before generating the final report. The prompts were initially developed by kernel developer Chris Mason and include per-subsystem specializations.

Key highlights

• Found 53.6% of bugs in a test against the last 1,000 upstream commits that had Fixed: tags, using Gemini 3.1 Pro—a rate the project notes is arguably above human level, since all those bugs had already passed human review.
• False positives are claimed to sit within a 20% range, though the project concedes this is based on limited manual review and that LLM output remains probabilistic.
• Fully self-contained: no external agentic CLI dependencies, with support for multiple LLM providers and both a web UI and a local CLI mode.
• Can monitor lore.kernel.org automatically or review local commit ranges without touching your working tree.
• Experimental forge integration for GitHub/GitLab webhooks exists but is explicitly unsupported.

Caveats

• Reviewing patches requires sending patch data and potentially extensive kernel git history to a third-party LLM provider, raising obvious confidentiality and IP concerns the authors explicitly disclaim responsibility for.
• Operational costs can be significant depending on patch volume and LLM pricing; the authors do not take responsibility for runaway API bills.
• The 53.6% bug-catch rate and false-positive metrics come from specific, limited tests and should not be read as guaranteed production performance.

Verdict

Kernel maintainers and contributors drowning in review backlog should look closely; anyone working outside the Linux kernel, or teams unwilling to ship proprietary driver code to a cloud LLM, should look away.