How to deal with fully LLM-generated merge requests

[Nate Graham]

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