Google Engineers Launch "Sashiko" for Agentic AI Code Review of the Linux Kernel
phoronix.com
phoronix.com
For an example of a review (picked pretty much at random) see: https://sashiko.dev/#/patchset/20260318151256.2590375-1-andr...
The original patch series corresponding to that is: https://lkml.org/lkml/2026/3/18/1600
Edit: Here's a simpler and better example of a review: https://sashiko.dev/#/patchset/20260318110848.2779003-1-liju...
I'm very glad they're not spamming the mailing list.
Rust > C and GNU/Linux should be Rust.
And what were they supposed to use in 2006? Free Pascal? Ada?
And he's so right. I didn't think like that back then, but new/delete (which have to be overloaded for kernel) behind allocators behind containers, vtables, =0, uninitialized members, unhandled ctor errors, template magic, "sometimes rvo", compiler hints, "sometimes reinterpret cast", 3rd party libraries, it would have been a disaster 20 years ago. Now he's being nice to Rust partially to spite that lang I love some more.
Unless there is a CI that fails immediately when these checks fail, and it is not possible to bypass/override, then of course quality in the codebase improves significantly.
But that is very hard to give business results, in terms of ROI, 99.9% of the PMs will sweep these under the rug, because of unclear ROI.
Another remark I have to make is that, these things should be in a cloud/container (isolated environment) somewhere. Because I know several people who has their git commit aliased with no-precommit-hooks, because well, otherwise they complain that it is too slow. (Slowness is another issue that can be improved, but again, less visible ROI than just adding the command-line switch)
Nitpicking on this though:
> "In my measurement, Sashiko was able to find 53% of bugs based on a completely unfiltered set of 1000 recent upstream issues based on "Fixes:" tags (using Gemini 3.1 Pro). Some might say that 53% is not that impressive, but 100% of these issues were missed by human reviewers."
That'd assume 100% of the issues that were fixed and used for training were not fixed following a human review. I don't buy it: it's extremely common to have a dev notice a bug in the code, without a user having ever reported the bug.
I think the wording meant to say: "... but 100% of these issues were first missed by humans".
My point being: the original code review by a human ain't the only code review by a human. Or put it this way: it's not as if we were writing code, shipping it, then never ever looking at that line of code again unless a bug report were to come out. It's not how development works.
I think the table might be slightly inside-out? The Status column appears to show internal pipeline states ("Pending", "In Review") that really only matter to the system, while Findings are buried in the column on the far right. For example, one reviewed patchset with a critical and a high finding is just causally hanging out below the fold. I couldn't immediately find a way to filter or search for severe findings.
It might help to separate unreviewed patches from reviewed ones, and somehow wire the findings into the visual hierarchy better. Or perhaps I'm just off base and this is targeting a very specific Linux kernel community workflow/mindset.
Just my 1c.
Reviewers are more likely to instead subscribe to get the review inline, and then potentially incorporate that with their feedback.
That's cool. Another interesting metric, however, would be the false positive ratio: like, I could just build a bogus system that simply marks everything as a bug and then claim "my system found 100% of all bugs!"
In practice, not just the recall of a bug finding system is important but also its precision: 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.
(Also tests can be focused per defect.. which prevents overload)
From some of the changes I'm seeing: This looks like it's doing style and structure changes, which for a codebase this size is going to add drag to existing development. (I'm supportive of cleanups.. but done on an automated basis is a bad idea)
I.e. https://sashiko.dev/#/message/20260318170604.10254-1-erdemhu...
Having said that, if it can save maintainers time it could be useful. It's worth slowing contribution down if it lets maintainers get more reviews done, since the kernel is bottlenecked much more on maintainer time than on contributor energy.
My experience with using the prototype is that it very rarely comments with "opinions" it only identifies functional issues. So when you get false positives it's usually of the form "the model doesn't understand the code" or "the model doesn't understand the context" rather than "I'm getting spammed with pointless advice about C programming preferences". This may be a subsystem-specific thing, as different areas of the codebase have different prompts. (May also be that my coding style happens to align with its "preferences").
> This project was built using Gemini CLI
Seems to be a well funded effort though so maybe it’s better?
What does this mean?
>"good catch - thanks for pointing that out"
We've already seen how bug bounty projects were closed by AI spam; I think it was curl? Or some other project I don't remember right now.
I think AI tools should be required, by law, to verify that what they report is actually a true bug rather than some hypothetical, hallucinated context-dependent not-quite-a-real-bug bug.