Ihor Radchenko <[email protected]> wrote:

>>> Also, I started this thread simply because LLMs are starting to affect
>>> the Org development. I'd prefer to discuss the rules we will eventually
>>> formulate on this list rather than elsewhere. This way, the records will
>>> be preserved.

>> Looking at my (and other projects) experience I think also orgmode is going 
>> in the direction of a
>> "no-AI slop/spam" policy that covers not only copyright concerns (which are 
>> still cloudy and having
>> the FSF in the loop makes the process longer).

> I'm leaning towards more receptive attitude.
> Preliminary ideas are the following:

> 1. First-time contributors should be discouraged to use LLM
> 2. The only exception to (1) is when they declare that
>    a. They are experienced LLM users
>    b. They confirm that they have reviewed the LLM-generated code and
>       *also the code it changes*
> 3. Contributors who wrote their own patches in the past may use LLM for
>    smallish patches. No new substantial features.
> 4. Regular contributors may be trusted to use LLM assist for new
>    features. They are probably experienced enough to review the
>    generated code and make sure that it is reasonable.

> […]

As a user, I wouldn't be happy with this.

First, this establishes some kind of LLM priesthood where,
when one is experienced enough, one can use an LLM.  It also
requires this LLM-generated code just to be "reviewed".
History shows that in every field there are lots of people
who consider themselves experienced and that "review" is a
very loosely defined term that does not necessarily involve
looking at the code.

I want every contribution to be "owned".  That means that a
(human) contributor understands the code to the extent that
they can answer questions about it and take responsibility
if it introduces some bug or vulnerability.  I'm more than
willing to forgive if a volunteer makes a mistake in their
honest endeavour to advance Org (or software in general),
and I don't care if they found the solution by looking at
the code for hours or having a epiphany, but they should
have more knowledge than being able to type "fix this error"
at an LLM prompt for – well, what exactly?

Second, one of the main advantages of Org, Emacs and free
software overall is that I (as a user) can change and extend
it.  When doing so, I often encounter code that makes this
process harder.  LLMs and similar tools do not care about
this.  They "understand" complexity to a degree that a human
cannot, and thus they are not "interested" in generating
code that is easy to read and easy to extend.  As a result,
this may lead to a code base that a human can no longer
comprehend, i. e. a form of "closed source".

Tim

Reply via email to