How to deal with fully LLM-generated merge requests

[Filip Fila]

Hi,

Another +1 for the Jellyfin policy Nicco posted.

I think the initial interaction is key. We don't go in to spend energy on
reviewing, but first attempt to gauge contributors and branch off from
there.

>From what I've seen there can be two types: 1) people who just don't back
down; 2) people who see what we're saying and are willing to correct their
course.

1 would likely be bad contributors anyway, but 2 might be hiding a person
who got carried away and doesn't now the norms of the community, but is
genuinely interested in improving the software and who might still end up
being a good contributor.

Best,
Filip


On Thu, Sep 10, 2026, 10:04 Sune Vuorela <nospam at vuorela.dk> wrote:

> On 2026-09-10, Vlad Zahorodnii <vlad.zahorodnii at kde.org> 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.
>
> I think we should add an entry to our contributor guidelines:
>
> | For large changes, please reach out to relevant maintainers first.
>
> I'd personally like a full ban on LLM contributions; I feel they're a
> waste of everyones time.
>
> I'm currently just tagging them with a 'this looks llm generated, will
> ignore' tag so I can filter them out.
>
> We don't owe anyone to review their pull requests, and we don't owe the
> Large Lying Machines anything.
>
> /Sune
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260910/85cbe37f/attachment.htm>