KI-Beiträge brauchen menschliche Verantwortung

Meine These

KI kann Menschen den Einstieg in grosse Codebases erleichtern. Das ist gut. Aber sie demokratisiert Open Source nicht automatisch. Zugang zu Code ist nur der Anfang. Gute Zusammenarbeit entsteht erst dort, wo Menschen Änderungen verstehen, begründen, testen, korrigieren und langfristig mittragen.

Genau diese Verantwortung darf nicht an einen Agenten delegiert werden. Ein LLM kann einen Patch vorschlagen. Es kann Zusammenhänge erklären, Tests entwerfen oder eine erste Implementierung liefern. Aber es trägt keine Verantwortung für Architektur, Wartbarkeit, Lizenzfragen oder die Zeit anderer Menschen.

Für mich ist deshalb nicht die wichtigste Frage, ob KI verwendet wurde. Die wichtigere Frage ist: Hat die Person hinter dem Beitrag verstanden, was sie in ein gemeinsames System einbringt?

Zugang ist nicht dasselbe wie Beitrag

Ich halte die Hoffnung, dass KI mehr Menschen zum Mitmachen befähigt, für berechtigt. Viele Open-Source-Projekte sind fachlich, historisch und sozial schwer zugänglich. Wer neu dazukommt, muss Projektstruktur, Stil, technische Entscheidungen, Tests, Governance und unausgesprochene Erwartungen verstehen. KI kann hier Orientierung geben.

Aber Orientierung ist nicht dasselbe wie ein belastbarer Beitrag. Ein Pull Request ist kein isoliertes Ergebnis. Er ist eine Bitte an andere Menschen, ihre Aufmerksamkeit zu investieren und ein Stück Verantwortung mitzutragen. Wenn KI die Einstiegshürde senkt, ohne dass die einreichende Person mehr Verantwortung übernimmt, wird Open Source nicht offener. Es wird lauter.

Das ist der Punkt, der in der Debatte oft untergeht. Mehr generierter Code löst nicht automatisch das Problem knapper Maintainer-Zeit. Im Gegenteil: Wenn plausibel klingende Änderungen schneller entstehen als sie geprüft werden können, verschiebt sich Arbeit zu den Menschen, die ohnehin schon den stabilsten Teil des Projekts tragen.

Review-Zeit ist Infrastruktur

In Security und Software Engineering lernt man schnell, dass der teuerste Teil eines Systems nicht immer der Code ist. Oft ist es die Aufmerksamkeit, die nötig ist, um Risiken zu erkennen. Reviews sind keine bürokratische Hürde. Sie sind Infrastruktur für Vertrauen.

Ein KI-generierter Patch kann oberflächlich sauber aussehen und trotzdem falsch liegen: eine Randbedingung fehlt, eine Annahme passt nicht zur Architektur, eine API wird subtil missverstanden, ein Test bestätigt nur das generierte Verhalten statt die eigentliche Anforderung. Solche Fehler sind unangenehm, weil sie Reviewern Zeit entziehen und gleichzeitig Kompetenz vortäuschen.

Das heisst nicht, dass menschlich geschriebener Code automatisch besser ist. Menschen produzieren ebenfalls schlechte Patches. Der Unterschied ist aber: Von einem Menschen erwarte ich, dass er oder sie erklären kann, warum eine Änderung nötig ist, welche Alternativen geprüft wurden und welche Folgen die Entscheidung hat. Bei KI darf dieser Anspruch nicht sinken.

Policies sind nicht automatisch Gatekeeping

Wenn Projekte KI-generierte Beiträge einschränken, wird das schnell als technikfeindlich oder elitär gelesen. Ich finde diese Reaktion zu einfach. Ein Projekt darf legitime Gründe haben, seine Review-Zeit, seine Lernkultur und seine rechtliche Integrität zu schützen.

Bei Projekten mit starkem Bildungsanspruch kann eine restriktive Haltung sinnvoll sein. Wer beitragen will, soll nicht nur Output liefern, sondern verstehen lernen. Bei Projekten mit hoher Lebensdauer oder strengen Lizenzanforderungen kommt ein weiterer Punkt dazu: Herkunft und Rechte eines Beitrags müssen nachvollziehbar sein. Bei KI-generiertem Code ist diese Nachvollziehbarkeit nicht immer trivial.

Ich sehe darin keinen generellen Anti-KI-Reflex. Ich sehe den Versuch, klare Grenzen für Verantwortung zu ziehen. Diese Grenzen können überhart sein, sie können auch falsch formuliert sein. Aber sie sind nicht automatisch Fortschrittsverweigerung.

Wie ich KI-Beiträge bewerten würde

Ich würde weniger am Werkzeug ansetzen und stärker an der Nachweisbarkeit von Verantwortung. Ein Beitrag sollte unabhängig von seiner Entstehung dieselben Fragen beantworten können:

• Versteht die einreichende Person die Änderung fachlich?
• Ist klar, welches Problem gelöst wird und welches nicht?
• Sind Tests, Edge Cases und Risiken nachvollziehbar?
• Ist die Lizenz- und Herkunftsfrage sauber genug?
• Respektiert der Beitrag die begrenzte Review-Zeit des Projekts?

Wenn diese Fragen gut beantwortet sind, ist KI für mich ein Werkzeug. Wenn sie nicht beantwortet sind, wird KI zur Maschine für Review-Schulden.

Meine Einordnung

Open Source ist nicht nur Code-Verfügbarkeit. Open Source ist eine Praxis aus Lesen, Verstehen, Prüfen, Warten und Kommunizieren. KI kann diese Praxis unterstützen. Sie kann Menschen helfen, schneller in ein Projekt hineinzufinden, bessere Fragen zu stellen oder erste Entwürfe zu testen.

Problematisch wird sie dort, wo sie den schwierigen Teil überspringt: Verantwortung für eine Änderung zu übernehmen.

Ich will deshalb keine pauschale Anti-KI-Haltung in Open Source. Aber ich halte die Forderung nach Verantwortung für nicht verhandelbar. Wer mit KI arbeitet, muss mehr erklären können, nicht weniger. Gerade weil die Erzeugung leichter wird, muss die Prüfung ernster genommen werden.

Abschliessende Gedanken

KI kann Open Source zugänglicher machen. Aber Zugänglichkeit ohne Verantwortung hilft den Projekten nicht, die heute schon unter knapper Maintainer-Zeit leiden.

Die entscheidende Frage ist für mich nicht, ob ein Patch von einem Menschen oder mit Hilfe eines Modells entstanden ist. Entscheidend ist, ob am Ende ein Mensch dahintersteht, der den Beitrag versteht, verteidigen kann und bereit ist, die Folgen mitzutragen.