[MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc
Jonathan Corbet <[email protected]> Thu, 16 Jul 2026 09:09:27 -0600
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <[email protected]> |
The use of LLMs in the development process appears to be a clear theme for
the upcoming summit. On top of what others have already suggested, I think
we may want to consider these questions:
- Do we want to continue naming specific LLMs in the Assisted-by tags, or
put something more generic? I *think* that this thread:
https://lore.kernel.org/all/[email protected]/
reached a consensus that "Assisted-by: LLM" was better than what we
require now, but it might be good to ratify that in this setting.
- There is a lot of LLM-generated code that lacks an Assisted-by
disclosure. Often, that seems to be the result of ignorance of the
rules; those contributors will start adding the tags when informed of the
requirement. But others just lie about it. A rule that is widely
ignored does not help anybody. Can we come up with a way to get better
compliance, or should we just drop the tag entirely?
- There are many first-time contributors coming in with LLM-generated
patches. At times, I could swear that every one of them is focused on
documentation typos, but the truth of the matter is that they are
reaching into subsystems all over the kernel. We have some brand-new
contributors making significant changes to dozens of subsystems. An
experienced developer would be hard-put to truly understand what those
changes are doing; a newcomer is unlikely to have that understanding,
and is unlikely to be around to fix eventual problems.
Our maintainers are not scaling to handle this new flood, and I fear we
are going to see some unfortunate things merged. One LLM-driven newcomer
recently nearly succeeded in establishing himself as the maintainer of
lib/. How do we hold the line against this stuff while remaining open to
new developers?
- Our process is becoming increasingly dependent on proprietary tools. We
have done that before and, in 2005, it went pretty badly for us - and
could have been worse. How do we prepare for the inevitable rugpull? I
raised this last year, and it was largely brushed off, but I still think
it's something we should be concerned about.
That's probably enough :)
jon