HN

Comments (39)

• Menu

  rwmj
  Better to link to the site itself, or one of the reviews?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/1600Edit: 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.
• Menu

  kleiba
  > Sashiko was able to find around 53% of bugsThat'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.
• Menu

  withinrafael
  Looks cool, but this site is a bit difficult for me to grok.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.
• Menu

  simianwords
  > Roman reports that Sashiko was able to find around 53% of bugs based on an unfiltered set of 1,000 recent upstream Linux kernel issues with "Fixes: " tagWhat does this mean?
• Menu

  throwa356262
  I find it interesting that this is written in Rust (not golang) and co-authored with Claude (not gemini)
• Menu

  monksy
  I think this is a great and interesting project. However, I hope that they're not doing this to submit patches to the kernel. It would be much better to layer in additional tests to exploit bugs and defects for verification of existance/fixes.(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...
• TacticalCoder
  Looks like a great new tool to help ship less bugs!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.
• ChrisArchitect
  https://github.com/sashiko-dev/sashiko (https://news.ycombinator.com/item?id=47427996)
• michaelchen58
  nice execution. the demo video sold me more than the text
• mika-el
  the separation between who writes and who reviews is the whole thing. I do same at smaller scale — one model writes code, different model reviews it. self-review misses things, same reason you don't review your own PRs
• goatyishere25
  cool idea. curious how you're handling the cold start problem
• takahitoyoneda
  [dead]
• Heer_J
  [dead]
• ratrace
  [dead]
• Menu

  4fterd4rk
  oh god can we not
• quantium1628
  b2b or b2c? feels like it could go either way
• Menu

  shevy-java
  Now they want to kill the Linux kernel. :(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.
• qainsights
  They would have completely redesigned Google Gerrit.