How to deal with fully LLM-generated merge requests

[Kristen McWilliam]

Nate's draft sounds good to me, and very well-written. +1!

On 9/11/26 04:15 AM, Vlad Zahorodnii wrote:


On 9/11/26 11:07 AM, Carl Schwan wrote:

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/


I think "This obligation does not apply where the AI system performs only
an assistive function for standard editing (e.g. grammar correction) or
where it does not substantially alter the input data or its semantics.
There is also a carve-out for systems authorised by law to detect, prevent,
investigate or prosecute criminal offences." is pretty relevant in this
case. With Nate's suggested guidelines, you need to change the generated
output substantially to make sure that it aligns closely with what you'd
write.

In either case, I really don't like the idea that KDE projects can be
forced by law to advertise LLM models. However, it also reads to me like
that law is mostly about disclosing fully AI generated contents.

Vlad

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

-- 
Cheers,
  Kristen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260911/7c84ea86/attachment.htm>