Re: Merging AI-generated program code

Hi Dan,

thanks for bringing this up.

> Now, I want to ask whether anyone sees any issue with merging 
> AI-generated program code.
I think there are all sorts of issues, and I won't go into the broader 
issues regarding the copyright status of AI-generated code (which might 
contain copyrighted bits of training material), the environmental impact 
of AI data centers etc. Instead, I'll focus on the question of quality 
of code contributions, but these of course automatically pertain to how 
that quality gets assessed.
> This is somewhat urgent in the sense that we have such an MR in draft, 
> though of course we could delay it until there is certainty.  I just 
> wouldn't want the uncertainty to last so long that a capable 
> contributor gets frustrated and leaves.
>
> To my knowledge (and I have been paying only minimal attention), the 
> FSF views AI-assisted contributions to GNU projects as potentially 
> problematic but has not established a policy.
>
> As a reviewer, I strongly desire two things:
>
> 1. openness about the origin of the code I'm reviewing
> 2. accountability of the human submitter (not reviewers)
>    for the code that is merged
>
> For the MR that is in draft now, there were tells in the patch, but I 
> had to ask the submitter twice before he confirmed that it was 
> "AI-assisted."

In my opinion, LilyPond should only contain code that a human 
understands. It is essential that the creator of a MR understands their 
code, and it is desirable that a code reviewer understands the code as 
well (the latter, of course, depending very much on the time and 
generosity of people willing to do reviews). This is not just a question 
about AI contributions: It means that LilyPond also shouldn't contain 
human-written code of the "I added that line and then the problem 
somehow went away, knock on wood" type. It's of course hard to enforce 
this, but a thorough review where questions can be raised and must be 
dealt with makes it more probable.

> To streamline this in the future, I propose configuring a template for 
> default MR descriptions something like this:
>
>     ##### Description
>
>     <!-- Describe your motivation and your work briefly
>     to orient reviewers.  If you have not described
>     your commits well, go back and do that first. -->
>
>     ##### Question
>
>     What percentage of this work is AI-generated?  <!-- 0-100 -->
>
> Do you think that would effectively address that specific concern?

Of course, since the number given will (according to your proposal) 
influence how the MR is dealt with, we depend on getting an honest 
answer to that question. I don't want to seem paranoid, but maybe it 
would be wise to add - somewhere in the CG - a statement along the lines 
of: Commits with non-disclosed AI-generated code get refused (or may get 
reverted later).

In the discussions of the current MR I noticed the term "AI-assisted". 
Maybe it would we a good idea to distinguish various kinds and degrees 
of AI assistance: IIUC, not every way of using an LLM during development 
leads to longer, coherent blocks of AI generated code.

> Therefore, I suggest adopting a new policy: AI-generated program code 
> does not automatically move forward without a human reviewer's 
> acknowledgment.  It should be full acknowledgment, not, for example, 
> "C++ LGTM; don't know about Scheme."
>
> It would fall to the "patch meister" to help people follow this policy 
> and to allow sensible exceptions, such as if a contributor with a good 
> record vouches for the quality of his own AI-generated submission in 
> an area where he has developed expertise.

I support this. This basically means that you either have to motivate 
reviewers to look at your code, or you have to build a reputation by 
smaller patches that both show and increase your familiarity with the 
codebase.

Lukas