How to deal with fully LLM-generated merge requests

[Aleix Pol]

This could probably work, we should find a better tool to workshop the
text than mailman :D but it's a good start. I would like it if we
could make it a bit shorter and clearer. At the moment it's both very
specific but also open to "how about" questions.

Your text made me think of the "Meat proxy" concept. I guess what we
want to say in the end is "don't become a thoughtless information
relay" https://gruhn.me/blog/2026-08-03/

Aleix

On Thu, Sep 10, 2026 at 8:33 PM Nate Graham <nate at kde.org> wrote:
>
> 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/