Godot verbietet KI-geschriebene Beiträge, und die Unterscheidung ist wichtig
Anfang dieses Monats hat die Godot Foundation eine auf den 30. Juni datierte Aktualisierung ihrer Beitragsrichtlinien veröffentlicht, die die härteste Grenze zieht, die bisher eine große Engine gezogen hat. Aller Code, der zur Engine beigetragen wird, muss von Menschen geschrieben sein. KI-Unterstützung ist nur für Kleinkram erlaubt, etwa Code-Vervollständigung, Regex oder Suchen und Ersetzen, und wer KI in irgendeiner Form zum Schreiben von Code genutzt hat, muss das in der PR-Diskussion angeben. Dieselbe Regel gilt für Kommunikation: Issue-Beschreibungen, PR-Nachrichten und Vorschläge müssen von einer Person geschrieben sein, nicht von einem Modell erzeugt. Autonome Agenten und vibe-gecodete Einreichungen waren schon vorher Grund für einen automatischen Ausschluss aus dem Repository, und das bleibt so.
Berichterstattung der Community zur aktualisierten Beitragsrichtlinie von Godot
Die Richtlinie, im Klartext
Die Begründung der Foundation dreht sich um Verantwortung, nicht um Ideologie. Ein Beitrag zu Godot ist kein einmaliger Vorgang. Wer den Code schreibt, muss ihn gut genug verstehen, um ihn im Review zu verteidigen, ihn zu reparieren, wenn er kaputtgeht, und Jahre später Fragen dazu zu beantworten. Der Beitrag formuliert es unmissverständlich:
"Wir können nicht darauf vertrauen, dass Vielnutzer von KI ihren Code gut genug verstehen, um ihn zu reparieren."
Godot Foundation, Aktualisierung der Beitragsrichtlinie
KI kann keine Verantwortung für eine Codezeile übernehmen, also muss ein Mensch das tun, und ein Mensch, der den Code nicht geschrieben hat, kann es meist nicht. Die Kommunikationsregel folgt derselben Logik. Maintainer stellen ihre Zeit freiwillig zur Verfügung, um deine Arbeit zu prüfen, und die Foundation nennt es ein Grundprinzip des Respekts, dass sie dabei mit einem Menschen sprechen und nicht mit einer Maschine. Maschinelle Übersetzung geht weiterhin durch, solange ein Mensch das Original geschrieben hat. Dazu kommt eine neue Bremse für Ehrgeiz: Beitragende mit drei oder weniger gemergten PRs dürfen ohne Zustimmung eines Maintainers keine neuen Features oder größeren Refactorings aufmachen.
Vier Monate von der Beschwerde zur Richtlinie
Nichts davon kam aus dem Nichts. Im März haben wir berichtet, wie Rémi Verschelde die Flut an KI-Müll-PRs als zermürbend und demoralisierend für Maintainer beschrieb, bei 4.681 offenen PRs. Als die Richtlinie kam, lag die Warteschlange laut Berichten über 5.000. Die Ökonomie hat sich seit März nicht geändert. KI hat die Kosten, einen plausibel aussehenden PR zu erzeugen, auf nahezu null gedrückt, während die Kosten, einen zu prüfen, exakt dort geblieben sind, wo sie waren. Geändert hat sich, dass Godot das nicht länger als Moderationsproblem behandelt, sondern als Richtlinienproblem. Die Aktualisierung kam weniger als zwei Wochen nach dem Release von Godot 4.7, was zeigt: Die knappe Ressource der Maintainer ist nicht die Fähigkeit auszuliefern, sondern die Aufmerksamkeit fürs Review.
Beitragen ist nicht dasselbe wie Erschaffen
Wir bauen eine KI-Plattform zum Erstellen von Spielen, also sagen wir die Spannung offen, statt so zu tun, als gäbe es sie nicht. Die meistgenutzte quelloffene Indie-Engine hat gerade gesagt, dass KI-geschriebener Code unerwünscht ist, und bei Cinevva entstehen Spiele komplett per KI. Das klingt nach einem Widerspruch. Ist es nicht, und der Unterschied liegt darin, wer den Code danach trägt.
Wenn ein PR in Godot gemergt wird, erben Hunderttausende Entwickler diesen Code, und eine kleine Gruppe Freiwilliger wird auf unbestimmte Zeit dafür verantwortlich. Das Verständnis des Autors ist die einzige Garantie, die das Projekt bekommt, und genau die entfällt bei starkem KI-Einsatz. Wenn du dein eigenes Spiel mit KI baust, gehört dir das Ergebnis. Geht es kaputt, geht dein Spiel kaputt. Niemand erbt deinen Code, und kein Freiwilliger muss ihn prüfen.
Godot hat nicht verboten, Spiele mit KI zu machen, und könnte es auch nicht, wenn es wollte. Verboten wurde, deine Hälfte einer geteilten Verantwortung an ein Modell auszulagern. Das ist eine vertretbare Grenze, und ehrlich gesagt würden wir dieselbe ziehen. Die Werkzeuge dürfen den Code schreiben. Dahinterstehen muss trotzdem jemand.