Re: Merging AI-generated program code

>> It's a fact that AI assistance makes it /possible/ to generate large 
>> amounts of working code that the human contributor doesn't fully 
>> understand. This was practically impossible before, so it creates a 
>> new situation.
>>
> I can easily produce code manually, and not understand it. Or worse, 
> live in the illusion to understand what i am doing, but being totally 
> wrong in this.
>
Yes. This tends to show up in the reviewers' scrutiny. A problem arises 
by the possibility of generating large quantities of such code.

It's not easy (I think) to manually produce hundreds of lines of C++ 
code changing LilyPond's inner workings and still get a version of the 
program that successfully passes all tests.

> Currently the amount of MRs, especially when not counting those which 
> seem to come from what looks to me like being the core lilypond team, 
> which rightfully could be trusted more than MRs from outsiders, 
> obviously, is rather underwhelming.
>
At the moment, the rate of contributions is low; this has varied in 
recent years.

I, for one, are not member of any "core lilypond team" that I know of. I 
obtained write access to the repository after a few successfully merged 
MRs, but otherwise, I'm just an enthusiastic LilyPond user who, over 
time, did a bit of "learning on the job" regarding contributing. This 
route is open to anyone without having to apply to become a core team 
member or some such; it'll probably be much faster for someone with 
actual programming experience (which I don't really have).

The circumstances of starting to contribute changed somewhat with AI 
assistance, since the stage of "learning about LilyPond's working [and 
the currently established MR and review process] while creating 
comparatively easy MRs" is not a natural necessity anymore. This is what 
this mailing list thread is about, as far as I can see.

>> I view Dan's question as an honest attempt do find a solution. I'm 
>> surprised that you construed his e-mail (which also contained the 
>> sentence "I just wouldn't want the uncertainty to last so long that a 
>> capable contributor gets frustrated and leaves.") as an expression of 
>> "academic AI hate" or "something personal".
>>
> I cannot separate this email from other communication which did 
> already happen. If "capable" was for me, nice, but then all the other 
> explicit and implicit pejoratives against persons and code apply to me 
> too. And enough details were mentioned which can only apply to me, or 
> rather my MR !3058

There's no doubt (and Dan acknowledged this) that your MRs trigged the 
current mailing list thread. But as others and I have tried to point 
out, your MRs are not actually the object of the current discussion; 
they only showed the need to find a stance on how to deal with 
AI-assistede contributions in LilyPond in general.

> If this is to mean that any code needs to be read by contributors and 
> reviewers, we can agree on this. But then any discussion about how 
> much bias is justified against code which comes with whatever support 
> from whatever kind of AI (which is how i understand the wordings here) 
> is completely obsolete.
>
I'm glad we agree. But it's not as much bias against AI-assisted 
development here as the need to deal with the possibility (that became 
quite real for other projects as far as I know) of dealing with large 
amounts of code.
>
> And i hope that on can understand that it adds only to the frustration 
> if one spends quite some time on 20 years of silently cursing about 
> #34 but never complaining (always thinking "i had better write code 
> than complain"), observing that other attempts to solve this by even 
> the most lilypond experienced coders did not materialize over many 
> years, external attempts also gave up (e. g. !3002) and one finally 
> sees a way to propose a solution (nota bene: not claiming a 100% one) 
> and hands it in, expressedly as an unfinished proposal of an idea, 
> with some working (!) code but with the question if before all any 
> further investment into this makes sense in the eyes of the core 
> developpers and project owners, is only met by "the git history is not 
> perfectly clean, we won't evaluate even the concept" or "there was 
> some assistance by AI, so we are to assume that he never read his code 
> and doesn't understand it anyway"
>
I understand the frustration you describe, but let me point out that in 
both sentences, the part after the comma is//your interpretation. You 
were asked to clean up the git history, and it was suggested to discuss 
the general approach not in a merge request (which is usually used for 
code review). If I understand you correctly, we both agree that you 
sought feedback on the general concept, not an actual line-for-line code 
review. And given the large quantity of code, I can understand that a 
reviewer asks for some background and explanations before diving into 
the actual code.
>
> and pseudo-academic meta discussions like this one, or about if 
> creating code is allowed to change from how it was the ideology in the 
> 80s.
>
Sigh. I second David's request about avoiding the use of hyperbole.

Lukas