Der Umgang mit KI-generiertem Code führt zunehmend zu erhitzten Diskussionen und Spaltung bei freien Softwareprojekten. Zuletzt gab es derartige Zerwürfnisse bei der Einführung von systemd. Nachdem in den vergangenen Monaten bereits Projekte wie der Kernel, Fedora und Jellyfin Regeln für Beiträge mit Large Language Models (LLMs) formuliert haben, wird derzeit auch innerhalb von KDE über entsprechende Richtlinien diskutiert. Ein Vorschlag des KDE-Entwicklers Nate Graham hat nun eine deutlich restriktivere Gegenposition aus dem GNOME-Umfeld hervorgerufen.
KDE setzt auf »Human in the Loop«
Grahams Entwurf entstand ursprünglich aus einer Diskussion über vollständig von LLMs erzeugte Merge Requests. Als Grundprinzip schlägt er für KDE einen »Human in the Loop«-Ansatz vor: LLMs sollen grundsätzlich eingesetzt werden dürfen, solange der Mensch weiterhin eigene Entscheidungen trifft, die erzeugten Ergebnisse versteht und für sie verantwortlich bleibt. Graham fasst die Grundregel mit »Don’t be lazy« zusammen. LLMs sollen weder das eigene Urteilsvermögen noch zwischenmenschliche Kommunikation oder den eigenen Lernprozess ersetzen.
Absage an Vibe-Coding
Besonders deutlich wird der Vorschlag bei Programmcode. Beiträge sollen nicht einfach per Prompt erzeugt und anschließend ungeprüft eingereicht werden. Graham spricht sich unter anderem gegen Vibe Coding aus, bei dem Entwickler Änderungen einreichen, die sie selbst nicht verstehen oder nicht selbst umsetzen könnten. Ebenso sollen keine von einem LLM erzeugten Rohfassungen mit der Erwartung eingereicht werden, dass die Maintainer daraus anschließend funktionierenden Code machen.
Nützlich für Fehlersuche oder Recherche
Noch restriktiver fällt der Entwurf bei Texten aus. Commit-Meldungen, Merge-Request-Beschreibungen oder Antworten auf Kommentare sollen grundsätzlich von den Beteiligten selbst geschrieben werden. Als ausdrücklich akzeptierte Ausnahme nennt der Vorschlag die maschinelle Übersetzung eigener Texte ins Englische, solange dabei Stil und Aussage nicht verändert werden. Bei der Fehlersuche oder Recherche können LLMs dagegen als Hilfsmittel dienen, sofern der Nutzer ihre Ergebnisse anschließend selbst überprüft.
Für Diskussionen sorgte unter anderem die Formulierung, dass andere KDE-Mitglieder im Idealfall gar nicht erkennen sollten, ob ein LLM eingesetzt wurde. Das heißt nicht, dass dessen Einsatz verborgen werden müsse, sondern weil das Ergebnis nicht von selbst erstellter Arbeit zu unterscheiden sein sollte. Graham spricht sich zudem gegen Angaben wie Assisted-by in Commits aus, wie es in ähnlicher Form beim Kernel praktiziert wird. Solche Hinweise seien letztlich kostenlose Werbung für den jeweiligen Anbieter.
Der Vorschlag ist bislang keine offizielle KDE‑Richtlinie. Die Diskussion auf KDE Invent wurde nach teils heftigen Auseinandersetzungen am 21. September zunächst geschlossen. Graham hatte eine Pause vorgeschlagen, nachdem sich die Debatte zunehmend auch um grundsätzliche Fragen zu KI, Transparenz und Nachhaltigkeit drehte.
GNOME-Entwickler fordert grundsätzliches Verbot
Jordan Petridis aus dem GNOME-Umfeld reagierte am 23. September mit einem eigenen Entwurf unter dem Titel »The GNOME LLM Policy That I Want«. Er hält bereits die Zielsetzung vieler bisheriger LLM-Richtlinien für falsch. Statt detailliert einzelne erlaubte und unerlaubte Arbeitsabläufe zu definieren, sollten solche Regeln seiner Ansicht nach vor allem soziale Normen für ein Projekt festlegen und deutlich machen, welches Verhalten die Gemeinschaft akzeptiert.
Faktisch ein Verbot
Sein Vorschlag fällt entsprechend deutlich kürzer und wesentlich restriktiver aus: LLMs dürften demnach weder zur Erstellung noch zur Veränderung von Code verwendet werden, der bei GNOME eingereicht oder auf der GNOME-Infrastruktur gehostet wird. Von Entwicklern könnte verlangt werden, nachvollziehbar zu machen, dass ihr Code diese Voraussetzung erfüllt. Versuche, eine solche Regel gezielt zu umgehen, könnten zum Ausschluss aus dem Projekt führen.
Als mögliche Kriterien nennt Petridis unter anderem, dass Entwickler ihre Änderungen selbst erklären und begründen können müssen, das jeweilige Problemfeld verstehen und die eigentliche Ursache eines Fehlers statt lediglich dessen Symptome beheben sollen. Außerdem dürften automatisierte Systeme oder Chatbots nicht dazu verwendet werden, gegenüber anderen Projektmitgliedern die eigene Person zu vertreten.
Der Mensch im Fokus
Petridis begründet diese harte Linie weniger mit technischen Fragen als mit seinem Verständnis von GNOME als sozialem Projekt. Freie Software bestehe nicht lediglich aus regelmäßig veröffentlichtem Code, sondern aus der Zusammenarbeit von Menschen. Eine Entwicklung, bei der Freiwillige ihre Zeit hauptsächlich damit verbringen, automatisch erzeugten Code zu überprüfen, hält er für unattraktiv und langfristig schädlich für die Gemeinschaft. Dabei verweist er auch auf gesellschaftliche, arbeitsrechtliche und ökologische Probleme rund um LLMs, ohne diese in seinem Vorschlag im Einzelnen auszuführen.
Technisch nicht durchsetzbar
Dass sich ein Verbot technisch nicht zuverlässig durchsetzen lässt, räumt Petridis selbst ein. Der Zweck einer solchen Richtlinie bestehe für ihn jedoch ähnlich wie bei einem Code of Conduct nicht ausschließlich in der Durchsetzung, sondern darin, die Werte und Erwartungen des Projekts festzuhalten. Bei eingereichtem Code müsse ohnehin bis zu einem gewissen Grad darauf vertraut werden, dass der angegebene Autor tatsächlich für seine Arbeit verantwortlich ist.
Damit markieren die beiden Vorschläge zwei deutlich unterschiedliche Ansätze: Grahams KDE-Entwurf will LLMs als Werkzeug grundsätzlich zulassen, solange Menschen Kontrolle, Verständnis und Verantwortung behalten. Petridis möchte dagegen zumindest bei GNOME-Code eine klare Grenze ziehen und den Einsatz von LLMs bei dessen Erstellung oder Änderung vollständig ausschließen. Ob und in welcher Form daraus tatsächlich verbindliche Richtlinien für KDE oder GNOME entstehen, ist derzeit noch vollkommen offen.
