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

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Tue, 12 Aug 2025 09:38:12 +0100
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Mon, 2025-08-11 at 14:46 -0700, Paul E. McKenney wrote:
> > On Fri, Aug 08, 2025 at 10:31:27AM +0200, Krzysztof Kozlowski wrote:  
> > > On 05/08/2025 19:50, Sasha Levin wrote:  
> > > > On Tue, Aug 05, 2025 at 05:38:36PM +0200, Jiri Kosina wrote:  
> > > > > This proposal is pretty much followup/spinoff of the discussion
> > > > > currently happening on LKML in one of the sub-threads of [1].
> > > > > 
> > > > > This is not really about legal aspects of AI-generated code and
> > > > > patches, I believe that'd be handled well handled well by LF,
> > > > > DCO, etc.
> > > > > 
> > > > > My concern here is more "human to human", as in "if I need to
> > > > > talk to a human that actually does understand the patch deeply
> > > > > enough, in context, etc .. who is that?"
> > > > > 
> > > > > 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
> > > > > 
> > > > > We might just implicitly assume this to be the first person in
> > > > > the S-O-B chain (which I personally don't think works for all
> > > > > scenarios, you can have multiple people working on it, etc),
> > > > > but even in such case I believe this needs to be clearly
> > > > > documented.  
> > > > 
> > > > The above isn't really an AI problem though.
> > > > 
> > > > We already have folks sending "checkpatch fixes" which only make
> > > > code less readable or "syzbot fixes" that shut up the warnings
> > > > but are completely bogus otherwise.
> > > > 
> > > > Sure, folks sending "AI fixes" could (will?) be a growing
> > > > problem, but tackling just the AI side of it is addressing one of
> > > > the symptoms, not the underlying issue.  
> > > 
> > > I think there is a important difference in process and in result
> > > between using existing tools, like coccinelle, sparse or even
> > > checkpatch, and AI-assisted coding.
> > > 
> > > For the first you still need to write actual code and since you are
> > > writing it, most likely you will compile it. Even if people fix the
> > > warnings, not the problems, they still at least write the code and
> > > thus this filters at least people who never wrote C.
> > > 
> > > With AI you do not have to even write it. It will hallucinate,
> > > create some sort of C code and you just send it. No need to compile
> > > it even!  
> > 
> > Completely agreed, and furthermore, depending on how that AI was
> > trained, those using that AI's output might have some difficulty
> > meeting the requirements of the second portion of clause (a) of
> > Developer's Certificate of Origin (DCO) 1.1: "I have the right to
> > submit it under the open source license indicated in the file".  
> 
> Just on the legality of this.  Under US Law, provided the output isn't
> a derivative work (and all the suits over training data have so far
> failed to prove that it is), copyright in an AI created piece of code,
> actually doesn't exist because a non human entity can't legally hold
> copyright of a work.  The US copyright office has actually issued this
> opinion (huge 3 volume report):
> 
> https://www.copyright.gov/ai/
> 
> But amazingly enough congress has a more succinct summary:
> 
> https://www.congress.gov/crs-product/LSB10922
> 
> But the bottom line is that pure AI generated code is effectively
> uncopyrightable and therefore public domain which means anyone
> definitely has the right to submit it to the kernel under the DCO.
> 
> I imagine this situation might be changed by legislation in the future
> when people want to monetize AI output, but such a change can't be
> retroactive, so for now we're OK legally to accept pure AI code with
> the signoff of the submitter (and whatever AI annotation tags we come
> up with).
> 
> Of course if you take AI output and modify it before submitting, then
> the modifications do have copyright (provided a human made them).

On my tests with AI, humans need to modify it anyway. It reminds me
the (not so) good old code generators we had in the past: AI-generated
code, even when it works, it usually have unneeded steps and other
caveats that require human interaction to clean it up and fix.

I got good results with AI for things like generating unit tests, but
once tests are generated, still 50%-60% of them fails because AI
did stupid things, like not counting whitespaces right, and even
sometimes forgetting parameters and arguments.

From several aspects, it looks like contact a very junior intern
that knows a programming language and code really fast, but it has
no glue about how to generate a production quality level code.

After dozens of interactions, the code can be used as the bases for
a senior professional to modify it and have something ready for
merging.

The net result is that:

1. AI alone doesn't produce a ready-to-merge code;
2. Lots of refinement requirements made by humans to shape the code 
   into something that actually works;
3. During AI interaction, human has to intervene several times to
   avoid AI to hallucinate. Sometimes, it also has to close the
   chat and open again - or even use a different LLM model when
   AI can't converge;
4. At best scenario, human still needs to read the code and carefully
   modify for it to make sense; at worse, it has to write its own
   code, eventually using some suggestions from the AI hallucination.

Heh, there are exceptions: if one asks AI to produce a hello world
code (or something that "plays by the book" - e.g. when AI can use
thousands of references from code in public domain) the code is not 
that bad: it is just a variant of some public domain code.

Thanks,
Mauro