Offenlegung bei Beiträgen mit AI-Tools obligatorisch

• In einer PR-Diskussion des Open-Source-Projekts Ghostty wurde die Auffassung geäußert, dass die Nutzung von AI-Tools ausdrücklich offengelegt werden muss
• Der Vorschlagende weist darauf hin, dass AI noch immer häufig Code von niedriger Qualität erzeugt und dass dies besonders problematisch ist, wenn unerfahrene Nutzer Beiträge ohne Prüfung einreichen
• Ziel der Offenlegung ist es, dass Maintainer die Verlässlichkeit eines PR einschätzen können und menschlichen Beitragenden pädagogisches Feedback geben, bei rein AI-generierten Beiträgen jedoch unnötigen Aufwand vermeiden
• Ein weiterer Teilnehmer schlug vor, über ein PR-Template eine Checkliste zu ergänzen, die auch die Nutzung von AI umfasst
• Außerdem wurde die Idee eingebracht, dass AI-Tools automatisch eine spezielle Byline standardisieren und in GitHub-Commit-Messages festhalten, sodass Transparenz und Sichtbarkeit des Tools zugleich gewährleistet werden

---

Warum die Offenlegung von AI-Nutzung nötig ist

• Mitchellh sagt, dass er AI-Tools mag und sie selbst nutzt, die Situation derzeit aber so bewertet, dass keine gleichwertige oder bessere Qualität garantiert werden kann
  • Besonders wenn Anfänger mit unzureichender Review-Kompetenz AI-Code unverändert als PR einreichen, ist die Qualität sehr niedrig
  • Dass Maintainer in solchen Fällen Zeit für unnötige Reviews und Feedback aufwenden müssen, kritisiert er als „Täuschung“
• Wenn die Nutzung von AI daher ausdrücklich offengelegt wird, können Maintainer einschätzen, wie sorgfältig sie einen Beitrag prüfen müssen

Vorschlag zur Einführung eines PR-Templates

• Yawaramin schlug vor, die PR-Template-Funktion von GitHub zu nutzen, um auch die AI-Nutzung aufzunehmen
  • Gleichzeitig könnten auch Checklisten wie das Developer Certificate of Origin(DCO) aufgenommen werden
• So können alle Beitragenden auf konsistente Weise die Nutzung von AI kenntlich machen

Idee für eine Standardisierung auf GitHub-Ebene

• Tobi schlug vor, auf GitHub-Ebene einen AI-spezifischen Byline-Standard zu schaffen
  • Jedes Mal, wenn ein AI-Tool verwendet wird, würde dies in der .git-Staging-Datei vermerkt und automatisch der Commit-Message hinzugefügt
  • GitHub könnte dies auflisten und auf das Tool verlinken → Maintainer könnten die Herkunft prüfen
  • Gleichzeitig müssten AI-Tools nicht länger wie bisher Co-Authors spamartig missbrauchen
• Dieser Ansatz wird als Lösung bewertet, die Transparenz, Tool-Promotion und Effizienz für Maintainer zugleich erfüllt

[GN⁺]

Hacker-News-Kommentare

• Es wird darauf hingewiesen, dass auch beim Einsatz von "AI" eine Kontaminierung mit geistigem Eigentum auftritt, und wir ignorieren diese Tatsache. Wenn jemand den gesamten Code aller Open-Source-Projekte auswendig könnte und ihn bei Bedarf wortwörtlich hinschreiben würde, müsste eine solche Person in unserem Unternehmen selbstverständlich verboten werden. Bei AI hingegen wird diese Tatsache mit allerlei Rationalisierungen und Ausreden geleugnet. Tatsächlich werden dabei verschiedenste Codes einschließlich GPL in locker „gewaschener“ Form übernommen, und das birgt für IP-basierte Unternehmen ein verheerendes Risiko.
  • US-Gerichte haben bereits entschieden, dass die Nutzung von Trainingsdaten ein transformativer (transformative) Zweck ist. Es wird noch viel im Detail zu klären geben, aber letztlich ist das eine unumkehrbare Veränderung. Wenn wir wollen, dass die Schaffung von IP wirtschaftlich nachhaltig bleibt, muss auch das zugehörige Rechtssystem geändert werden.
  • Folgt man dieser Logik, müsste man auch StackOverflow oder Lehrbücher in fast allen Fachgebieten verbieten. In der Realität kommen Programmierer nicht darum herum, den Code anderer Leute zu sehen.
  • Tatsächlich nehmen wohl nur Menschen mit finanziellen Interessen die rechtlichen Fragen rund um AI ernst. Glücklicherweise ignoriert die Mehrheit dieses Thema in den meisten Fällen, und auch das Rechtssystem funktioniert gut, solange es den Fortschritt nicht behindert.
• Ich fand den Teil von mitchellh, in dem er sagt, dass man „neue Beitragende bis zum Ende begleitet und ihnen hilft, damit ihr PR gemergt wird“, besonders beeindruckend. Durch Feedback zu wachsen, ist für Nachwuchsentwickler wirklich wertvoll. Wenn die Person, die den PR einreicht, dieses Feedback aber sofort an eine AI weitergibt und selbst nichts lernt, dann ist das Zeitverschwendung.
  • Für Nachwuchsentwickler wird es künftig gar keine Arbeitsumgebung mehr ohne AI geben.
• Ich freue mich sehr, dass die heutige HN-Startseite mit guten Inhalten voller realistischer Praxiserfahrungen gefüllt ist. Es gibt viele ehrliche Geschichten, ohne unnötige Panikmache oder Übertreibung. Auf meinem privaten Rechner deaktiviere ich AI-Assistenz, und auch im Unternehmen nutze ich sie nur sehr eingeschränkt, wenn es wirklich nötig ist. AI-Assistenz ist bei kleinen, atomaren Aufgaben sehr stark, bei zusammengesetzten Aufgaben aber miserabel. Letztlich hängt bei AI alles davon ab, wie Menschen sie einsetzen. Menschliche Intelligenz ist der Kern.
  • Der Aussage „AI ist nur so intelligent, wie der Mensch, der sie bedient“ stimme ich immer mehr zu. Ich konnte früher nicht verstehen, wie beim Einsatz derselben AI völlig unterschiedliche Ergebnisse herauskommen, aber inzwischen spüre ich, dass AI wirklich keine Magie ist. Rückblickend denke ich, dass ich naiv war zu erwarten, dass Menschen, die nicht einmal ihren Teamkollegen etwas erklären können, aus AI echten Wert herausholen würden. Eher wird AI den Abstand zwischen durchschnittlichen und großartigen Ingenieuren noch vergrößern. Ich habe weiterhin gemischte Gefühle, aber ich verstehe inzwischen, warum AI für manche nutzlos wirken kann.
  • Aus Frederik P. Brooks’ „No Silver Bullets, Refired“ wird die Schlussfolgerung zitiert, dass Softwareentwicklung inhärent komplex ist und man statt auf revolutionäre Wundermittel zu warten lieber schrittweise Produktivitätssteigerungen anstreben sollte. Diese Sichtweise wirkt realistisch und zugleich hoffnungsvoll.
  • Ich finde die Aussage „AI ist nur so intelligent, wie der Mensch, der sie bedient“ interessant. Letztlich waren die Hauptfiguren in Posts wie „Ich habe mit AI an einem Tag eine coole Bibliothek gebaut“ von Anfang an einfach sehr gute Entwickler.
  • Ich stimme ebenfalls zu. Bei uns im Unternehmen ist gerade Hack Week, und wir testen AI-Tools unternehmensweit. Gute Ergebnisse kommen vor allem bei analytischem Ansatz, Guardrails, grounded generation und ähnlichen Dingen in realen Anwendungen heraus. In letzter Zeit fühlt es sich so an, als sei der unnötige Chatbot-Hype vorbei und das Paradigma wieder auf das Wesen von Machine Learning zurückgesetzt worden.
  • Ich denke, Menschen treffen die Kernentscheidungen, und danach verbindet AI den Rest. Was genau eine Kernentscheidung ist und was bloßes Verbinden von Punkten ist, unterscheidet sich je nach Domäne, aber in Wirklichkeit besteht der Großteil des Codes (etwa 80–90 %) aus einfacher Wiederholung bzw. Verknüpfung. Wenn man diese Grenze gut einhält, ist der Produktivitätsgewinn enorm. Übergibt man AI dagegen die Kernentscheidungen, ist der Schaden noch größer; oft ist Wegwerfen und Neuaufsetzen besser. Beispiele für Kernentscheidungen sind Datenbankdesign, Typdefinitionen, Abhängigkeiten, System-/Infrastruktur-/UI-Design, Auswahl der Testfälle und die Struktur der Code-Organisation. Dinge, die AI gut kann, sind dagegen CRUD, API-Handler, einfache Transformationen von Datenstrukturen, Deployment-Skripte, Testimplementierungen, UI-Komponentencode, Styling und das Aufräumen temporärer Daten. Auch bei Recherche, Ideenfindung und dem Erkunden von Alternativen hilft AI, aber Schlussfolgerungen und die eigentliche Implementierung müssen Menschen selbst verantworten.
• Ich bin kein großer AI-Fan, sehe sie aber einfach als eines von vielen Werkzeugen. Mir ist egal, wie jemand einen PR vorbereitet hat, solange das Ergebnis gut ist. Wenn der Maintainer vor dem Einreichen des PRs aber etwas verlangt, gehört es sich meiner Meinung nach, sich danach zu richten.
  • Woher ein PR kommt und wie er zustande gekommen ist, ist wichtig. Reviewer machen auch Fehler und haben Grenzen, deshalb wird Vertrauen wichtig. Ohne Vertrauen sollte so etwas gar nicht erst in den Review-Prozess aufgenommen werden. Dass das Linux-Kernel-Team die University of Minnesota wegen ihrer Experimente blockiert hat, hatte denselben Grund.
  • Auf das Kernargument des Textes – nämlich „Das Ziel ist, neuen Beitragenden beim Wachsen zu helfen, aber wenn das Gegenüber AI ist, ist es nur Zeitverschwendung“ – scheint keine echte Antwort gegeben worden zu sein.
  • Mit AI kann man auch 1.000 PRs pro Tag erzeugen. Viele denken nur an gut gemachte PRs mit AI, aber in der Realität kann man Projekt-Maintainern mit AI enorm zusetzen.
  • Laut dem US Copyright Office sind von AI erzeugte Ergebnisse nicht urheberrechtlich schutzfähig. Deshalb muss schon aus Lizenzgründen offengelegt werden, dass AI verwendet wurde. Wer dagegen verstößt, kann das Urheberrecht am gesamten Werk verlieren. Details dazu finden sich im Bericht und auf der Hauptseite.
  • Wenn ich AI verwendet habe und danach gefragt werde, würde ich das immer offenlegen. Wenn aber nicht konkret danach gefragt wurde, würde ich es nicht „aus üblicher Höflichkeit vorab“ erwähnen. Ich denke, die meisten Menschen halten die Nutzung von AI für selbstverständlich oder kümmern sich gar nicht darum, und eher wirkt es wie eine kleine Markierung, die nur ablenkt – ähnlich wie Benachrichtigungen von dependabot, die in der Praxis niemanden wirklich interessieren.
• Die Frage „Was ist dann mit meinem Autocomplete?“ kam ein paar Mal auf. Für einfache Schlüsselwörter oder kurze Phrasen wie bei einfachem Tab-Autocomplete gibt es in der Richtlinie ausdrücklich eine Ausnahme, sodass das nicht offengelegt werden muss. Man solle das Dokument (oder den PR) bitte ordentlich lesen.
• Diese Richtlinie überzeugt mich, weil sie zusätzlichen Kontext liefert. Viele frühere AI-Richtlinien, die ich gesehen habe, kamen eher einer ideologischen Erklärung gleich. Hier werden die Gründe für die Anforderungen und die künftige Richtung erläutert, was viel praxisnäher wirkt. Ich wünschte, mehr Dinge würden auf diese Weise gemacht.
• Ich habe die Sorge, dass diese Richtlinie letztlich nur ehrlichen Menschen die Nutzung von AI erschwert. Wird nicht am Ende jeder versuchen, es zu verheimlichen, weil ein PR weniger Beachtung findet, sobald man sagt, dass AI im Spiel war?
  • Ich glaube nicht, dass es so einfach ist. Auch der Verfasser der Richtlinie (mitchellh) nutzt selbst LLMs. Wenn man also erklären kann, dass man den eigenen Beitrag ausreichend verstanden hat und AI nur als Hilfsmittel eingesetzt wurde, dürfte das nicht zu großem Vertrauensverlust führen.
  • Die Sorge könnte real werden. AI erzeugt massenhaft Code, der „ungefähr richtig aussieht, in Wirklichkeit aber Murks ist“. Wenn sich also Misstrauen gegenüber AI-Code aufbaut, dann ist das ein Problem der AI, nicht der Menschen. Wir brauchen bessere AI-Coding-Tools.
  • Sobald man sagt „ich habe chat-gpt benutzt“, geht man sofort unter; tut man aber wissend, ohne etwas zu sagen, bekommt man Lob. Es geht bereits für alle in Richtung Verschweigen der AI-Nutzung.
  • Ich halte es nicht für besonders sinnvoll, das überhaupt als Problem zu betrachten.
  • Es geht nicht darum, „keine AI zu verwenden“, sondern darum, im PR ehrlich anzugeben, wenn man sie verwendet hat.
• Ich frage mich, warum sogar eine detaillierte Offenlegung wie „Ich habe ChatGPT genutzt, um die Codebasis besser zu verstehen, den eigentlichen Code aber selbst geschrieben“ verlangt wird.
  • Mit einer solchen Erklärung kann sich der Reviewer auf mögliche Missverständnisse oder Irrtümer beim „Verständnis der Codebasis“ als Review-Punkt konzentrieren.
  • Ich bin selbst kein Entwickler, aber mit solchen AI-Assistenten hat sich meine Zeit für die Erkundung von Code deutlich verkürzt. Persönlich hat mir AI wirklich sehr geholfen.
• Ich finde das Muster gut, bei dem jeder Prompt, der zur Erstellung des PR verwendet wurde, beigefügt wird. LLMs sind keine völlig deterministischen Werkzeuge, aber es hat Wert, den Kontext zu hinterlassen, über welche Schritte bzw. Prompts man zum Ergebnis gekommen ist.
  • In der Praxis ist das sehr unpraktisch. Selbst für einen einzigen AI-basierten PR vermischen sich 10 bis 20 Prompts, Tests, manuelle Kontextanpassungen, manuelles Coden und viele weitere Schritte. Ich denke, eine Bildschirmaufzeichnung wäre eher sinnvoll.
  • Ich nutze eine Kombination aus dem vscode-Plugin specsytory und Cursor, protokolliere damit alle LLM-Interaktionen als md und reiche sie zusammen mit dem Pull Request ein, damit sie beim Code-Review als Referenz dienen.
• In meinem privaten Projekt habe ich sogar die Regel aufgestellt, offenzulegen, ob Editor-Autocomplete verwendet wurde.
  • Die Art, die Absicht zu vermitteln, ist interessant, aber heutige AI unterscheidet sich vollständig von herkömmlichem Autocomplete. Man kann sie zwar wie Autocomplete verwenden, aber das, was AI leisten kann, ist viel vielfältiger und tiefer. AI bloß als eine Art automatische Vervollständigung zu betrachten, ist nur eine persönliche Sichtweise; viele Menschen nutzen sie nicht so.
  • Tab-Autocomplete ist in der Richtlinie ausdrücklich als Ausnahme anerkannt.
  • Autocomplete ist meist nur ein syntaktisches Werkzeug, während AI versucht, sogar die Bedeutung und Struktur des Codes zu lenken.