Exiger l'étiquetage des thèmes et plugins générés par LLM

Actuellement, certaines personnes peuvent essayer de téléverser des plugins, des thèmes ou des composants entièrement générés par des LLM sans le déclarer comme tel. Il existe de nombreuses raisons pour lesquelles il peut être utile de savoir si quelque chose a été entièrement généré par un LLM, et il n’existe actuellement aucune obligation de déclarer ces plugins comme tels. Personnellement, j’aimerais le savoir à l’avance afin de ne pas finir par installer un plugin de mauvaise qualité, présentant de nombreux problèmes de performance, d’optimisation ou d’expérience utilisateur, comme c’est souvent le cas avec les plugins générés par LLM.

Bien sûr, cela suppose que les gens soient honnêtes et transparents (et les personnes ayant des sujets générés par IA peuvent ne pas savoir mieux que ce qui est indiqué), mais l’ajout d’un tag comme #ai-généré sur les assets principalement générés par IA serait bénéfique pour tout le monde.

2 « J'aime »

Je ne partage pas l’idée qu’un plugin généré par un LLM soit intrinsèquement de faible qualité ou qu’il souffre nécessairement de problèmes de performance, d’optimisation ou d’expérience utilisateur. La qualité du résultat dépend largement de la personne qui guide le LLM et qui examine sa sortie.

J’ai toujours pris soin du logiciel que je développe depuis 40 ans, et l’intégration des LLM dans mon flux de travail a amélioré la qualité de mon travail, pas l’inverse.

À l’inverse, j’ai vu de nombreux plugins écrits à la main, truffés de vulnérabilités de sécurité, de problèmes de performance et de mauvaises décisions de conception, où j’aurais sincèrement souhaité que l’auteur utilise un LLM. En fin de compte, ce qui compte, c’est la qualité du développeur et du code résultant, pas le fait qu’un LLM ait été impliqué dans sa rédaction.

11 « J'aime »

Je me demande comment vous recommanderiez de relire et/ou de mettre à jour le code généré par des LLM, pour ceux d’entre nous qui se lancent dans le « vibe-coding » afin d’implémenter de nouvelles fonctionnalités ou de personnaliser celles qui sont effectivement livrées.

Je sais qu’une revue collective dans des dépôts publics est idéale, mais je voudrais d’abord faire mon travail et ne publier que des versions qui ont épuisé ma capacité actuelle.

Je suis d’accord avec le commentaire précédent : je ne suis pas anti-IA, mais je suis conscient que TOUT ce qu’elles génèrent doit être audité, vérifié et mis à jour par des humains.

Quelque chose de curieux, en lien avec le sujet :

1 « J'aime »

C’est tout à fait juste et, au fond, je ne suis autorisé à parler qu’en mon nom propre. Cela se base sur mes observations concernant les applications de faible qualité « slop » qui se ressemblent toutes et sont généralement de mauvaise qualité (tant en termes de fonctionnalités que de sécurité), ainsi que sur les applications existantes dont la qualité a considérablement chuté depuis qu’elles ont commencé à déléguer une grande partie du travail aux LLM (comme Visual Studio Code et Formbricks ; j’ai cessé d’utiliser les deux depuis). Même si votre application est parfaite, il y a toujours des préoccupations éthiques, il serait donc excellent qu’il existe une forme de notification pour ces créations, comme suggéré. Cela ne signifie pas que quelqu’un doit se baser sur le tag, mais si vous le souhaitez, c’est une option appréciable.

Comme je l’ai dit, c’est un système basé sur la confiance et il incombe uniquement au développeur de s’assurer qu’il est étiqueté en conséquence. Évidemment, il y a certains cas où le LLM s’étiquette lui-même dans les journaux git (comme la plupart le font), de sorte qu’un utilisateur TL3+ peut prendre des mesures s’il le souhaite en consultant GitHub.

Je vous remercie pour votre réponse. Ma question s’adresse également à tout le monde et concerne les outils actuellement disponibles pour vérifier le code généré par les LLM.

Je ne suis pas développeur, mais j’ai réussi à implémenter des fonctionnalités qui n’existaient pas dans Discourse. Et je souhaite faire ce qui est à ma portée de la meilleure manière possible.

J’envisagerai d’ajouter des étiquettes si je publie mes dépôts ; pour l’instant, ils sont privés précisément parce que je les teste, et je tiens à le faire correctement avant de les partager avec la communauté.

Je serais extrêmement surpris si la majorité du code Core (y compris les plugins Core) n’était pas désormais développée à l’aide d’agents de codage, tant la façon de développer a changé.

À mon avis, il est désormais très difficile de justifier de ne pas utiliser d’agents de codage pour la plupart des tâches, car la perte d’efficacité serait tout simplement peu rentable.

3 « J'aime »

Je ne me préoccupe absolument pas de « la manière dont un plugin a été créé » ni de savoir si l’artisan a utilisé un crayon ou un stylo.

« Aucune IA ici » ne me donne pas la moindre once de confiance supplémentaire lorsqu’il s’agit d’installer un thème ou un plugin.

Cependant… il y a un problème beaucoup plus grave que nous devons aborder sur CDCK.

Les plugins de base et le code source de Discourse sont régulièrement soumis à des analyses de sécurité. Lorsqu’une personne installe un canal pris en charge, elle peut faire confiance à la sécurité du code.

Les plugins et thèmes tiers ici, en revanche, sont « l’Ouest sauvage » : n’importe qui peut contribuer, nous ne les soumettons pas à des analyses de sécurité et nous ne nous assurons pas qu’ils respectent les bonnes pratiques. Cela met la communauté en danger.

J’aimerais arriver à un état où la « version XYZ » d’un thème serait au moins automatiquement analysée, afin de donner aux auto-hébergeurs au moins une certaine tranquillité d’esprit.

Ma vision ici est donc tout le contraire :slight_smile: exiger que les versions des thèmes et plugins tiers passent par une sorte d’analyse par IA avant d’être proposées ici.

8 « J'aime »

À mon avis, au moins sur le plan éthique, la revue de code par une LLM est totalement différente de « Claude, construis-moi cette application et ne fais aucune erreur » et de publier la sortie avec peu ou pas de validation ni de modifications de votre part. Malheureusement, on ne peut vraiment pas obliger un utilisateur final à assumer ses responsabilités, et peu importe à quel point on essaie, quelqu’un trouvera toujours un moyen de télécharger quelque chose de malveillant. Mais de toute façon, à quel point les LLM sont éthiques est une autre conversation et n’est pas vraiment pertinent pour ce fil de discussion.

et c’est très bien ! Je ne propose pas une interdiction générale de tout ce qui implique l’IA dans Customization.. Je voudrais simplement que cela soit correctement balisé pour que ceux qui ne veulent pas ouvrir cette boîte de Pandore ne se retrouvent pas à le faire.

J’ai de nombreuses réserves concernant les outils basés sur les LLM (et leurs résultats). Ce ne sont pas seulement les problèmes de sécurité, juridiques, de fiabilité et environnementaux. Mais ce n’est pas le point principal ici.

La sécurité, au sens large, est le vrai enjeu ici, que le code soit généré par une IA ou non.

Quels outils CDCK utilise-t-il pour les contrôles de sécurité ? Certains d’entre eux seraient également importants pour les créations tierces.

Mais il y a encore plus de points à vérifier. Avec quels systèmes externes la création tierce communique-t-elle ? La plupart des outils d’analyse de sécurité acceptent qu’un logiciel communique avec des serveurs externes, sans mécanisme de vérification de vie (heartbeat). Mais un simple composant cosmétique ne devrait effectuer aucun appel vers un serveur externe. La création tierce peut donc contenir des failles de sécurité, ou des problèmes susceptibles de nuire à la disponibilité. Elle pourrait également exfiltrer des données.

Je suis d’accord à 95 % avec cela. Et maintenant, on parle de Discourse ; imaginez si nous étions dans l’univers de WordPress !

(Les 5 % manquants : je ne pense pas que ce soit « le Far West » — les problèmes de sécurité sont signalés via meta aux développeurs tiers et, en général, ils sont corrigés assez rapidement).

Mais en même temps, mon expérience m’a montré que les LLM (de nos jours) génèrent un code plus sécurisé que l’auteur de plugin humain moyen. Et on peut soumettre un plugin à n’importe quel LLM décent et lui demander de « trouver et corriger les problèmes de sécurité », et il le fera, même si l’humain ne dispose pas de grandes connaissances en matière de sécurité.

Je passe en revue manuellement des plugins depuis une décennie et j’en ai vu des tas : des injections SQL (par des personnes qui trouvaient ActiveRecord trop sophistiqué), des réglages de clés API avec client: true, une absence totale d’autorisation et de contrôles d’accès, un manque de limitation de débit. Tous ces problèmes sont détectés et corrigés par les LLM en un temps record et sans trop d’effort.

Donc encore une fois : je pense que les LLM ont rendu les choses meilleures, pas pires.

Tu associes toujours le code généré par les LLM à une « boîte de Pandore », c’est trop noir ou blanc.

4 « J'aime »

Jack McDade a adopté cette approche avec l’annuaire d’extensions Statamic

J’accueille favorablement cette approche, je l’ai trouvée utile pour confirmer ce que nous savions déjà devoir être fait. Elle aide également à renforcer la confiance dans le code.

Il semble qu’une approche similaire pourrait être implémentée ici sans trop d’effort de la part de l’équipe.

4 « J'aime »

Je suis également préoccupé par les plugins et composants de mauvaise qualité, et je ne leur fais pas vraiment confiance lorsqu’ils sont à 99 % générés par une IA par quelqu’un qui ne connaît rien à la programmation.

Mais je crois aussi que des programmeurs expérimentés, ici et là, affirment que de mauvais programmeurs existaient bien avant l’IA[1]. Du code bâclé, peu fiable et défaillant a été écrit à la main depuis des lustres.

Ce qui me préoccupe, c’est lorsque je vois une application, un plugin ou quoi que ce soit généré par une IA et que je soupçonne l’auteur de ne pas avoir relu le code.

Bien que j’aie des connaissances basiques en programmation, je n’ai pas codé depuis longtemps et j’ai toujours été médiocre. J’ai essayé de générer du code avec une IA pour quelques projets.

Au départ, j’étais très réticent à les publier officiellement sur le meta, mais je l’ai finalement fait après avoir pris le temps de relire et de comprendre ce que chaque partie du code faisait, et aussi d’exposer publiquement ma démarche dans mes sujets. Non que je me souvienne de tout ce que j’avais lu avant de publier ces plugins, mais au moins, je pouvais garantir la fiabilité et la sécurité au moment où je publiais ce travail.

J’ai un bon exemple pour illustrer comment la génération de code par IA aurait pu me faire publier un plugin très peu sûr.

Avant de travailler sur 🖼️ Topic Gallery, j’avais réalisé une preuve de concept d’un plugin similaire ici : A way to monitor user-uploaded files 🖼️ - #2 by Canapin
Il fonctionnait très bien, et l’IA suivait mes directives.

Il y avait un problème, cependant : bien que la fonctionnalité soit clairement une fonction de modération, l’IA n’a pas tenu compte des permissions : n’importe quel utilisateur, y compris les visiteurs, pouvait ouvrir cette page et voir tous les fichiers téléversés par tous les utilisateurs. C’était évident pour moi que cela devrait être réservé aux administrateurs, mais l’IA n’a pas « réfléchi » à cela. Et comme je ne l’ai pas demandé, elle a créé une page publique par défaut.

Je me répète donc que si moi et l’IA avons pu laisser passer une telle faille de sécurité, alors les non-programmeurs qui génèrent des TC et des plugins avec une IA pourraient malheureusement faire de même.

Les opinions sur le code généré par IA en matière de logiciels sont fortement polarisées. Il suffit de jeter un œil à n’importe quel projet open source populaire où Claude est cité comme co-auteur des derniers commits pour voir une avalanche de haine de la part de certaines personnes.
Je suis convaincu que nous devrions aborder ces questions avec prudence et que nos opinions devraient être plus nuancées.

Je ne suis pas particulièrement en faveur d’une sorte d’étiquette généré-par-ia qui pourrait nuire inutilement à la popularité des personnalisations bien codées et sûres et de leurs auteurs.

Je sais que désormais, n’importe qui peut produire des personnalisations, qu’il y en aura probablement de plus en plus chaque jour, et qu’il n’y a pas assez de personnes pour les relire.

La relecture par IA est peut-être la solution. Mon instinct n’aime pas vraiment cette idée pour diverses raisons, mais je crois que si Sam propose ce type de solution, c’est probablement une bonne idée, car je fais beaucoup confiance à ses compétences et à son jugement. D’autant plus que je ne m’y connais pas du tout moi-même. :laughing:

Peut-être que certains développeurs ici qui connaissent la programmation et l’écosystème Discourse pourraient avoir un titre qui montre explicitement leur expertise dans ce domaine, afin qu’ils puissent être considérés comme des développeurs de confiance, même par les visiteurs qui cherchent simplement des personnalisations ici sans s’inscrire. Ce serait l’inverse de ce que vous demandez, darkpxlz. Au lieu de « stigmatiser » les personnalisations potentiellement peu fiables, nous mettrions en avant celles qui sont fiables. :slight_smile:

Juste de la matière à réflexion, cependant. :person_shrugging:


  1. Je devrais le savoir, j’en faisais partie ! ↩︎

5 « J'aime »

Il est tout à fait possible que je sois pris dans une chambre d’écho anti-IA, due aux médias que je consomme et aux gens avec qui j’interagis au quotidien. J’étais presque certain que cette demande ne serait pas aussi impopulaire qu’elle l’a été, mais si tout le monde ici adore vraiment coder avec des LLM et ne veut pas d’un tag purement pour la transparence, qui suis-je pour m’y opposer ? La détection du code généré par LLM reste assez facile, donc si quelqu’un (comme moi) veut vraiment l’éviter, il peut simplement vérifier les contributeurs pour un tag LLM s’auto-identifiant, comme je l’avais suggéré précédemment.

1 « J'aime »

Compte tenu du caractère controversé du sujet, je soutiens personnellement votre demande initiale, qui répond aux besoins de la partie de la communauté qui est, pour l’instant, plutôt sceptique (ce qui est compréhensible).

Cependant, je crains que nous finissions par étiqueter presque tout, ce qui contredit un peu l’objectif initial, non ?

Je rejoins également les autres pour dire que tous les codes générés par IA ne se valent pas : certains sont produits par des modèles plus récents et plus coûteux, sous la supervision de développeurs expérimentés, tandis que dans d’autres cas, il peut s’agir d’une génération en une seule étape par une personne moins expérimentée utilisant un modèle moins performant, et le dépôt peut ne pas respecter les bonnes pratiques. On ne peut évaluer cela qu’en examinant le dépôt lui-même et en observant si les utilisateurs rencontrent fréquemment des problèmes.

5 « J'aime »

Je pense qu’une relecture approfondie, réalisée à la fois par des humains et par des IA, est une bonne idée pour tout logiciel important, qu’il ait été initialement rédigé par des humains ou par des IA. Il serait souhaitable de disposer de meilleurs outils pour examiner le code et suivre qui a passé en revue quelles versions de quels paquets. Il existe actuellement des solutions qui s’en rapprochent pour Rust/Cargo : Crev, cargo-vet et Thirdpass. J’ai également entamé une discussion sur les forums Swift.

1 « J'aime »

Je suis plutôt du camp de la question du pourquoi. La question des étiquettes ou de leur absence est un peu un faux débat. À mes yeux, le vrai enjeu est de garantir la qualité du code et des produits dans le répertoire des plugins, et c’est là que réside la priorité absolue. Discourse en porte la responsabilité ultime, mais la communauté peut y contribuer. Dans cette optique, mon plus récent meilleur ami et moi-même avons travaillé sur la création d’un fichier DiscourseSkill.md. Mon intention initiale était de l’utiliser en interne, mais d’autres pourraient peut-être le trouver utile. Dans ce but, jetez un œil à DiscourseSkill.md