Re: [MAINTAINERS SUMMIT] Annotating patches containing AI-assisted code

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Sep 16, 2025 at 04:30:30PM -0700, Kees Cook wrote:
> On Tue, Sep 16, 2025 at 10:20:22AM -0400, Steven Rostedt wrote:
> > On Mon, 15 Sep 2025 11:01:46 -0700 Kees Cook wrote:
> > 
> > > So, what I mean to say is it's certainly useful to declare "I used a
> > > chisel", but that for long running sessions it becomes kind of pointless
> > > to include much more than a general gist of what the process was. This
> > > immediately gets at the "trust" part of this thread making the mentioned
> > > "human understanding the generated code" a central issue. How should that
> > > be expressed? Our existing commit logs don't do a lot of "show your work"
> > > right now, but rather focus on the why/what of a change, and less "how did
> > > I write this". It's not strictly absent (some commit logs discuss what
> > > alternatives were tried and eliminated, for example), but we've tended
> > > to look only at final results and instead use trust in contributors as
> > > a stand-in for "prove to me you understand what you've changed".
> > 
> > I don't think anyone cares if you used AI to help you understand the
> > situation or to test your work. But if you had a robot build you the fish
> > and you handed that in as your own work, that would be deceptive.
> 
> Right, but the LLMs aren't used strictly as a "workflow" assistant. Do
> we want to say "I used the chisel to remove a big hunk of wood you can't
> see at all in the fish."
> 
> Perhaps the issue is to just over-explain when the LLM is in use for
> now, and we (as a developer community) will collectively figure out what
> turns out to be unimportant or redundant over time. But this can't be
> done with a trailer tag: we're going to need relatively verbose notes
> in the commit log.

This conversation has gone in many directions, it seems to be time to
try and refocus. One way to do so would be to focus on *why* we want
those annotations. That may help then deciding how to best annotate
patches to reach the intended goals.

Personally, I care about knowing the possible LLM origin of a patch for
two main reasons:

- From a maintainer point of view, to focus my reviews. I will look for
  different error patterns, or will interpret patterns differently for a
  human author compared to an LLM.

  This mostly focusses on code produced by LLMs. Usage of LLMs to
  understand an API or review a piece of code before submission is less
  of a concern.

  I don't specifically need a commit trailer for this purpose, a
  free-formed explanation in the commit message would be enough. I would
  rely on trust that submitters will be honest there, the same way we
  rely on trust that a submitter has no malicious or selfish intent in
  general. We of course stay alert to detect breaches of that trust
  today, and I wouldn't see a need to change the process there: we
  already deal with situations where a submitter is determined not to be
  trustworthy.

- From a legal point of view, to detect code that may not be compatible
  with the GPL license. This is still a legal grey area, if we want to
  accept code generated by LLMs without waiting for courts around the
  world to make clear decisions, we can't ignore that there's a legal
  risk.

  For this purpose, a commit trailer would be useful, in order to easily
  list affected commits.

-- 
Regards,

Laurent Pinchart