Am 01.06.26 um 13:37 schrieb Lukas-Fabian Moser:
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.
Challenge taken ;-) But this experiment would definitely make reviewers
more busy than necessary ;.)
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).
I used "those which seem to come from what looks to me like being the
core lilypond team" just as a term for a certain somewhat trusted
circle. Can be taken with a grace of a note.
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.
Not sure which two sentences you mean referring to one single (okay,
very long9 sentence with several commas. Frustration does not get less
if someone perceives things as "interpretation", independently how far
this is true. I felt better to hand in the general concept together with
code serving as an example for how i would do it, especially when i
already had it. And far before the (possible, but hm, why?) suggestion
to move discussion to the mailing list first came rough tone, repeated
discussions about super clean git history (possible, but certainly the
last thing being helpful about general concepts), obviously suspecting
questions about AI (yes/no :-)) ) and all together the little helpful
claim i should invest a lot of work before asking if further work is
worth doing it.
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.
This is your interpretation
Lukas
