How to deal with fully LLM-generated merge requests

[Carl Schwan]

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

Due to the article 50 of the European AI Act, we (at least european, not sure about jon European) are required to disclose when using AI: https://artificialintelligenceact.eu/transparency-rules-article-50/

> ### 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/