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

[Kees Cook <kees@kernel.org>]

On Tue, Aug 05, 2025 at 05:38:36PM +0200, Jiri Kosina wrote:
> I believe we need to at least settle on (and document) the way how to 
> express in patch (meta)data:
> 
> - this patch has been assisted by LLM $X
> - the human understanding the generated code is $Y

A lot was covered in this thread already, but I noticed that much of the
discussion ended up looking at LLM assistance from the perspective of
"one shot" execution, either as a comparison against other "mechanical"
transformation tools (like Coccinelle) or from the perspective of bulk
code creation ("the LLM wrote it all").

What I didn't see discussed, and where I think there is substantially
greater utility to be had from LLMs, is contributions created during long
running sessions. Such sessions might include more than "just" writing
code, like doing builds, running tests, or helping with debugging (like
driving gdb analysis of kernel crashes). I think this scenario makes
things much more complex to "declare" in a commit log.

(Some examples from me: "security fix I drove the LLM to make"[1], "I
worked interactively with an LLM to construct API testing coverage"[2]
and "I used the LLM to find missed conversion instances and do cross-arch
build and test validation"[3].)

The awkward analogy I have is that of carving a fish out of drift
wood: I picked the wood, and then used a chainsaw, chisel, and knife
to remove everything that wasn't the fish I wanted. Normally only the
final result is shown. For more complex creations, I might describe why
I made various choices. If I'm asked to describe "how I used the chisel"
it quickly becomes murky: it was one of several tools used, and its use
depended on other tools and other choices and the state of the sculpture
at any given time.

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".

It seems like a "show your work" approach for commit logs would be
valuable regardless of tools involved. I've been struggling to find a
short way to describe this, though. Initially I thought we wanted to
ask "Why is this contribution correct?" but we actually already expect
that to be answered in the commit log. We want something more specific,
like "How did you construct this solution?" But that is unlikely to be
distilled into a trailer tag.

-Kees

[1] https://lore.kernel.org/lkml/20250724080756.work.741-kees@kernel.org/
[2] https://lore.kernel.org/lkml/20250717085156.work.363-kees@kernel.org/
[3] https://lore.kernel.org/lkml/20250804163910.work.929-kees@kernel.org/

-- 
Kees Cook