Debian vertagt Entscheidung zu KI-generierten Beiträgen

• Die Debian-Community diskutierte, ob KI- oder LLM-basierte Codebeiträge zugelassen werden sollen, beendete die Debatte jedoch ohne Ergebnis.
• Ein vorgeschlagener Entwurf hätte solche Beiträge unter Bedingungen erlaubt, darunter ausdrückliche Offenlegung bei Nutzung von KI-Tools, klare Verantwortlichkeit und das Verbot der Nutzung sensibler Informationen.
• Unter den Entwicklerinnen und Entwicklern gingen die Meinungen auseinander, insbesondere wegen der Unschärfe des Begriffs „KI“, des Anwendungsbereichs von LLMs sowie Fragen zu Qualität, Urheberrecht und Ethik.
• Einige sprachen sich dagegen aus und nannten unter anderem Hürden für das Onboarding neuer Beitragender, unethisches Verhalten von Unternehmen und rechtliche Unsicherheit als Gründe.
• Debian will vorerst weiter nach den bestehenden Richtlinien im Einzelfall entscheiden und lässt die Möglichkeit künftiger Diskussionen offen.

---

Überblick über Debians Diskussion zu KI-Beiträgen

• Debian führte eine interne Debatte darüber, ob KI-generierter Code akzeptiert werden soll, die jedoch ohne Einbringung einer General Resolution (GR) endete.
  • Ausgelöst wurde die Diskussion durch einen Entwurf von Lucas Nussbaum, der eine klare Position zu KI-unterstützten Beiträgen schaffen sollte.
  • Nach dem Einholen von Feedback prüfte er eine formelle Einreichung, ließ dies aber fallen, als die Diskussion an Dynamik verlor.
• Der Entwurf sah unter anderem eine Offenlegungspflicht für mit KI-Tools erzeugten Code, die klare Zuordnung der Verantwortung, die Zusicherung von Sicherheits- und Lizenzkonformität sowie ein Verbot der Nutzung nicht öffentlicher Informationen vor.

Streit um Begriffsdefinitionen und technische Abgrenzungen

• Mehrere Entwicklerinnen und Entwickler kritisierten die Unklarheit des Begriffs „KI“ und betonten die Notwendigkeit, konkrete Technologien wie LLMs ausdrücklich zu benennen.
  • Russ Allbery erklärte, „KI“ sei zu weit gefasst und daher ungeeignet als Grundlage für Richtlinien.
  • Sean Whitton schlug eine Unterscheidung nach Verwendungszweck von LLMs (Code-Review, Prototypen, Produktivcode) vor.
  • Andrea Pappacoda sagte, Projekte wie Claude’s C Compiler sollten nicht in Debian aufgenommen werden.
• Nussbaum hielt dagegen, entscheidend sei nicht die Art des Werkzeugs, sondern der Vorgang der automatisierten Codegenerierung selbst.

Onboarding neuer Beitragender und Kostenfragen

• Simon Richter äußerte die Sorge, dass KI Lerngelegenheiten für neue Entwicklerinnen und Entwickler ersetzen könnte.
  • Er wies darauf hin, dass KI auch unter Anleitung nicht lerne und Ressourcen des Projekts dadurch nicht in nachhaltige Wissensweitergabe mündeten.
  • Zudem wurde die Sorge geäußert, dass der Einsatz von KI eine Abhängigkeit von kostenpflichtigen Tools schaffen und damit die Zugänglichkeit für Beitragende senken könnte.
• Nussbaum entgegnete, derzeit gebe es noch kostenlosen Zugang, räumte aber ein, dass Kostenprobleme künftig entstehen könnten.
  • Er argumentierte zudem, KI könne den Zugang zu komplexen Aufgaben sogar erleichtern.
• Ted Ts’o widersprach dem Ausschluss von KI-Nutzenden mit dem Argument, dies sei widersprüchlich und könne die Vielfalt unter den Beitragenden einschränken.

Diskussion zu Ethik, Urheberrecht und Qualität

• Matthew Vernon argumentierte, Debian müsse sich klar gegen KI positionieren, und verwies auf unethische Datensammlung durch KI-Unternehmen und Umweltschäden.
  • Er nannte als problematische Folgen unter anderem Urheberrechtsverletzungen, die Erzeugung von Bildern ohne Einwilligung und falsche Sicherheitsberichte.
• Jonathan Dowland schlug vor, die Annahme KI-generierter Inhalte einzuschränken, bis die rechtliche Unsicherheit geklärt ist.
• Thorsten Glaser forderte, Projekte mit LLM-basiertem Code in den Bereich „non-free“ zu verschieben, fand dafür jedoch keine Unterstützung, weil dies das Risiko bergen würde, große Projekte wie den Linux-Kernel oder Python auszuschließen.
• Allbery merkte an, die Debatte über die Qualität von KI-Code sei wenig sinnvoll, da auch Menschen schlechten Code schreiben können.
• Bdale Garbee betonte, man solle KI als Evolutionsstufe betrachten und ihre langfristigen Auswirkungen beobachten.

Debatte über die „bevorzugte Form zur Bearbeitung“ (Preferred form of modification)

• Nussbaum antwortete, LLM-Eingaben (Prompts) seien die bevorzugte Form zur Bearbeitung, was jedoch wegen des Problems der Nichtdeterministik weitere Diskussionen auslöste.
  • Einige argumentierten, LLMs seien nichtdeterministisch und daher für reproducible builds ungeeignet.
  • Andere entgegneten, bei gleichem PRNG-Seed und identischer Umgebung sei Reproduzierbarkeit möglich.
  • Die Diskussion weitete sich auf technische Details wie Determinismus, Reproduzierbarkeit und die Asynchronität von GPU-Berechnungen aus.

Fazit: Debian vertagt die Entscheidung

• Innerhalb von Debian besteht nicht einmal Einigkeit darüber, wie KI-generierte Beiträge überhaupt zu definieren sind.
• Viele kamen zu dem Schluss, dass jetzt nicht der richtige Zeitpunkt für eine Abstimmung über eine Resolution ist, und dass weitere Diskussionen auf Mailinglistenebene sinnvoller seien.
• Nussbaum sagte, ein „Kompromiss, der KI erlaubt, aber Schutzmechanismen vorsieht“ sei wohl der realistischste Weg.
• Vorerst bleibt es bei Einzelfallentscheidungen nach den bestehenden Richtlinien; Kriterien für KI-Modelle, LLM-Code und KI-generierte Beiträge sind weiterhin offen.
• Angesichts komplexer technischer Veränderungen und vielfältiger Positionen gilt der Status quo derzeit als die pragmatischste Wahl.

[GN⁺]

Hacker-News-Kommentare

• Ich programmiere schon mein ganzes Leben, aber seit eine Handgelenksverletzung Tippen fast unmöglich gemacht hat, kann ich dank LLMs, KI-Autovervollständigung und agentenbasierter Entwicklung wieder hochwertigen Code produzieren
  Selbst KI-Halluzinationen helfen eher dabei, Prompts zu verfeinern und die eigene Absicht klarer zu formulieren
  Aus Sicht der Barrierefreiheit ist KI für mich ein unverzichtbares Werkzeug, und wichtiger als die Frage, ob „das Gute das Schlechte aufwiegt“, ist meiner Meinung nach eine integrative Haltung gegenüber der Einbindung ins Ökosystem

  • Wie du sagst, gibt es Leute, die KI vernünftig einsetzen, aber es ist gefährlich anzunehmen, dass alle Nutzer so handeln
    Manche Projekte werden mit minderwertigen PRs überschwemmt, und viele Beitragende wollen nur ihr GitHub-Profil aufpolieren
    Am Ende ist entscheidend, ob jemand in gutem Glauben (good faith) beiträgt, und Projekte sollten klar festlegen, wo sie die Grenze ziehen
  • Ich verfolge einen ähnlichen Ansatz. Statt KI schwierige Probleme lösen zu lassen, gebe ich ihr bereits die technische Lösung, die ich umsetzen wollte, und lasse daraus Code generieren
    So ermüdet das Review weniger, und ich kann mich gezielt auf die Stellen konzentrieren, die von meinen Erwartungen abweichen
  • Ich habe auch Schmerzen im Handgelenk und nutze eine Whisper- + LLM-Kombination für Spracheingabe und Aufbereitung. Damit sind E-Mails, Dokumente und sogar die Sortierung von Belegen automatisiert, was auch meiner Gesundheit hilft
    In einem Unternehmen, das solche Funktionen blockiert, würde ich inzwischen gar nicht mehr arbeiten wollen
  • Ich habe ebenfalls RSI, und KI-Autovervollständigung hat mir sehr geholfen. Agentenartige KI ist in Echtzeit-C++-/Rust-Umgebungen allerdings nicht besonders nützlich
    Der Aspekt der Barrierefreiheit ist sehr wichtig, aber Urheberrechts- und Haftungsfragen bleiben weiterhin komplex
  • Wenn man Code signieren und dafür mit der eigenen Fachkompetenz und dem eigenen Ruf einstehen kann, ist KI nur ein fortgeschrittenes Autovervollständigungswerkzeug und sollte als Ausnahme von „no AI“-Regeln gelten

• Ich denke, bei PR-Reviews geht es letztlich um Vertrauen. Man glaubt, dass der Einreicher sein Bestes gegeben hat
  Entscheidend ist nicht, ob KI verwendet wurde, sondern ob sie verantwortungsvoll eingesetzt wurde

  • Natürlich gibt es auch böswillige Akteure. Persistente Bedrohungen (APT) wie beim XZ-Angriff sind auch in Open Source real
    Mehrere Fake-Accounts können zu einem einzigen Angreifer gehören, und von LLMs erzeugter Code wirkt für LLMs selbst plausibel, was die Verifikation noch schwieriger macht
    Letztlich ist es dadurch schwieriger geworden, PRs zu bewerten, als sie zu erzeugen
  • Trotzdem finde ich weiterhin, dass man jeden Code als potenzielles trojanisches Pferd betrachten und verifizieren sollte
  • Der Review-Prozess muss robust genug sein, um Fehler zu finden, egal ob von Menschen oder KI

• Die Qualitätsdebatte bei KI-Beiträgen ist seltsam. Für Qualität ist immer der Einreicher verantwortlich
  Die Nutzung von KI entbindet niemanden davon, und im Gegenteil könnten restriktive Richtlinien zur KI-Nutzung nur gutwilligen Beitragenden schaden

  • Das Problem ist, dass LLM-Code oberflächlich gut aussieht, in Wirklichkeit aber ohne echtes Verständnis implementierter Code sein kann
  • Entscheidend ist nicht das Werkzeug, sondern ob der Beitragende seinen Code im Review erklären und verteidigen kann
    Ich pflege einen mit KI erzeugten Fork mit 300 Commits, kann aber jede Zeile prüfen und erklären
    Am Ende ist die Qualität der Beteiligung entscheidend, nicht die Art des Werkzeugs
  • Die eigentliche unveränderliche Bedingung ist Verantwortungsbewusstsein. Wer einen Patch einreicht, muss auch für Design und Wartung einstehen
  • KI kann Menschen allerdings dazu verleiten, sich dieser Verantwortung zu entziehen

• Langfristig wird KI sich wohl so weit entwickeln, dass menschliche und KI-Erzeugnisse schwer zu unterscheiden sein werden
  Wenn sie irgendwann „gut genug“ ist und wie von Menschen gemacht wirkt, frage ich mich, was dann passiert

  • Man kann das nicht vollständig verhindern, aber ich denke, Richtlinien festzulegen ist besser, als gar nichts zu tun
    Derzeit sind die meisten KI-PRs von niedriger Qualität, aber selbst bei hoher Qualität könnte man sie aus rechtlichen oder ideologischen Gründen ablehnen
  • KI-Beiträge sollte man letztlich als Erweiterung einer Person sehen. Das Konto muss zu einem echten Menschen gehören, und dessen Ruf muss auf dem Spiel stehen
  • Wenn plötzlich riesige Mengen Code auftauchen, kann das auf KI-Nutzung hindeuten. Wichtig ist nicht, ob KI verwendet wurde, sondern ob das Problem verstanden wird
  • KI bleibt weiterhin bei tokenweiser Vorhersage, und daran unterscheidet sie sich von von Menschen entworfenen Programmen
    Übermäßig kleinteilige Abstraktionen oder unnötiges Refactoring sind häufig
    Dass Menschen KI als Werkzeug verwenden, ist in Ordnung, aber bis KI den Menschen ersetzt, ist es meiner Ansicht nach noch weit
    Allerdings erhöht der Missbrauch von Vibecoding die Kosten für Review und Wartung drastisch
  • Letztlich ist Code von Leuten, die KI richtig einsetzen, nicht von menschlich geschriebenem Code zu unterscheiden. Das Problem ist nicht das Werkzeug, sondern seine Nutzung

• Ich vertrete die Position: „Wenn es funktioniert, reicht das“
  Wenn der Code die Kriterien Funktionalität, Dokumentation, Tests und Korrektheit erfüllt, ist es egal, ob ihn KI oder ein Mensch geschrieben hat
  Wichtig ist, die „Definition von funktioniert“ klar zu machen und ein kompetentes Review-System zu haben

• KI kann Tausende Zeilen Code auf einmal erzeugen und als PR einreichen, aber letztlich muss man die Größe auf reviewbare Einheiten begrenzen
  Selbst wenn KI alle Tests besteht, ist es riskant, wenn der Autor den Inhalt nicht versteht
  Es braucht eine Begrenzung des Arbeitsumfangs und eine bisherige Historie manueller Beiträge

• Debians Richtlinie ist einfach — „Niemand soll zu Schaden kommen“. Das ist ein guter Grundsatz

• Es wurde gefragt, ob Debian eine Regel hat, die verbietet, fremden Code als den eigenen einzureichen
  Tatsächlich ist das durch Urheberrechtsverletzung ohnehin illegal, daher existiert diese Regel implizit auch ohne ausdrückliche Formulierung
  LLMs sind keine Menschen, aber die Urheberrechte an ihrem Code sind weiterhin unklar

• Vibecoding bei Web-Apps oder Mobile-Apps mag egal sein, aber KI bei kritischer Infrastruktursoftware wie Kernel, Compiler oder Betriebssystemen einzusetzen, ist riskant
  In solchen Bereichen braucht es formal verifizierbare Sprachen wie Ada/SPARK
  Die Vorstellung, irgendwann in einem Auto mit einem von KI erzeugten Bremssystem zu fahren, ist beängstigend

  • Stimme zu. Kritische Systeme brauchen größte Sorgfalt, und LLMs bringen weder genug Sorgfalt noch genug Urheberrechts-Sicherheiten mit
  • Soweit ich weiß, gibt es in der Automobilindustrie tatsächlich schon seit vor der KI viel automatisch generierten Code

• „YOLO-artige Code-Einreichungen“ sind weit weniger akzeptabel als Code, bei dem jemand zwar KI verwendet hat, ihn aber so gründlich wie möglich verifiziert hat