This seems wrong at least at two points:
1. The automatic assumption that any support of AI makes a contributor
not read his contribution, not understand his contribution, and the
whole thing ununderstandable to a degree which can not be remedied in
the same way as hand written code is completely irrational. AI code can
be bad. Manual code can be bad. I produced both kinds. Reasonable people
read their code before submitting, or, say, try to put it in shape.
Assuming people lose their reasonable minds by using an AI summary of a
local MR index is, sorry, ridiculous.
2. What you wrote basically means, that code can be trusted blindly once
it was written by hand. This is but a joke.
Arno Waschk
Gubener Str. 44
10243 Berlin
+49 172 3149605
arnowaschk.de <https://arnowaschk.de>
*[email protected]*
current and upcoming projects:
*Lesungen Klaus Maria Brandauer im Burgtheater, Prinzregententheater,
Metropol-Theater Bremen, Neuhardenberg, etc.*2025
*Die Dreigroschenoper: Berliner Ensemble, Berlin Schauspiel Dresden u. a. *
*Beethoven, die drei letzten Klaviersonaten* wieder ab 2026
*Buch der hängenden Gärten George/Schönberg*
*Verklärte Nacht und Forellenquintett* ab Frühjahr 2026 *Jede Menge
Unsterblichkeit* Musiktheater im Revier Gelsenkirchen
*Die weisse Rose von Udo Zimmermann Kammerfassung der zweiten Version*
Theater Erfurt 2025
*Die weisse Rose von Udo Zimmermann Kammerfassung der Version 1968-72*
Theater Hof Regie: Lothar Krause ab Februar 2023
*Zukunftsmusik* von Jelena Schulte Regie: Antje Thoms
*Der Idiot* Deutsches Theater Berlin Regie: Sebastian Hartmann
*Beichte* mit Markus Öhrn Schweden, on tour seit Dezember 2020
*Häusliche Gewalt* Wiener Festwochen, Biennale Wiesbaden, u. v. a. mit
Markus Öhrn
on tour
*Schlingensief und die Avantgarde* Publikation ZiF Bielefeld
*Fräulein Else* Hörbuch mit Elisabeth Trissenaar
*u. v. a.*
Am 01.06.26 um 09:49 schrieb Lukas-Fabian Moser:
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
