KDE is fighting over whether AI belongs in Linux. Here's what's at stake

Published Oct 8, 2026, 8:00 AM EDT Sydney Butler is a technology writer with over 20 years of experience as a freelance PC technician and system builder and over a decade as a professional writer. He's worked for more than a decade in user education. On How-To Geek, he writes commerce content, guides, opinions, and specializes in editing hardware and cutting edge technology articles. Sydney started working as a freelance computer technician around the age of 13, before which he was in charge of running the computer center for his school. (He also ran LAN gaming tournaments when the teachers weren't looking!) His interests include VR, PC, Mac, gaming, 3D printing, consumer electronics, the web, and privacy. He holds a Master of Arts degree in Research Psychology with a minor in media and technology studies. His masters dissertation examined the potential for social media to spread misinformation. Outside of How-To Geek, he hosts the Online Tech Tips YouTube Channel, and writes for Online Tech Tips, Switching to Mac, and Helpdesk Geek. Sydney also writes for Expert Reviews UK. He also has bylines at 9to5Mac, 9to5Google, 9to5Toys, Tom's Hardware, MakeTechEasier, and Laptop Mag. It seems that every open source project is currently grappling with the issue of AI. Whether it's about the inclusion of AI features within the actual software itself, or the use of AI to develop and maintain the project, there are many questions up in the air as I write this. KDE, one of the major desktop environments used by millions of Linux users around the world, seems to be having an especially tough time figuring out what role, if any, AI will play in its future. The main decision makers need to figure out a way forward soon. Meanwhile, the flood of AI-generated code is here and needs to go somewhere. Even if it's straight into the trash. AI-generated contributions are eating into KDE’s time It's a widespread issue already There were signs of trouble already when Vlad Zahorodnii (of KWin fame) made a post on the KDE mailing group titled "How to deal with fully LLM-generated merge requests." In it, he raises concerns about merge request and comment replies that are extremely verbose, and arrive impossibly quickly. Zahorodnii compares a flood of such requests to DDoS attacks, and suggests changing KDE's policy to simply close requests that are "obviously" LLM-generated, with the implication that human reviewers don't actually need to read them. This sentiment echoes what we've already seen other FOSS projects raise, with a flood of vibe code contributions and generated requests from people who likely don't know how to code, or whether their "contributions" will actually help or hurt the project in question. The argument is over where to draw the line It's a sticky issue But proposing that a line be drawn isn't the same as describing where that line should be drawn. Despite this, KDE's Nate Graham took a shot anyway, replying in that email thread with suggestions partly based on measures other projects like Jellyfin and Fedora had already taken. The proposal can be summarized as: KDE has a "human-in-the-loop" principle. A person must make decisions about the LLM output, and that output has to be a reflection of that person's "unique humanity" in some way. The end result should be text that's "functionally indistinguishable" from something created without the help of an LLM. Using an LLM to draft or do groundwork is acceptable. As is using one to find and fix bugs, but a human must verify and test it all. Machine translation of your own native language words using an LLM is an acceptable use case. The prohibitions include submitting copy-paste output you don't understand yourself and even open disclosure of LLM use would be frowned upon. The principle is "don't be lazy" and if it's at all obvious an LLM was involved, that's taken as evidence of said laziness. It's certainly not a bad first attempt, but, of course, the major issue here is how can you reliably "detect" that an LLM was used to produce the content you're looking at? No one has the answer to that one yet, but it seems the idea here is that if a reviewer's gut says "this is AI" then that's enough to dismiss a contribution, regardless of what actual merit it might have. Regardless, if you look at examples like this KDE community thread, it's clear that many people who contribute to the project in some way are vehemently opposed to LLM involvement in any shape or form. They raise other issues, such as LLMs introducing code that's plagiarized and would be incompatible with the open licenses that KDE is released under. KDE Eco also raises issues around AI use in the development of KDE because of its water and energy use. Late in September 2026, Linux Pro Magazine published a post about the "KDE for the People" campaign, which advocates for a strict no-AI policy. So factions are clearly drawing their own battle lines. An “AI-native” desktop proposal raised the stakes People install AI anyway In September 2026, Eva Brucherseifer and Jan Muehlig made a KDE Akademy presentation for "A lovable, sovereign, AI-native KDE. It proposed "Kadai," which would integrate AI workspaces and workflows directly into KDE. Its slides explicitly offered a choice of local AI, other models, or no AI. They proposed approval gates and controls over what an agent could access or do. This isn't a KDE roadmap or anything, it's just a conference proposal, which can be as far-out as anyone likes. It's a normal part of ideation, but it does give us a glimpse of the other extreme within the community. On the one hand, you have all AI banned and rejected, with no exceptions. On the other, you have a Linux desktop with an AI-shaped hole you can choose to fill. It's unclear what the middle road here would even look like. That earlier Linux Pro Magazine post highlighted that KDE had a proposed AI policy posted, which was later taken down, and as of this writing there's nothing like a final or well-developed draft. There are so many issues around legality, privacy, control, ethics, and more raised by the advent of generative AI that this policy discussion will either go on forever, or will probably end up being some extreme polarizing decision, splitting the community into pro and anti-AI factions. So what's at stake here might be the very soul of this crucial Linux project. Again, KDE is far from the only FOSS project facing the issue of what to do with generative AI, but most of those projects aren't as impactful and influential as this. In fact, I'd wager whatever the KDE community and leaders end up doing will act as a signal to everyone else. So the pressure is on to get it right.