[MAINTAINERS SUMMIT] Revisiting the "AI Coding Assistants" page

Dear committee members,

There has been significant discussion in the past year about LLM use
in the Linux kernel. One of the documents that have come out of this
is the "AI Coding Assistants" page in the documentation.[1] A LLM-assisted
patch series I submitted prompted a discussion about its content.[2]
Brauner writes:

    I remain very confused by our coding assistant contribution guidelines.
    I'm going to be a bit polemic now but this seriously in good faith.
    Why precisely do we require all this detailed information about what
    specific coding assistant was used?

This point is relatively minor, but the ensuing discussion unveiled some important
points of disagreement that I think would be useful to try to discuss at
the summit. A summary of some of the opinions and pain points:

- Should we keep the assisted-by tag? Jeff Layton proposed to get rid of them
  in a separate thread,[3] Greg KH and others, on the other hand, found them
  very useful in their workflow and opposed the idea.
- This discussion lay bare that the concern is about what signal to noise
  the tags bring, but what is really wanted (at least by some) is to know
  WHAT was done with the LLM, so that reviewers can use that information
  to scrutinize or de-prioritize. David Hildenbrand, for instance, suggested
  we could use: Assisted-by: LLM # automated removal of useless blabla.
  Is this a requirement we want?
- Are maintainers/reviewers allowed to de-prioritize patches of unknown or fairly new
  contributors that involve deep changes in core systems, where those changes
  "smell" like an LLM was heavily involved and the author did not understand
  what he submitted. (This point was brought up by Lorenzo Stoakes, among others.)
- Should we strengthen the wording of the current "AI Coding Assistants" page, to
  make clear that submitters must fully comprehend the code they submitted, and
  code assistants may only be used to "to perform the grunt work." ([4], from
  systemd)

To be clear, this discussion is not about doubting the technical merit of LLMs
or even about the ethical concerns in using them. And Linus has already made it
clear that the kernel will not adopt an anti-AI stance.

Still, as a mentor in the Linux Kernel Mentorship Program (led by Shuah Khan),
which accepts and supports people from all over the world, I do wish to express
my worry about how we can keep developing the kernel accessible to everyone.
And if I remember correctly, these concerns are shared by Khan and Corbet.
Tools are tools, but with the rising cost of LLM usage, we may create an uneven
playing field. However, this is a separate concern that may not be process-related
enough to be discussed at the summit.

Best wishes,
Jori.

[1]: https://docs.kernel.org/process/coding-assistants.html
[2]: https://lore.kernel.org/linux-fsdevel/[email protected]/T/#mcfa3addaee1383f62ae1341824cd37c45f9d45bf
[3]: https://lore.kernel.org/linux-fsdevel/[email protected]/
[4]: https://lore.kernel.org/linux-fsdevel/20260702-bahnen-ertappen-verspannungen-0eaaf1e3f5af@brauner/