How to deal with fully LLM-generated merge requests

[Luna Lovecraft]

In my opinion the most reasonable/best LLM policy is the one currently
being used by Servo:
https://book.servo.org/contributing/getting-started.html#ai-contributions

On Thu, Sep 10, 2026 at 12:26 PM Lasath Fernando <kde at lasath.org> wrote:

> I personally am a big fan of Jellyfin's AI/LLM use policy:
> https://jellyfin.org/docs/general/contributing/llm-policies/
>
> It's very pragmatic and somewhat enforceable. We should adapt something
> similar.
>
> Cheers,
> Lasath
>
> On Thu, Sep 10, 2026, at 02:27, 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.
> >
> > 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260911/1728f92b/attachment-0001.htm>