How to deal with fully LLM-generated merge requests

[Vlad Zahorodnii]

Hi,

On 9/10/26 9: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.

I'd remove "don't understand" because understanding is not really the 
same as being able to make it yourself. For example, I don't code in 
Zig, but I can follow more or less code written in Zig. Otherwise reads 
good to me. :)

Vlad

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