How to deal with fully LLM-generated merge requests

[Christoph Cullmann]

Hi,

+1 for that proposal!

On Thursday, September 10th, 2026 at 22:00, Nate Graham <nate at kde.org> wrote:

> [re-posting to re-add kde-devel, which I dropped by accident]
> 

> 

> Perhaps this is a good time to propose a specific set of LLM usage
> guidelines.
> 

> I've been working on this for a few weeks, modeled on a synthesis of the
> Jellyfin[1] and Fedora[2] policies mixed into what I see as KDE's
> culture and the rough emerging consensus in KDE on the topic.
> 

> Let me present my current draft for comment:
> 

> 

> 

> 

> ## LLM usage
> KDE follows a "human in the loop" principle: when using an LLM, a human
> must be making decisions beyond mere prompting. The output must express
> the operator's unique humanity in some way.
> 

> So nobody in KDE should know you used an LLM — not because you're
> concealing it, but because the results are functionally
> indistinguishable from what you could produce yourself.
> 

> How can you ensure that? Here are some examples:
> 

> 

> ### Acceptable LLM usage
> 1. Create it yourself in the first place, with no LLM.
> 2. Write text that you want other people to read yourself in English,
> with no LLM.
> 3. Have an LLM make a rough draft or something, then you rewrite or
> refine it yourself.
> 4. Have an LLM find a bug, and then you verify that and fix it yourself.
> 5. Have an LLM fix a merge conflict in your patch, then you verify and
> push the result yourself.
> 6. Use an LLM to debug an issue and identify a bug, then report the bug
> yourself, with your own words.
> 7. Write text that you want other people to read yourself in your native
> language, and then machine-translate it (with no stylistic or tonal
> changes) into English.
> 8. Use an LLM to explain or teach you something you don't understand,
> then test your new knowledge in the field to verify that it was correct
> and that you now have a new skill.
> 

> 

> ### Prohibited
> 1. Don't ask an LLM to write some English text, and copy-paste that into
> a chat or merge request description.
> 2. Don't copy someone else's response to you into an LLM, tell it to
> reply, and then copy-paste the output as a response to the other person.
> 3. Don't submit "vibe-coded" changes you don't understand and couldn't
> make yourself.
> 4. Don't disclose LLM usage as a way of trying to excuse the potential
> errors or poor quality of a contribution.
> 5. Don't add "Assisted-by: [some LLM]" tags to your commits; it's just
> free advertising for the LLM's provider.
> 

> 

> ### The golden rule
> **Don't be lazy.**
> 

> If anyone can detect that you used an LLM, you were being too lazy.
> 

> Don't try to use an LLM to replace your own judgment, interpersonal
> communication, or learning process. Don't take unsustainable shortcuts.
> Don't avoid growing as a person.
> 

> Any of this will produce poor-quality work that eventually becomes
> someone else's problem.
> 

> **Contributions in violation of the above guidelines are subject to
> being ignored or closed.**
> 

> 

> 

> 

> 

> 

> Nate
> 

> 

> 

> [1]
> https://jellyfin.org/docs/general/contributing/llm-policies/#llm-code-contributions-to-official-projects
> 

> [2]
> https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260910/ed2460a8/attachment.sig>