140 Zeilen Richtlinien auf 7 gekürzt: Ein Traditionsprojekt schließt das Tor
Am 24. September 2026 reichte das Open-Source-Geoinformationssystem QGIS – ein Projekt mit über zwanzig Jahren Entwicklungsgeschichte – den Pull Request PR #387 ein. Der Schritt war höchst ungewöhnlich: Das Betreuungsteam strich 140 Zeilen des bisherigen Richtliniendokuments und fügte lediglich 7 Zeilen neu ein, wodurch der gesamte Text von 148 auf 15 Zeilen schrumpfte.
Gestrichen wurden alle wohlwollenden Empfehlungen und Kompromissformeln. Die Neufassung besteht im Kern aus einem einzigen unmissverständlichen Satz: Das QGIS-Repository akzeptiert keinerlei Code-Beiträge mehr, die durch LLMs, KI oder Agenten unterstützt wurden. Sollte sich im Nachhinein herausstellen, dass ein solcher Workflow genutzt wurde, wird der Beitrag zurückgerollt und die Rechte des Beitragenden werden sanktioniert. Der Vorschlag fand überwältigende Zustimmung und wurde zügig gemergt.
No LLM, AI or agent assisted code contributions are allowed in the qgis repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.Das Richtliniendokument sprang von Version 1.0 auf Version 2.0, und die Autorenschaft wechselte von einem einzelnen Maintainer zu „Allen Mitwirkenden des QGIS-Projekts“. Obwohl über 90 Prozent des Regelwerks gestrichen wurden, zieht die Verbindlichkeit beispiellos an. Das frühere Gentleman’s Agreement, das auf freiwillige Selbstkontrolle setzte, wurde durch eine kompromisslose rote Linie ersetzt.
Abb.: Die Diff-Ansicht des Vorschlags: Ein vollständiges Richtliniendokument wurde auf einen kurzen Absatz eingedampft. Quelle: GitHub (QGIS-Enhancement-Proposals PR #387)
Die gestrichene alte Richtlinie war eigentlich erstaunlich entgegenkommend gewesen: Mitwirkende durften jedes beliebige Werkzeug verwenden, solange ein „Human-in-the-Loop“ gewahrt blieb. Sie mussten jeden von LLMs erzeugten Code- und Textbaustein vor dem Einreichen selbst vollständig gelesen und geprüft haben, die volle Verantwortung als Autor tragen und transparent offenlegen, welche Teile durch Tools generiert wurden – etwa durch eine entsprechende Notiz in der Commit-Nachricht. Das alte Dokument betonte sogar ausdrücklich, dass diese Regelung lediglich den Modus der Zusammenarbeit festlege und keine grundsätzliche Haltung des Projekts dazu darstelle, ob KI-Code angenommen werden dürfe.
Nur wenige Monate später wurde dieses Regelwerk von der Realität überrollt. Maintainer timlinux brachte es treffend auf den Punkt: Der entscheidende Vorteil dieser 7 Zeilen liege darin, dass sie jegliche Zweideutigkeit beseitigen.
Code entsteht in drei Sekunden – die menschliche Prüfung bleibt Handarbeit
Die Sorge alteingesessener Projekte wurzelt in der Asymmetrie der Verifikationskosten. Ein Tastendruck genügt, um hunderte Zeilen Code auszuspucken, doch die Prüfung dieser Zeilen ist um keine Sekunde schneller geworden.
Es ist, als würde man eine Lkw-Ladung vorgeschnittener Kartoffelstreifen in eine Restaurantküche kippen: Die Maschine liefert in Sekundenschnelle, aber die Prüfer müssen sich über die Schüsseln beugen und jeden einzelnen Streifen auf faule Stellen untersuchen. QGIS verarbeitet Geodaten und komplexe räumliche Berechnungen. Wenn eine Koordinatenprojektion um eine Nachkommastelle verrutscht oder tief in einer Schleife ein Speicherleck lauert, schlägt der Compiler keinen Alarm. Die Kosten auf der Erzeugungsseite sind praktisch auf null gesunken, die Kosten auf der Prüfungsseite keinen Cent billiger geworden – und diese Differenz kann nur durch menschliche Arbeitszeit ausgeglichen werden.
Maintainer haubourg brachte die Gründe in der Diskussion am deutlichsten auf den Punkt. Externe Mitwirkende, die KI nutzen, bürden den ehrenamtlichen Maintainern eine gewaltige, untragbare Last auf – und diese Aufgabe war bereits vor dem Aufkommen von LLMs extrem fordernd. Die Verbreitung der Werkzeuge hat für keine Entlastung gesorgt; sie hat lediglich das vorgelagerte Volumen vervielfacht und ungefiltert nachgelagert abgeladen.
Er skizzierte zwei unvermeidliche Szenarien: Wenn der Zustrom an Code die menschliche Prüfungskapazität übersteigt, häuft das Projekt entweder einen endlosen Berg unbearbeiteter Pull Requests an oder lässt ungeprüften Code in die Codebasis fließen. Beide Ergebnisse sind für eine industrielle Basisinfrastruktur inakzeptabel.
Abb.: Maintainer erklären im Diskussionsverlauf, warum die Schotten dichtgemacht werden. Quelle: GitHub (QGIS-Enhancement-Proposals PR #387)
Über fremde Konten mit dem Modell streiten: Maintainer korrigieren KI-Hausaufgaben
Ein weiteres Argument von haubourg wiegt noch schwerer: Das Fundament der Freie-Software-Gemeinschaft ist ein Netzwerk aus Menschen. Institutionen vertrauen QGIS, weil sie wissen, dass sie sich beteiligen können und Fachleute für Support, Schulungen oder neue Funktionen anheuern können. All diese Prämissen beruhen darauf, dass auf der anderen Seite des Bildschirms ein ansprechbarer Mensch sitzt, der Verantwortung übernimmt.
Doch diese Grundannahme bricht weg – und die Maintainer zahlen den Preis dafür. Zeitgleich entbrannte auf Hacker News eine Debatte unter dem Titel „AI coding agents produce more code, not more software“. Der Kommentarbereich glich einem Frontbericht der Maintainer: Plotly berichtete von ungeprüften, drei Seiten langen Issues und „plausibel wirkenden, aber fragilen“ Patches, die so viel Review-Zeit fraßen, dass man erwäge, externe Gelegenheitsbeiträge ganz einzustellen. Hatchet klagte, viele Code-Reviews fühlten sich an wie „ein Streitgespräch mit Claude über das Konto eines Dritten“. PgDog stellte Code-Beiträge komplett ein und erlaubt nur noch Issues; und Entwickler von Godot konnten nach einer Welle KI-generierter PRs nur noch kraftlose Entschuldigungen formulieren.
haubourgs Sorge gilt nicht nur dem Tagesgeschäft. Wenn externe Beiträge von synthetischem Rauschen überschwemmt werden, gehen echte Neueinsteiger, die ernsthaft lernen wollen, in der Masse unter, und die Zukunft des Projekts bricht weg. Genau diese Bandbreite will er bewahren: die Energie, um menschliche Anfänger zu begleiten, die bereit sind, mit kleinen, ehrlichen Verbesserungen zu beginnen.
Die Schleuse zu schließen ist eine institutionelle Maßnahme, kein Urteil über die Technik
Bei der Entscheidung von QGIS gibt es ein naheliegendes Missverständnis: Die Regelung zielt auf extern eingereichten Code ab. Das Projekt lehnt die Technologie keineswegs pauschal ab. haubourg stellte ausdrücklich klar, dass der Einsatz großer Sprachmodelle für Code-Reviews, Audits und Sicherheitsüberprüfungen auf einer separaten Schiene diskutiert werden sollte – zunächst auf Anwendertreffen, bevor ein formeller Vorschlag ausgearbeitet wird.
Diese Unterscheidung ist elementar. In den Händen der Torwächter ist dasselbe Werkzeug ein nützliches Diagnosegerät; in der unkontrollierten Flut vor den Toren wird es zu Schlick und Geröll. Die Institution muss sich gegen unzurechnungsfähige Ergebnisse absichern, nicht gegen das Werkzeug selbst.
Die Rückkehr von 140 Zeilen kulanter Richtlinien zu einem 7-zeiligen strikten Verbot ist die konsequente Zuspitzung dieses Gedankens. Wenn die Generierung rasant beschleunigt wird, während die Verifikation stagniert, bricht eine auf gutem Willen basierende Verteidigungslinie unweigerlich zusammen. Der Engpass liegt längst nicht mehr beim Schreiben von Code, sondern beim Nachvollziehen dessen, was der Code tatsächlich tut. Das Schließen des Tores dient dem Schutz dessen, was Open Source im Kern ausmacht: einem echten Dialog von Mensch zu Mensch.
Weiterführende Links:
- QGIS-Vorschlag PR #387 (QEP428)
- Diskussionsbeiträge der Maintainer zu PR #387
- Hacker News: AI coding agents produce more code, not more software
- Öffentliche Rückmeldungen der Maintainer von Plotly, Hatchet, PgDog und Godot
