Godot nimmt keine von KI verfassten Codebeiträge mehr an
(pcgamer.com)- Die Open-Source-Game-Engine Godot will KI-generierten Code und von KI-Agenten eingereichte Beiträge in ihrer Beitragsrichtlinie verbieten, nachdem KI-erzeugte Pull Requests den Review-Aufwand erhöht haben
- Die Maintainer sind der Ansicht, dass die Prüfung KI-generierter PRs die ohnehin mühsame Review-Arbeit noch aufwendiger macht und zugleich weniger dazu beiträgt, neue Mitwirkende zu künftigen Maintainern zu entwickeln
- Die neue Richtlinie wird ausdrücklich von KI verfassten Code, von KI-Agenten eingereichte Pull Requests und KI-generierten Text in der Kommunikation zwischen Menschen ablehnen
- Beitragende dürfen KI nur unterstützend für “menial things” einsetzen und müssen die Nutzung offenlegen; maschinelle Übersetzung auf Basis eines von Menschen verfassten Originaltexts bleibt erlaubt
- Die Godot Foundation will angesichts sich schnell wandelnder KI-Tools zunächst konservativ vorgehen und die Richtlinie bei veränderten Umständen erneut bewerten
Änderung der Beitragsrichtlinie bei Godot
- Die Godot Foundation und die Maintainer haben nach monatelangen Diskussionen beschlossen, die Beitragsrichtlinien zu überarbeiten und KI-bezogene Einreichungen einzuschränken
- Betroffen sind von KI verfasster Code, von KI-Agenten eingereichte Pull Requests und KI-generierter Text in der Kommunikation zwischen Menschen
- Godot ist eine Open-Source-Game-Engine, die in Spielen wie Slay the Spire 2 und The Case of the Golden Idol eingesetzt wird
Der durch KI-Pull-Requests verursachte Wartungsaufwand
- Die Maintainer diskutieren seit Februar, wie sie auf die zunehmenden AI slop Pull Requests reagieren sollen
- Dieser Strom an PRs ist für die Code-Reviewer des Projekts zu einem Zustand geworden, der „increasingly draining and demoralizing“ ist
- Die Godot Foundation hält das Problem nicht für vorübergehend und will die Belastung der Maintainer senken, ohne dabei den Weg zu verlieren, neue Mitwirkende zu künftigen Maintainern zu entwickeln
Wenn Reviews nicht mehr in Mentoring münden
- Die hohe Zahl wartender PRs kann an sich auch als Zeichen für das wachsende Interesse an der Nutzung von Godot und an Beiträgen zum Projekt gesehen werden
- Mit der Zunahme von von KI verfassten oder eingereichten Beiträgen sinkt jedoch die Bereitschaft der Maintainer, Zeit für PR-Reviews aufzuwenden
- Wenn Feedback zu PRs nicht mehr potenzielle künftige Maintainer coacht, sondern „von der Maschine absorbiert“ wird, ist es schwer zu rechtfertigen, freie Zeit für Reviews einzusetzen
Konkrete Einschränkungen der neuen Richtlinie
- Die Beitragsrichtlinie von Godot wird bald ausdrücklich AI-authored code zurückweisen
- Beitragende sollen KI nur für “menial things” unterstützend einsetzen und die Nutzung offenlegen
- Die Foundation erklärt: „AI can’t be held accountable, and we can’t trust heavy users of AI to understand their code enough to fix it“
- Auch KI-generierter Text in der Kommunikation zwischen Menschen wird abgelehnt
- Die Foundation bezeichnet dies als „a basic principle of respect“
- Maschinelle Übersetzung auf Grundlage eines von Menschen geschriebenen Originaltexts bleibt weiterhin erlaubt
Ausrichtung der Richtlinie
- Die Godot Foundation konzentriert sich darauf, Hürden für wenig aufwendige „slop“-Beiträge zu erhöhen
- Zur Zielsetzung gehört auch, Maintainer in die Lage zu versetzen, weiterhin Code-Reviews durchzuführen und neue Mitwirkende zu künftigen Maintainern zu entwickeln
- Alle Beiträge müssen von einem Menschen kommen, der Verantwortung für den eigenen Code übernimmt und ihn im Fehlerfall selbst korrigieren kann
- Die Foundation erklärt, dass sich KI-Tools derzeit täglich verändern; deshalb wolle man vorerst an einer konservativen Richtlinie festhalten und sie bei Veränderungen neu bewerten
1 Kommentare
Hacker-News-Kommentare
Diese Richtlinie ist fair. Einen ausschweifenden Wand aus KI-generiertem Text gründlich prüfen zu müssen, ist wirklich nervig und fühlt sich an wie ein Denial-of-Service-Angriff auf den menschlichen Geist
Allerdings wird sich KI-gestütztes Coding dadurch wohl kaum aufhalten lassen. Im negativen Fall könnten Einreichende einfach stilistische Marker hinzufügen, damit es menschlicher wirkt, während Kerninhalt und Umfang des Beitrags gleich bleiben und nur der Stil merkwürdiger wird
Im positiven Fall könnte das zu schnörkellosen Commits und Kommentaren führen wie „Das ist der Code, deshalb wurde er geändert, und das sind die Auswirkungen“. Selbst wenn KI ihn erzeugt hat, sind solche kleinen Beiträge viel leichter zu verifizieren, und es könnten sich Standards dafür herausbilden, welche Beitragsgröße angemessen ist oder welche Änderungen ein strengeres Review brauchen
Persönlich ist es mir ziemlich egal, ob etwas KI-generiert ist, solange der Inhalt eher in die zweite Kategorie fällt
Wenn tatsächlich einmal „schnörkellose Commits und Kommentare“ ankommen, wäre das traumhaft
In diesem Kontext ist es nachvollziehbar, KI-Beiträge zurückzudrängen, und bei Software wie Godot, die ihren Wert bereits klar bewiesen hat, umso mehr
Wenn ein von KI geschriebener Commit seinem Wesen nach nicht anders ist, gibt es auch keinen Grund, ihn abzulehnen — ich denke also nicht, dass das Ziel darin besteht, KI-gestütztes Coding zu verhindern
Es ist interessant, dass auf der einen Seite die Unternehmensbewertungen von KI-Firmen offenbar auf der Annahme beruhen, dass in naher Zukunft sämtlicher Code und alle digitalen Ergebnisse von KI geschrieben werden, während auf der anderen Seite fast alle populären Open-Source-Projekte versuchen, KI-Beiträge auszusperren. Das lässt sich nur schwer zusammenbringen
Ich persönlich erlebe nach ausgiebiger Nutzung in meinen Open-Source-Projekten auch so etwas wie einen KI-Kater. Im Moment der Nutzung fühlt es sich an, als hätte man enorme Kräfte gewonnen und würde Features, die Wochen gedauert hätten, in wenigen Stunden bauen — aber wenn man den Code später ansieht, entdeckt man die feinen Risse und Inkonsistenzen, die das Tool hinterlassen hat, und das ist unerquicklich
Inzwischen versuche ich, es weniger für große Feature-Entwicklung und eher für Dinge mit strengen Guardrails zu nutzen, etwa Planung, Debugging oder eng umrissene Refactorings. Es beschleunigt die Arbeit immer noch, aber eher um das 1,5- bis 3-Fache statt um das 10-Fache
Die mentale Konzentration, die fürs Coden nötig ist, nimmt zwar ab, dafür entsteht eine neue Art von Müdigkeit, weil man ständig mit der Maschine chattet und nie genau weiß, wie natürlichsprachliche Anweisungen interpretiert werden. Es fühlt sich an, als würde man eine Maschine über Tastenkombinationen bedienen, deren interne Verdrahtung laufend verändert wird — nicht besonders befriedigend
Ermöglicht hat KI nun Beiträge von Menschen, die überhaupt nicht am Projekt beteiligt sind. Allein die Tatsache, dass jemand einen PR erstellt hat, überschreitet damit nicht mehr automatisch die Schwelle von „diese Person interessiert sich zumindest etwas für den Erfolg des Projekts“
Richtig eingesetzt ist KI ein Verstärker, aber aus Sicht von Open-Source-Maintainern wird man leicht von großen Mengen geringwertiger „Beiträge“ überrollt, die von Menschen kommen, denen das Projekt egal ist
Gerade wegen der Schmeicheltendenz von KI hört man ständig „Das ist eine tolle Idee!“, obwohl ich sehr gut weiß, dass die meisten meiner Ideen nicht besonders toll sind
Wenn ich Geschichten höre wie „Ich bin mit den Kindern zusammen und mache nebenbei auf dem Handy Vibe Coding“, klingt das fast schon zwanghaft
Schon ursprünglich hatte Geschwindigkeit in Open Source keine besonders große Bedeutung, und das hatte gute Gründe
Problematisch ist auch die Dopamin-Struktur, durch die man bei der Arbeit oder beim Start neuer Projekte viel zu schnell zu KI greift
Im Moment versuche ich mein Gehirn wieder darauf zu trainieren, den Großteil des Codes von Hand zu schreiben, statt zuerst nach Claude zu greifen. Ob das nur eine vorübergehende Phase ist oder wir irgendwann eine Art anonyme LLM-Selbsthilfegruppe brauchen, wird die Zeit zeigen
Es gibt Listen, die KI-freie Software sammeln. Es wäre interessant, im Zeitverlauf einen Index oder Graphen dazu zu sehen
https://codeberg.org/brib/slopfree-software-index
https://noai.starlightnet.work/list.html
https://hcker.news/?ai=exclude&include_domains=github.com
Ein funktionaler Grund für eine No-AI-Policy fällt mir nicht wirklich ein. Es läuft, wenn es läuft — egal, wer oder was es gemacht hat
Selbst wenn man KI-generierten Müll vermeidet, vermeidet man dadurch nicht automatisch auch menschen- oder mensch+KI-generierten Müll, der den Filter passiert
Trotzdem fallen mir genügend nichtfunktionale Gründe ein, etwa Herkunft, Verantwortlichkeit, Arbeitsnachweis, Menschen dazu zu ermutigen, Code direkt selbst zu schreiben, oder empirisch nachzuverfolgen, wie Menschen eine Codebasis weiterentwickeln
Die Aussage der Foundation trifft den Kern: „Wenn Feedback zu einem PR nicht dafür genutzt wird, jemanden zu betreuen, der künftig vielleicht selbst Maintainer wird, sondern nur von einer Maschine aufgesogen wird, ist es viel schwerer zu rechtfertigen, seine Freizeit für PR-Reviews zu opfern.“
Wer es nicht versteht, sollte sich diese Beispiele ansehen:
https://github.com/godotengine/godot/pull/115280
https://github.com/godotengine/godot/pull/116410
Es ist unfair gegenüber den Maintainern, von einem Projekt, das schon vor dem AI-Zeitalter mit zu vielen zu reviewenden PRs überlastet war, auch noch zu verlangen, ständig so etwas abzuarbeiten.
Die eigentliche große Änderung der Richtlinie ist daher, dass neue Mitwirkende keine großen Features oder Refactorings mehr übernehmen dürfen.
Aus den im Repository verbliebenen Informationen ließen sich Alias und Social-Media-Konten finden, und es handelte sich um ein Kind, das noch nicht einmal im frühen Teenageralter war. Es wirkte, als fehle noch das Grundwissen, um das Problem oder die damit verbundenen sozialen Strukturen zu verstehen.
Das ist ein Paradebeispiel für Brandolinis Gesetz.
Es kostet zehnmal mehr Aufwand, Unsinn zu widerlegen, als ihn zu erzeugen. Code-Review ist Widerlegung, und das Prüfen der Korrektheit einer Behauptung genauso.
Eine Behauptung zu erzeugen ist leicht, aber zur Widerlegung muss man Wahrheit oder Falschheit beweisen oder einen Widerspruch finden. Deshalb wird die Energie von ohnehin zeitknappen Open-Source-Maintainern unnötig verschwendet, und ich stimme voll zu, dass man diese Energie sparen und produktiver einsetzen sollte.
AI hat zufällig eine der teuersten Ressourcen der Branche entdeckt: die Freizeit von Menschen, die nach ihrer eigentlichen Arbeit abends Open Source maintainen.
Die Foundation hat auf etwas hingewiesen, das immer schon stimmte, das durch AI aber besonders sichtbar geworden ist. Jeder Contributor, auch einer mit AI, könnte am Ende nicht in der Lage sein, den eingereichten Patch selbst zu warten.
Entscheidend ist nicht die Nutzung von AI an sich, sondern dass sie eines von mehreren Anzeichen dafür ist, dass der Einreichende nicht versteht, was er da einreicht. Wenn jemand etwa Namenskonventionen für Variablen bricht, APIs verändert, die nicht angefasst werden sollten, oder unbeholfene Sprachfehler macht, kann das schon ein Grund zur Ablehnung sein, selbst wenn der Patch funktioniert.
Als Umgehung könnte man den PR mit dem Hinweis ablehnen, dass er wegen AI abgelehnt wird, und den Autor dann bitten, einen Teil hervorzuheben, auf den er besonders stolz ist, und in eigenen Worten statt in einer AI-Textwand zu erklären, was er getan hat und warum das gut ist. Der Autor müsste dabei Geschmack und Meinungen zeigen, die AI nicht hat.
Hier reagieren offenbar viele eher auf die Überschrift, statt die eigentliche Richtlinie zu lesen. In der Richtlinie steht, dass ein wichtiger Grund darin liegt, PR-Reviews zur Schulung neuer Mitwirkender und zur Identifizierung potenzieller künftiger Maintainer zu nutzen.
Unabhängig von der Qualität von AI-Beiträgen scheint das schwer zu widerlegen zu sein.
Es sei denn, man glaubt, dass AI das gesamte Konzept von Open-Source-Beiträgen oder Maintenance ohnehin überflüssig machen wird. Dann wäre es wohl passender, die Engine zu forken und Agenten daran arbeiten zu lassen, statt PRs an Godot zu schicken.
Glauben AI-Contributors wirklich, dass sie helfen? Merken sie nicht, dass sie Projekte mit solcher „Arbeit“ kaputtmachen?
Ich verstehe nicht, warum man Geld dafür ausgibt, etwas zu erzeugen, das niemand will und das abgelehnt wird. Haben diese Leute keine Hobbys, oder laufen da OpenClaw-Instanzen frei herum, weil ihr Ersteller sie vergessen hat?
Solche Leute ernten Beiträge zu großen FOSS-Projekten als Lebenslauf-Politur ab. Dasselbe passiert bei Schwachstellenmeldungen.
Massenproduzenten glauben vielleicht wirklich, dass sie helfen, oder sie wissen, dass ihre „Beiträge“ für das Projekt netto schädlich sind. Aber wenn ein direkter wirtschaftlicher Anreiz besteht und die eigene Lage unsicher ist, rutschen Externalitäten in der Prioritätenliste nach unten.
Claude hat es in einer Stunde geschafft, und ich habe es dann drei- oder viermal überarbeitet, die Textwand reduziert und an den Stil des Ausgangsprojekts angepasst. Die Alternative wäre gewesen, es einfach liegenzulassen oder nur ein Issue zu eröffnen und die Last auf die Maintainer abzuwälzen.
Deshalb denke ich, dass ich geholfen habe. Auch diesen Grenzfall habe ich übrigens beim Basteln an meinem Homelab als Hobby entdeckt.
Beide PRs waren klein und unterschieden sich nicht von menschlichen PRs. Ich glaube weiterhin, dass sie wertvolle Ergänzungen waren, und offensichtlich sahen einige Maintainer das genauso.
Sie wollen nicht coden oder Produkte besser machen, sondern „Zeilen Code“, „Commits“ und ein hübsches grünes GitHub-Profil, ohne die Details verstehen zu müssen.