LLM-generierte Themes und Plugins müssen entsprechend gekennzeichnet werden

Derzeit versuchen möglicherweise einige Personen, Plugins, Themes oder Komponenten hochzuladen, die vollständig von LLMs generiert wurden, ohne dies offenzulegen. Es gibt viele Gründe, warum es von Vorteil sein kann zu wissen, wenn etwas vollständig von einem LLM generiert wurde, und derzeit besteht keine Pflicht, solche Plugins entsprechend zu kennzeichnen. Persönlich würde ich es gerne im Voraus wissen, damit ich nicht versehentlich ein Plugin von niedriger Qualität installiere, das die typischen Leistungs-, Optimierungs- und UX-Probleme von LLM-Plugins aufweist.

Natürlich hängt dies davon ab, dass die Menschen ehrlich und offen sind (und Menschen, die KI-generierte Themen erstellen, mögen nicht besser wissen, was diese aussagen), aber ein Tag wie #ki-generiert, der auf überwiegend KI-generierte Assets gesetzt wird, wäre für alle von Vorteil.

2 „Gefällt mir“

Ich stimme der Auffassung nicht zu, dass ein von einem LLM generiertes Plugin von Natur aus von schlechter Qualität ist oder zwangsläufig unter Leistungs-, Optimierungs- oder UX-Problemen leidet. Die Qualität des Ergebnisses hängt stark von der Person ab, die das LLM steuert und dessen Ausgabe überprüft.

Ich habe stets Stolz auf die Software, die ich in den letzten 40 Jahren entwickelt habe, und die Einbindung von LLMs in meinen Workflow hat die Qualität meiner Arbeit verbessert, nicht verschlechtert.

Im Gegenteil habe ich zahlreiche handgeschriebene Plugins gesehen, die voller Sicherheitslücken, Leistungsproblemen und schlechten Designentscheidungen steckten, bei denen ich mir wirklich gewünscht hätte, der Autor hätte ein LLM verwendet. Am Ende kommt es auf die Qualität der Entwickler und des daraus resultierenden Codes an, nicht darauf, ob ein LLM an der Erstellung beteiligt war.

11 „Gefällt mir“

Mich interessiert, wie ihr das Prüfen und/oder Aktualisieren von von LLMs generiertem Code vorschlagt – für all jene von uns, die mit Vibe-Coding neue Funktionen umsetzen oder bereits ausgelieferte anpassen.

Ich weiß, dass eine gemeinsame Prüfung in öffentlichen Repositories ideal ist, aber ich möchte erst meine Hausaufgaben machen und nur Versionen veröffentlichen, bei denen ich mein aktuelles Können ausgeschöpft habe.

Ich stimme dem vorherigen Kommentar zu. Ich bin nicht gegen KI, aber gleichzeitig mir bewusst, dass ALLES, was sie generiert, von Menschen geprüft, verifiziert und aktualisiert werden muss.

Etwas Kurioses, das damit zusammenhängt:

1 „Gefällt mir“

Das ist absolut fair. Letztendlich darf ich nur für mich selbst sprechen, und meine Beobachtungen betreffen Apps von schlechter Qualität („Slop“), die alle gleich aussehen und generell von niedriger Qualität sind (sowohl in Bezug auf Funktionalität als auch Sicherheit), sowie bestehende Apps, deren Qualität seitdem sie die Arbeit weitgehend an LLMs ausgelagert haben, massiv abgenommen hat (wie z. B. Visual Studio Code und Formbricks; beides nutze ich seitdem nicht mehr). Selbst wenn deine App perfekt ist, bestehen dennoch ethische Bedenken, daher wäre es großartig, wenn es eine Art Benachrichtigung für diese Kreationen gäbe, wie vorgeschlagen. Das bedeutet nicht, dass jemand muss sich auf das Tag stützen, aber wenn man möchte, ist die Option schön.

Wie gesagt, ist dies ein System, das auf Vertrauen basiert, und es ist die alleinige Verantwortung des Entwicklers, sicherzustellen, dass es entsprechend gekennzeichnet ist. Offensichtlich gibt es einige Fälle, in denen das LLM sich selbst in den Git-Logs kennzeichnet (wie die meisten es tun), sodass ein TL3+ bei Bedarf handeln kann, indem er den GitHub einseht.

Ich schätze deine Antwort, danke dir. Meine Frage richtet sich auch an alle anderen und betrifft Tools, die derzeit zur Überprüfung von von LLMs generiertem Code existieren.

Ich bin kein Entwickler, aber es ist mir gelungen, Funktionen zu implementieren, die in Discourse nicht vorhanden waren. Und ich möchte das, was in meiner Macht steht, auf die bestmögliche Weise tun.

Ich werde über eine Kennzeichnung nachdenken, falls ich meine Repositories veröffentliche; für den Moment sind sie ausgerechnet deshalb privat, weil ich sie teste, und ich bin daran interessiert, es richtig zu machen, bevor ich sie der Community zur Verfügung stelle.

Ich wäre extrem überrascht, wenn der Großteil des Core-Codes (inklusive Core-Plugins) heute nicht mit Coding Agents erstellt würde – so sehr hat sich die Entwicklung verändert.

Meiner Meinung nach ist es mittlerweile sehr schwer zu rechtfertigen, Coding Agents bei den meisten Aufgaben nicht einzusetzen, denn der Effizienzverlust würde schlicht keinen wirtschaftlichen Sinn ergeben.

3 „Gefällt mir“

Mich stört es überhaupt nicht, „wie ein Plugin entstanden ist“ oder ob der Entwickler dabei einen Bleistift oder einen Kugelschreiber benutzt hat.

„Hier ist keine KI im Spiel“ gibt mir nicht den geringsten zusätzlichen Vertrauensvorschuss, wenn es um die Installation eines Themes oder Plugins geht.

Allerdings … gibt es ein viel ernsthafteres Problem, das wir bei CDCK angehen müssen.

Die Kern-Plugins und der Quellcode von Discourse werden regelmäßig auf Sicherheitslücken überprüft. Wenn jemand einen unterstützten Channel installiert, hat er ein gewisses Vertrauen in die Sicherheit des Codes.

Die Drittanbieter-Plugins und -Themes hier sind hingegen „das wilde Westen“: Jeder kann beitragen, wir scannen sie nicht auf Sicherheitslücken und stellen nicht sicher, dass sie den besten Praktiken entsprechen. Das setzt die Community einem Risiko aus.

Ich möchte eine Welt erreichen, in der „Version XYZ“ eines Themas zumindest automatisch gescannt wird, um Self-Hostern zumindest ein gewisses Maß an Sicherheit zu geben.

Meine Vision ist hier also das komplette Gegenteil: Ich möchte, dass Versionen von Drittanbieter-Themes und -Plugins vor der Veröffentlichung hier einer Art KI-Scan unterzogen werden.

8 „Gefällt mir“

Code-Reviews durch LLMs sind meiner Meinung nach nach ethischen Gesichtspunkten völlig anders als „Claude, bau mir diese App und mach keine Fehler“ und das Ergebnis mit wenig bis keiner eigenen Validierung oder Bearbeitung zu veröffentlichen. Leider kann man Endnutzer nicht wirklich zur Verantwortung ziehen, und egal wie sehr man sich bemüht, jemand wird immer einen Weg finden, etwas Maliziöses herunterzuladen. Aber unabhängig davon, wie ethisch LLMs sind, ist das ein anderes Thema und für diesen Thread nicht wirklich relevant.

Und das ist völlig in Ordnung! Ich schlage keinen pauschalen Bann für alles mit AI-Beteiligung in Customization vor. Ich würde es nur gerne korrekt taggen, damit diejenigen, die diese Dose voller Würmer nicht öffnen wollen, es auch nicht versehentlich tun.

Ich habe viele Bedenken hinsichtlich LLM-basierter Tools (und deren Ergebnisse). Nicht nur die Sicherheits-, Rechts-, Zuverlässigkeits- und Umweltprobleme. Das ist aber nicht das Hauptthema hier.

Sicherheit im weiteren Sinne ist hier das entscheidende Problem. Egal, ob der Code von KI generiert wurde oder nicht.

Welche Tools nutzt CDCK für Sicherheitsprüfungen? Verschiedene davon wären auch für Dritt-Erzeugnisse wichtig.

Aber es gibt noch mehr zu prüfen: Mit welchen externen Systemen kommuniziert das Dritt-Erzeugnis? Die meisten Sicherheitsanalyse-Tools akzeptieren, dass Software mit externen Servern kommuniziert, ohne dass ein Heartbeat erfolgt. Eine rein kosmetische Theme-Komponente sollte jedoch keine Aufrufe an externe Server ausführen. Das Dritt-Erzeugnis kann also Sicherheitslücken enthalten oder Probleme verursachen, die die Verfügbarkeit beeinträchtigen. Es könnte aber auch Daten exfiltrieren.

Da stimme ich zu 95 % zu. Und jetzt reden wir über Discourse – stell dir vor, wir wären in der WordPress-Welt!

(Die fehlenden 5 %: Ich denke nicht, dass es das „wilde Westen“ ist – Sicherheitsprobleme werden über Meta an die jeweiligen Drittanbieter-Entwickler gemeldet und im Allgemeinen ziemlich schnell behoben).

Aber gleichzeitig ist meine Erfahrung, dass LLMs (heutzutage) sichereren Code generieren als der durchschnittliche menschliche Plugin-Autor. Und man kann einem Plugin jeden anständigen LLM vorlegen und ihn fragen: „Finde und behebe alle Sicherheitsprobleme“ – und er wird es tun, selbst wenn der Mensch kaum Sicherheitswissen hat.

Ich habe in den letzten zehn Jahren manuell Plugins überprüft und habe viel gesehen: SQL-Injection (von Leuten, die dachten, ActiveRecord sei zu ausgeklügelt), API-Schlüssel-Einstellungen mit client: true, komplettes Fehlen von Autorisierung und Zugriffskontrollen, fehlendes Rate Limiting. All das wird von LLMs in kürzester Zeit und ohne großen Aufwand gefunden und behoben.

Also nochmal: Ich denke, LLMs haben das besser gemacht, nicht schlechter.

Du verknüpfst LLM-generierten Code immer noch mit einer „Dose voller Würmer“ – das ist zu schwarz-weiß.

4 „Gefällt mir“

Jack McDade hat diesen Ansatz mit dem Statamic-Add-on-Verzeichnis verfolgt

Ich begrüße diesen Ansatz und fand ihn hilfreich, um zu bestätigen, was wir bereits wussten und was getan werden musste. Er hilft auch, das Vertrauen in den Code zu stärken.

Es scheint, als könnte hier etwas Ähnliches ohne allzu großen Aufwand von Team umgesetzt werden.

4 „Gefällt mir“

Mich beunruhigt auch die geringe Qualität von Plugins und Komponenten, und ich traue ihnen nicht wirklich, wenn sie zu 99 % von jemandem per „Vibe Coding“ erstellt wurden, der sich mit Programmierung nicht auskennt.

Aber ich glaube auch den erfahrenen Programmierern hier und da, die sagen, dass schlechte Programmierer schon lange vor der KI existierten[1]. Schlampiger und unzuverlässiger, fehlerhafter Code wurde seit jeher von Hand geschrieben.

Was mich beunruhigt, ist, wenn ich eine per „Vibe Coding“ erstellte App/ein Plugin/was auch immer sehe und vermute, dass der Autor den Code nicht überprüft hat.

Ich habe zwar grundlegende Programmierkenntnisse, habe aber seit langer Zeit nicht mehr programmiert und war es auch nie wirklich. Ich habe es für einige Projekte mit „Vibe Coding“ versucht.

Anfangs war ich sehr zögerlich, sie offiziell auf Meta zu veröffentlichen, aber schließlich habe ich es getan, nachdem ich mir die Zeit genommen hatte, jeden Codeabschnitt zu überprüfen und zu verstehen, was er tut, und meinen Ansatz auch öffentlich in meinen Themen dargelegt habe. Nicht dass ich alles, was ich vor der Veröffentlichung dieser Plugins gelesen habe, im Detail im Kopf hätte, aber zumindest konnte ich mir zum Zeitpunkt der Veröffentlichung sicher sein, dass die Arbeit zuverlässig und sicher war.

Ich habe ein gutes Beispiel, das verdeutlicht, wie „Vibe Coding“ dazu führen könnte, dass ich ein sehr unsicheres Plugin veröffentliche.

Bevor ich an 🖼️ Topic Gallery arbeitete, erstellte ich hier ein Proof of Concept für ein ähnliches Plugin: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
Es funktionierte großartig, und die KI folgte meinen Anweisungen.

Es gab aber ein Problem: Obwohl die Funktion eindeutig eine Moderationsfunktion war, berücksichtigte die KI keine Berechtigungen: Jeder Benutzer, einschließlich Besucher, konnte diese Seite öffnen und alle von allen Benutzern hochgeladenen Dateien sehen. Für mich war es offensichtlich, dass dies nur für Administratoren sein sollte, aber die KI hat das nicht „durchdacht“. Und weil ich es nicht explizit verlangt hatte, erstellte sie standardmäßig eine öffentliche Seite.

Deshalb sage ich mir immer wieder, dass, wenn ich selbst und die KI einen solchen Sicherheitsleck übersehen konnten, Nicht-Programmierer, die per „Vibe Coding“ TCs und Plugins erstellen, leider dasselbe tun könnten.

Die Meinungen zu KI-Code in der Softwareentwicklung sind stark polarisiert. Man muss nur einen beliebigen Open-Source-Projekt ansehen, in dem Claude als Mitverfasser der letzten Commits genannt wird, um einen Strom an Hass von bestimmten Personen zu sehen.
Ich bin überzeugt, dass wir solche Dinge mit Vorsicht betrachten sollten und dass unsere Meinungen nuancierter sein sollten.

Ich bin nicht besonders dafür, ein „vibe-coded“-Tag einzuführen, das die Popularität gut codierter und sicherer Customizations und ihrer Autoren unnötig schädigen könnte.

Ich weiß, dass jetzt jeder Customizations erstellen kann, es jeden Tag mehr davon geben könnte und nicht genügend Leute da sind, um sie zu überprüfen.

KI-Überprüfung ist vielleicht die Lösung. Meine Bauchintuition mag diese Idee aus verschiedenen Gründen nicht wirklich, aber ich glaube, dass, wenn Sam diese Art von Lösung vorschlägt, sie wahrscheinlich eine gute ist, weil ich seinen Fähigkeiten und seinem Urteil sehr vertraue. Besonders da ich selbst keine Ahnung habe. :laughing:

Vielleicht könnten einige Entwickler hier, die sich mit Programmierung und dem Discourse-Ökosystem auskennen, einen Titel haben, der ihre Expertise in diesem Bereich explizit zeigt, damit sie auch von Besuchern, die hier nur nach Customizations suchen, ohne sich zu registrieren, als vertrauenswürdige Entwickler angesehen werden. Das wäre das Gegenteil von dem, was du forderst, darkpxlz. Anstatt potenziell nicht vertrauenswürdige Customizations zu „schämen“, würden wir die vertrauenswürdigen hervorheben. :slight_smile:

Nur ein Gedanke zum Nachdenken. :person_shrugging:


  1. Das weiß ich, ich war einer von ihnen! ↩︎

5 „Gefällt mir“

Es ist durchaus möglich, dass ich in einer anti-KI-Echokammer gefangen bin, die durch die Medien, die ich konsumiere, und die Menschen, mit denen ich täglich interagiere, geprägt ist. Ich war mir fast sicher, dass diese Anfrage nicht so unbeliebt sein würde, wie sie es war. Aber wenn alle hier tatsächlich das Coden mit LLMs lieben und nicht nur aus Transparenzgründen ein Tagging wünschen, wer bin ich, das zu verhindern? Das Erkennen von KI-generiertem Code ist nach wie vor relativ einfach, sodass jeder, der es wirklich vermeiden möchte (wie ich selbst), einfach die Mitwirkenden auf ein LLM-Tagging prüfen kann, wie ich es zuvor vorgeschlagen habe.

1 „Gefällt mir“

Da es sich um ein kontroverses Thema handelt, unterstütze ich persönlich deine ursprüngliche Anfrage. Diese würde dem Teil der Gemeinschaft gerecht werden, der derzeit eher skeptisch eingestellt ist (was durchaus verständlich ist).

Allerdings befürchte ich, dass wir am Ende fast alles mit einem Tag versehen würden, was den eigentlichen Zweck zunichtemachen würde.

Ich stimme auch anderen zu, dass nicht jeder KI-generierte Code gleichwertig ist. Ein Teil davon wird von neueren, teureren Modellen erstellt und von erfahrenen Entwicklern begleitet, während es in anderen Fällen vielleicht ein One-Shot von einer weniger erfahrenen Person ist, die ein weniger leistungsfähiges Modell verwendet, und das Repository möglicherweise keine bewährten Methoden (Best Practices) einhält. Das lässt sich nur beurteilen, indem man das Repository selbst prüft und beobachtet, ob es häufig zu Problemen kommt.

5 „Gefällt mir“

Ich denke, dass eine gründliche Überprüfung durch Menschen und KI für jede wichtige Software eine gute Idee ist, unabhängig davon, ob sie ursprünglich von Menschen oder von KI geschrieben wurde. Es wäre schön, wenn es bessere Werkzeuge gäbe, um Software zu überprüfen und nachzuverfolgen, wer welche Versionen welcher Pakete geprüft hat. Für Rust/Cargo gibt es derzeit einige Tools, die in diese Richtung gehen: Crev, cargo-vet und Thirdpass. Ich habe auch eine Diskussion auf den Swift-Foren gestartet.

1 „Gefällt mir“

Ich gehöre zum Lager derer, die für das „Warum“ hinter dem Label plädieren. Die Debatte über Label ja oder nein ist ein bisschen ein roter Faden. Für mich ist das entscheidende Problem, die Qualität von Code und Produkten im Plugin-Verzeichnis sicherzustellen – das ist die oberste Priorität. Discourse trägt in diesem Bereich die letzte Verantwortung, aber die Community kann helfen. In diesem Sinne habe ich zusammen mit meiner neuesten besten Freundin an der Erstellung einer DiscourseSkill.md gearbeitet. Ursprünglich wollte ich sie nur intern nutzen, aber vielleicht finden andere sie auch nützlich. Schaut euch dazu gerne hier an: DiscourseSkill.md