KDE Closed Its LLM Usage Guidelines Two Days After Opening Them

By Indie Kings | September 26, 2026

Updated September 26, 2026: KDE closed its proposed LLM usage guidelines two days after opening them for discussion, following heavy pushback. The draft from Nate Graham argued that "nobody in KDE should know if you use an LLM," rejected "Assisted-by" commit tags as free advertising for model providers, and described LLM-written text as "long, rambling, soulless, corporate-sounding nonsense."

Source note: All guideline text below is quoted from the proposed KDE LLM guidelines as reported by GamingOnLinux on September 22, 2026. KDE has not published a final policy, so this is a closed proposal, not a rule in force.

Image: KDE. Credit: GamingOnLinux.

Two days, opened and closed

The sequence is short enough to be worth stating precisely, because the speed is the story.

Nate Graham opened Proposed KDE LLM guidelines for discussion on September 19.
It drew substantial pushback from other developers and the wider community.
Graham closed it on September 21, having suggested everyone take 24 hours to cool off.

KDE as a project wanted to allow some use of generative AI and LLMs, and was working on a written policy for it. That the policy attempt ended inside 48 hours, without a settled position, is the outcome worth reporting.

The golden rule: do not be lazy

The draft opens with what it calls the golden rule for LLM usage in KDE: do not be lazy. The supporting lines are specific.

Don't try to use a tool to replace your own judgment, interpersonal communication, or learning process. Don't take unsustainable shortcuts. Don't avoid growing as a person. The result will be poor-quality work that eventually becomes someone else's problem.

Read plainly, that is a quality argument rather than a tool argument. Nothing in it forbids LLMs. It forbids using them as a way of skipping the parts of the job that make a maintainer worth having, and the last line is the sharpest version of that argument, since bad patches in an open source project do not disappear, they land on a reviewer's desk.

The clause that caused the fight

Then the draft said something considerably harder to defend.

Nobody in KDE should know if you use an LLM. Not because you're concealing it, but because your usage of it produces output indistinguishable from what you could produce yourself. Contributions with obvious and lazy LLM usage may be ignored or closed.

This is the part that drew the pushback, and it is worth being precise about the claim because it is subtle. The draft is not saying detection is impossible or that disclosure is mandatory. It is setting the bar at invisibility as the target and treating visibility as evidence of laziness.

The stated logic is that good LLM-assisted work should be indistinguishable from work you could have produced yourself, so a reviewer learning you used a tool concludes the output was effortless. And because the proposal pairs this with the "do not be lazy" rule, it defines visible tool use as evidence of the specific behaviour being prohibited.

That is a coherent position and it is also a hard one to hold, because open source contribution norms have moved toward explicit tooling disclosure. Making invisibility the compliance target pulls against that direction rather than working with it.

Meat proxy and the first-draft problem

The rest of the contribution guidance is more operational. KDE is described as following a human in the loop principle, where you must be making decisions and adjustments beyond mere prompting, and the output must express your unique humanity in some way.

Don't be a "meat proxy", meaning someone who prompts a model and submits what comes back.
Don't submit "vibe-coded" changes you do not understand and could not have made yourself.
Don't submit throwaway LLM-created changes as a "first draft or proof-of-concept for maintainers to improve."
Don't disclose LLM usage as a way of trying to excuse the potential errors or poor quality of a contribution you have not put effort into.

The first-draft prohibition is the one with the most bite, and it is aimed at a genuinely common pattern. Offloading your rough thinking onto a model and handing a maintainer the cleanup is not a contribution, it is a support ticket dressed as a pull request. Calling it a proof-of-concept does not change what the maintainer has to do with it.

The Assisted-by clause, and why it is sharp

One line in the draft is short, practical, and slightly funny.

Don't add "Assisted-by: [some LLM]" tags to your commits; it's just free advertising for the LLM's provider.

The reasoning is different from everything else in the document, and it is not really about code quality. It is about attribution as marketing. An "Assisted-by" trailer on every patch that touched the model turns the commit log into a billboard for the provider, which is a project-maintainer objection rather than a licensing one, and it is the kind of objection that is hard to argue with because it is about someone else's exposure.

It is also the clause most likely to be overruled by practice. Assisted-by trailers are already a de facto standard in several large projects, and a KDE-specific prohibition against them would put the project out of step with the ecosystem it lives in.

On LLM-generated text

The section on generating text is the least argued and the most quotable.

What you are willing to write is generally the upper limit of what others are willing to read. LLMs, on the other hand, often produce long, rambling, soulless, corporate-sounding nonsense that nobody wants to read; don't do it.

The first sentence is the useful one, and it is a statement about a community's tolerance for volume rather than about any model. The second is a characterisation of model output that reviewers will recognise instantly.

It is worth noting that this is the least novel part of the document. Concerns about machine-generated documentation and commit prose being unreadable were already widespread in the community, so the draft mostly codifies an existing consensus rather than splitting it.

What the fight is actually about

The reason this became a two-day news item rather than a quiet mailing list thread is that the proposal tried to resolve a question the ecosystem has not resolved: whether tooling disclosure is a matter of principle or of optics.

The "nobody should know" clause says optics, and it says it by making visibility suspect. The Assisted-by clause says the same thing from the maintainer's side, by treating attribution as exposure. Both point at a project that would rather the tool were invisible than disclosed, which is a defensible position and a minority one.

What KDE ended up with is no policy at all, and a closed discussion. Whether a revised proposal appears, and whether it keeps the invisibility framing, is the thing to watch.

FAQ

What happened with the KDE LLM guidelines?
Nate Graham opened proposed KDE LLM usage guidelines for discussion on September 19, 2026. They drew significant pushback and were closed on September 21, with Graham suggesting participants take 24 hours to cool off. No final policy was published.

Does KDE now have an LLM policy?
Not as a settled rule. What exists is a proposal that was opened and then closed after two days. The document is a draft discussion, not a policy in force.

What did the guidelines say about disclosing LLM use?
That nobody in KDE should know if you use an LLM, not because of concealment but because good usage produces output indistinguishable from your own, and that contributions with obvious and lazy LLM usage may be ignored or closed. Visible tool use was treated as evidence of laziness.

What is a meat proxy in the context of the KDE guidelines?
Someone who prompts a model and submits the result without understanding or adjusting it. The draft also prohibited submitting LLM-generated throwaway work as a first draft or proof-of-concept for maintainers to improve.

Why did KDE object to Assisted-by commit tags?
The draft argued they amount to free advertising for the model provider on every patch, making it a maintainer objection about attribution as marketing rather than a licensing or quality one.

Were LLM contributions banned at KDE?
No. The stated golden rule was "do not be lazy," which prohibited using a tool to replace your own judgment, communication, or learning, rather than banning the tool. The hardest clause was about visibility, not permission.

Bottom Line

The interesting failure here is not that KDE rejected AI tools, because it did not. The draft permitted them and argued only against laziness, and its most concrete rules, no meat proxy, no offloaded first drafts, no vibe-coded patches you cannot explain, are ones most maintainers would sign without argument. The fight was over the invisibility clause, and that is a real split in the ecosystem rather than a KDE peculiarity, because it resolves tooling disclosure as a matter of optics. Making visibility suspect sits badly against an ecosystem where Assisted-by trailers are already becoming standard, and the draft's own reasoning against those tags, that they advertise the provider, is a maintainer's objection about someone else's exposure rather than about the code. Ending with no policy after 48 hours leaves the question exactly where it was, which is the outcome worth watching for. Expect any revised draft to be judged on whether it keeps the invisibility framing, because that is the part with actual opponents.

Source: GamingOnLinux, KDE developers' attempts at creating LLM guidelines are not going well, by Liam Squires-Hand, September 22, 2026, quoting Nate Graham's proposed KDE LLM guidelines