On Sunday, 1 March 2026 19:55:18 UTC Ihor Radchenko wrote: > Matthew Weymar <[email protected]> writes: > > Of course, I can -- and of course, I did! > > > > Do you have a preference as to whether people do or do not use an LLM to > > write a patch?... If so, I am curious as to why. > > First reason is simple - I have been instructed by Emacs maintainers to > not accept LLM-written patches. This is because GNU does not yet have an > official policy on this. And GNU does not have a policy because the > licensing implications of LLM code are not yet clear. > So, I currently cannot accept anything that is generated by LLMs. > (We are discussing on some ways forward right now on GNU lists, but > there is no decision on the topic yet) > > The second reason is more important. > > I can clearly see that the patch is ignoring the basic Elisp standards. > For example, the \n in the docstrings made me think that you did not > review the patch much and just posted it as is after it was generated (I > am not sure if that's the case, but that's the impression). > > If my suspicion is correct, you are missing out on one of the benefits > of contributing to libre software - learning. Normally, even if you > never saw the Elisp standards documentation, you can follow the example > of the rest of Org code and get reasonable code quality, implicitly > learning the code style along the way. > > Third reason is my time. > > In most cases, it is more efficient for Org mode project to have patches > written by interested people - I can quickly review the patches, making > sure that the quality is good, and double-checking with the second pair > of eyes. That takes less time compared to me writing the same patches > myself. > > There are also patches from less experienced contributors. > These patches often take more time on my side compared to if I write > them myself. But by reviewing them, I get more people familiar with > contribution process and Org codebase. So, we end up growing the number > of contributors in the long run and again benefit the whole Org mode > project. > > However, if the patch is simply generated by LLM (especially by > inexperienced contributors or inexperienced LLM users), the time I spend > reviewing is much harder to justify. > > Do note that using LLM may be OK (let's forget about copyright issues > for a moment). LLMs are pretty good generating boilerplate code to > kickstart writing a patch. > But using LLM output without changes is generally > not the best idea. Unless you really know what you are doing and provide > detailed instructions and context, LLMs often suffer from subtle > mistakes in the code -- LLM-generated code MUST be reviewed carefully > before usage. Sometimes, it is simply faster to write code from scratch > compared to reviewing LLM output. I have to say that your patch is an > example of bad LLM code.
I think it's less about whether or not an LLM is used and more about whether the contributor actually owns the code. In other words, did they put real thought into it? Did they test it? And most importantly, do they understand each part well enough to vouch for it based on their own judgment, rather than just saying "it seems to work"? If the only thing the contributor does is press a button and paste the output, the maintainer could do the same in no time. The contributor did not contribute. On the other hand, not all LLM use involves copying the first output and sending it. There is a spectrum: an LLM can be used as a drafting tool, in which case the 'human' would iterate through prompting, thoroughly studying the output, extracting useful and relevant parts, testing, comparing with existing code... In that mode, many lines are initially from the model, but the code is still authored and owned by the contributor. In my opinion, this is closer to using a very powerful code editor than blindly delegating the work. In practice, it can be difficult to determine the degree of LLM involvement just by looking at the code. In this case, however, the long docstring lines containing the literal `\n` are a clear indication that the patch was not given sufficient consideration. I think the maintainer is entitled to be very unhappy about it.
