[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