Re: [MAINTAINERS / KERNEL SUMMIT] AI patch review tools

[Chris Mason <clm@meta.com>]

On 10/9/25 11:08 PM, Krzysztof Kozlowski wrote:
> On 08/10/2025 19:04, Chris Mason wrote:
>> Hi everyone,

[ ... ]

>>
>> https://github.com/masoncl/review-prompts/ 
>>
>> These prompts can also debug oopsen or syzbot reports (with varying
>> success).
> 
> 
> In general, I like this entire idea a lot, because I believe it could
> drop many style or trivial review points, including obsolete/older code
> patterns.
> 
> Qualcomm is trying to do something similar internally and they published
> their code as well:
> https://github.com/qualcomm/PatchWise/tree/main/patchwise/patch_review/ai_review 
> Different AI engines can be plugged, which solves some of the concerns
> in this thread that some are expected to use employer's AI.
> 
> They run that instance of bot internally on all patches BEFORE posting
> upstream, however that bot does not have yet AI-review enabled, maybe
> because of too many false positives?
> 
> I also think this might be very useful tool for beginners to get
> accustomed to kernel style of commit msgs and how the patch is supposed
> to look like.
I really agree with Linus's comments about how much we can and can't
trust AI output, and I've tried to focus my effort for now on high
signal tools that maintainers would be able to use in CI without too
much frustration.

My first prompts told AI to assume the patches had bugs, and it would
consistently just invent bugs.  That's not the end of the world, but the
explanations are always convincing enough that you'd waste a bunch of
time tracking it down.

This is why the prompts spend so many words telling the AI how to prove
a problem is real, and framing the review to assume the patch author is
already an expert.  There's still a bunch of work to do there, but
hopefully it's small subsystem specific rules, or short explanations
that rule out large classes of problems.

At some point, I really want to be able to go back to telling the AI to
assume the patch is wrong, but it feels really far off.

I hadn't seen qualcomm's tools, but I think it's a really interesting
and slightly different use case.

If you're standing up internal gatekeepers to make sure early reviews
are done and internal process is followed, it's a chance to shift the
review bias toward teaching relatively new contributors about the kernel
and helping them research alternative approaches.  The gatekeepers still
need a person in the loop, but this does fit with the maintainer usecase
I've been targeting, it's just someone that might not be getting
external credit for their work.

-chris