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.
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.
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.
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.
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.
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ß.
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.