Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process

Roman Gushchin <[email protected]> Fri, 17 Jul 2026 14:14:49 -0700
Newsgroups dev.linux.lists.ksummit
Message-ID <[email protected]>
> On Jul 17, 2026, at 2:05=E2=80=AFPM, Krzysztof Kozlowski <[email protected]>=
 wrote:
>=20
> =EF=BB=BFOn 15/07/2026 18:55, Roman Gushchin wrote:
>> * Prompt development and testing.
>> Currently, prompts are maintained in two GitHub repositories and are
>> changed manually or with the help of AI coding agents. However, there is
>> no established practice for testing them, especially across various LLM
>> models. At the last LSFMMBPF conference, there was a discussion about
>> moving them into the kernel tree. I see some pros and cons to this
>> approach, but the ownership and testing models are not entirely clear.
>=20
> Prompts in a meaning how to parse kernel, work with it or produce
> reports: yeah, sure.
>=20
> Prompts teaching kernel code: I don't think so. I find it really
> incorrect approach to create a dedicated and duplicated basic knowledge
> for LLMs, instead of focusing on knowledge for developers. I understand
> that LLM has to be taught basics of C [1], but we should not duplicate
> kernel coding style or kernel rules into LLM-only instructions. Instead:

I agree.
I also experiment with Sashiko auto-creating prompts based on human
feedback in emails and initial results look promising. So maybe we don=E2=80=
=99t
even need to write too much manually for LLMs.

Thanks!

>=20
> 1. Fix docs or kerneldoc to have these properly documented,
> 2. Instruct LLM to read these documents.
>=20
> We do have tribal knowledge and it should be our kernel docs for the
> developers, first of all. If the knowledge is so important for LLM that
> it must be duplicated in prompts (just read some of the subsystem
> specifics at [2]), then maybe better add it to some guide "writing HID
> driver" or "common mistakes in Bluetooth", so developer writing such
> driver that will find it. And LLM too.
>=20
> I keep growing such codified and condensed (keep as short as possible)
> rules for subsystem I am part of [3] and LLM should read that one. LLM
> does not need dedicated doc, different than developers need. Well,
> except teaching C. [1] :)

This is awesome actually!=