Re: Merging AI-generated program code

Dan Eble <[email protected]> Mon, 1 Jun 2026 12:39:26 -0400
Newsgroups gmane.comp.gnu.lilypond.devel
Message-ID <[email protected]>
On 2026-06-01 07:14, Luca Fascione wrote:
> Thinking about it, it seems to me that in this case it's probably wise 
> to document in the submission which agents' help (name and versions are 
> probably ideal) was used to produce the submitted text, and to
> what degree the machine-generated code was retained as-is or modified. 
> Aside from the curiosity, this has to do with potential legal issues: if 
My heart is with you on record-keeping, but I don't foresee this being 
more useful in practice than a statement that the work is >0% AI-generated.

I'm not contributing LLM-generated content to LilyPond yet -- I've been 
focusing on improving code review -- but I would experience "friction" 
if I had to describe my local workbench in one line and keep it up to 
date.  I'm using open-source tools and open-weight models, and something 
is updated almost every day.  For a typical commit, it might even be 
impossible to describe my workbench both accurately and precisely.

Of course, if this became a requirement, I would submit to it, but I'm 
not in favor of it.


> And absolutely very agreed on the point about reviewer's load: it seems 
> wise to raise awareness that submitted code is work for the reviewers 
> and thereby more code induces more work.

Yes, and not just "Is it more work?" but "What is the most appropriate 
response?"

If we see "0%", we approach it as a traditional review and probe a 
little if that starts feeling wrong.

If we see "57%", then the LLM probably wrote the description too, but 
there's still a lot of the author's very own in there.

If we see "100%", then we might feel freer to speak bluntly about its 
faults, and our initial response might well focus on using the tool more 
effectively, e.g., where to find more context and better examples.


> Like in all projects, there will be trust built on a per-individual 
> fashion, and this will in turn cause more scrutiny in some cases versus 
> others.
> Seems like a normal part of life in a project where several people work 
> together, coding assistants don't seem to change that all that materially.
 >
 > HTH

Yes, yes, and yes.  Thanks.
-- 
Dan