How to deal with fully LLM-generated merge requests

[Akseli Lahtinen]

On Thursday 10 September 2026 10:27:00 Eastern European Summer Time Vlad Zahorodnii wrote:
> Hi,
> 
> We started seeing an increase in number of merge requests that have
> obvious signs of being generated fully by LLMs. For example, walls of
> text in merge description, or replying with a wall of text to a review
> comment in less than a minute, etc.
> 
> It is easy generating such merge requests, but going through them takes
> time for us, humans. It's possible to encounter a denial of service type
> of issue if the number of such MRs continues increasing.
> 
> Personally, if I talk to a contributor, I would like to know that they
> know what they do, that whoever uploaded the MR is not just a proxy
> between me and their LLM. Lastly, I think it's rude to copy paste LLM
> responses to comments made by humans.
> 
> I suggest that we update our guidelines to say that it is okay to close
> merge requests that have clear signs of being fully generated by LLMs
> right away.

We really, really should. 

The jellyfin one linked in this mailing thread seems fair, even as someone
who finds the whole "AI" ecosystem unethical and awful.

What I propose is to have something like jellyfin has as the baseline, 
but individual projects can ban them outright if they feel like doing so.
(Make this explicit in the writing, otherwise we will get weirdos yelling at us).

> 
> It's also interesting what systemd and NetworkManager did recently
> (https://www.phoronix.com/news/NetworkManager-AI-Canary and
> https://www.phoronix.com/news/systemd-262-rc2). I don't know how well
> that works but if it's proven to be effective, maybe we can adopt that
> idea too?
> 
> Regards,
> Vlad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260910/d9943d96/attachment.sig>