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

C’est un saut logique assez important dans ton raisonnement.

  • Si tu avais embauché un stagiaire ou passé 10 nuits toi-même, tu aurais pu ajouter un lecteur FLAC à ton application imaginaire. Prendre de mauvaises décisions produit n’est pas inhérent à l’utilisation des LLM, et le fait qu’ajouter une fonctionnalité inutile soit une perte d’effort de développement a toujours fait débat.

  • Les fonctionnalités supplémentaires ne rendent pas nécessairement ton application plus lente ni plus lourde en RAM ; ce problème a été résolu par le concept de chargement dynamique, il y a 40 ans.

Exactement. L’emphase est de moi :slight_smile:

4 « J'aime »

Non, cette distinction ne devrait pas être établie.

  • Le logiciel est-il sécurisé ?
  • Résout-il mon problème ?

Encore une fois, revenons à mon point de départ ici.

Si nous avons un problème de sécurité avec les thèmes, parlons d’un système de vérification.

Si nous avons un problème de qualité avec les thèmes, parlons de systèmes de vérification.

Mais non, je n’introduirai pas d’étiquette « développé sur Mac », « développé sur clavier rouge » ou « développé à 93,2 % par IA » sur les sujets, ça n’arrivera pas.

Combien d’IA j’utilise ? Je suis prêt à partager mes flux de travail dans un sujet séparé, mais je ne code plus à la main dans vim.

8 « J'aime »

Il serait fallacieux de rejeter tous les plugins générés par IA uniquement parce qu’ils ont été créés par une IA. Le fait d’être généré par IA a pu constituer par le passé un critère raisonnable pour identifier du contenu de mauvaise qualité, mais avec l’amélioration des modèles, il devient de plus en plus difficile de distinguer la production humaine de la production par IA. Si la préoccupation porte sur la qualité ou la sécurité, je pense qu’il serait plus prudent de considérer tout code comme potentiellement dangereux jusqu’à ce qu’il ait été examiné par un certain type de système de relecture par les pairs en open source.

Je pense que partager la façon dont l’équipe travaille avec l’IA aujourd’hui, des designers aux développeurs, en passant par le juridique, le marketing et d’autres domaines, intéresserait beaucoup de gens.

Connaître un peu les IA, comme moi, ne signifie pas savoir et comprendre comment une entreprise travaille vraiment avec l’IA au quotidien.

6 « J'aime »

J’ai lu tout ce qui est écrit ici et je vois les deux côtés. Je pense qu’il est à la fois bon et mauvais que les gens puissent simplement créer des plugins ici et les publier, même s’ils contiennent des vulnérabilités de sécurité « potentielles » susceptibles de compromettre une installation Discourse.

Un peu hors sujet.

Il existe un autre fournisseur de logiciels de forum (WoltLab) qui dispose, par exemple, d’une boutique de plugins. Avant toute publication, les plugins et les thèmes sont examinés par l’équipe. Peut-être serait-il une bonne idée de mettre en place quelque chose de similaire ici. Cependant, la question se pose toujours de savoir qui effectuerait cet examen, et je peux imaginer que cela exigerait un investissement important en temps et en personnel.

2 « J'aime »

Je peux affirmer avec 100 % de certitude que ce n’est absolument pas une idée viable, pour nous de passer en revue chaque plugin et thème tiers. (Ou du moins, pas manuellement par un humain)

Et si on disposait d’un ensemble d’outils sélectionnés pour tester les plugins ou les TC générés par LLM, supervisé, maintenu et mis à jour par l’équipe ?

Je sais que chacun peut tout à fait exécuter les tests individuellement, mais soyons honnêtes, tout le monde ne sait pas forcément comment faire.

Une méthode simple et fiable me semble être le meilleur des deux mondes.

C’est tout l’enjeu de ce sujet :

Il a été intéressant de voir les opinions de chacun sur les raisons pour lesquelles cette transparence peut être importante, tant sur le plan moral que sur le plan de la sécurité. Personnellement, je m’en fiche si quelque chose a été créé par un ingénieur logiciel de 30 ans qui code en Ruby depuis le début des temps, ou par un petit Timmy sans aucune expérience en programmation. Si c’est du code bâclé à 100 %[1], je ne l’utiliserai pas, cela serait hypocrite de ma part. Je comprends pourquoi c’est populaire, mais ce n’est tout simplement pas quelque chose sur quoi je vais m’engager. Si ces modèles avaient été entraînés de manière éthique et n’avaient pas provoqué de pénuries de composants ainsi qu’une épidémie de médias générés par IA, mon sentiment envers ces modèles serait peut-être moins négatif, mais ce n’est pas le monde dans lequel nous vivons.

Les préoccupations en matière de sécurité concernant les plugins en général sont également valables et ne se limitent pas à « cela a été créé par une IA ». C’est un problème difficile à résoudre et qui sort du cadre de ce sujet, qui n’est qu’une suggestion pour exiger des balises sur les actifs entièrement générés par des LLM.


  1. je refuse d’utiliser les termes « vibe-coding » ou « développement agentique » ↩︎

2 « J'aime »

Je ne vois toujours pas le problème que cette initiative cherche à résoudre. Quelqu’un peut-il me donner un exemple de plugin développé à l’aveugle (vibe coded) qui était médiocre, non sécurisé ou très gourmand en ressources ? Un plugin qui n’aurait jamais dû être annoncé ici, car c’était du n’importe quoi et une perte de temps pour tout le monde ?

Et s’il existe réellement des exemples, sont-ils suffisants pour constituer un problème ?

1 « J'aime »

À mon avis, il serait aussi utile d’avoir une sorte de liste de contrôle auto-certifiée pour les thèmes : combien de tests avez-vous effectués, êtes-vous prêts à recevoir des rapports sur la qualité et la sécurité, serez-vous réactif aux retours d’information.

Ou encore, quelle est votre processus de développement, en trois phrases maximum.

La valeur de vérité des réponses n’aura pas grande importance, mais la différence entre les thèmes auto-certifiés et ceux qui ne le sont pas pourrait constituer un signal utile pour la personne qui envisage d’installer le thème en question.

4 « J'aime »

Pour ma part, je ne fais jamais de « vibe-coding » pour aucune application, aucun projet ou aucun logiciel que je crée. J’utilise les chats IA pour faire rebondir des idées ou pour obtenir des clarifications, mais jamais pour l’ensemble du projet. C’est plus manuel, c’est vrai, mais au moins je sais ce que je fais et je ne confie pas aveuglément le tout à une autre entité.

Cependant, j’ai constaté que le codage assisté par IA a beaucoup progressé ces derniers mois. Il est vrai qu’à l’origine, le code était mal écrit ou truffé de vulnérabilités, mais je dirais qu’il s’est considérablement amélioré depuis. Les designs issus du « vibe-coding » restent assez reconnaissables (dégradés, bordures, émojis, etc.), même dans certains plugins que j’ai vus sur Meta. Mais ce qui compte, c’est que l’auteur l’a partagé par intérêt personnel et pour la communauté. Pas pour que quelqu’un vienne l’écraser et le qualifier de « n’importe quoi », mais parce qu’il a trouvé un succès réel avec ce plugin et souhaite le partager avec d’autres forums qui cherchent à obtenir la même fonctionnalité.

Je comprends ton point de vue sur les inquiétudes éthiques liées à l’IA, mais cela semble cibler l’IA en général, comme les entreprises qui découpent des livres, la consommation massive d’eau et d’électricité, etc. Tu mentionnes :

Mais comment cela se corrèle-t-il à l’utilisation de plugins ou de TC (thèmes de contenu) créés par IA ? Si tu n’aimes pas l’IA, très bien, n’en utilise pas. Mais le paysage de la programmation a changé radicalement avec l’introduction de l’IA, et des choses comme les plugins et les TC vont donc évoluer de la même manière. Vas-tu cesser d’utiliser Discourse entièrement maintenant, sachant qu’une partie du code a été écrite avec l’aide de l’IA ? Moi, non, car je sais qu’il y a toujours des humains derrière.

Alors, est-il encore exact de l’appeler du « code de mauvaise qualité » et de boycotter l’usage du terme « vibe-coding » (personnellement, je ne vois pas de problème avec cette dernière expression) ? Peut-être pas. Est-ce trop sévère ? Oui. Bien que je pense que tu n’aimerais pas cela, parfois nous devons nous adapter. Cela signifie-t-il que je vais maintenant créer des TC générés par IA et les partager ? Pour moi, non. Mais cela signifie-t-il que je vais le considérer comme une alternative, qui ne doit ni être bannie ni méprisée ? Oui. Et j’essaie de ne pas le faire. J’espère donc que tu pourras en faire de même.

5 « J'aime »

Je partage simplement un article soigné sur ce sujet :

Trail of Bits soutient que les agents d’IA sont les plus utiles lors des audits pour la création d’outils sur mesure, et pas seulement pour trouver des bugs. Lors d’un audit du zkVM Miden, ils ont utilisé Claude et Codex pour créer un serveur LSP, un décompilateur, un analyseur statique et un modèle Lean, découvrant ainsi un bug de contrefaçon de signature de haute gravité et 95 preuves Lean qui ont détecté deux problèmes subtils.

Parce que les agents rendent les projets secondaires ambitieux abordables, l’économie des audits s’est déplacée vers des revues pilotées par les outils, capables de sécuriser les systèmes complexes bien plus rigoureusement qu’auparavant.

j’utilise l’IA pour m’assister dans le développement de mes plugins et composants. Utilisez-les à vos risques et périls, mais je ne les étiqueterai pas avec de mention ou de balise particulière, tout comme le fait le cœur de Discourse. Je contrôle les agents, je révise le code (parfois avec un autre agent ou un autre LLM pour un second regard) et je les teste. Vous êtes libre de ne pas les utiliser, mais j’ai plus souvent vu du code médiocre écrit entièrement par un humain que par une IA.

7 « J'aime »

En effet, je pense que l’approche traditionnelle pour évaluer la qualité d’un produit consiste à vérifier la réputation de l’entité qui l’a créé. La réputation personnelle fonctionne bien lorsqu’une personne est active dans le code open source. En général, si quelqu’un a auparavant réalisé un bon travail et a été réactif, il continuera à le faire.

2 « J'aime »

Il vous faut tout de même faire le travail de terrain. Même lorsque vous utilisez des LLM pour créer des outils déterministes, vous devez vérifier que ces outils effectuent bien les actions correctes, et pas simplement quelque chose qui est statistiquement souvent juste. Utiliser des LLM pour créer des outils déterministes est préférable à se contenter de fournir des fichiers Markdown aux LLM en espérant que le résultat sera le même (ce qui reste problématique sur le plan juridique et éthique). Cependant, si cet outil déterministe est maintenu aveuglément à l’aide de LLM, les nouvelles versions risquent de perdre leur comportement déterministe au fil du temps.

Comme l’a montré Snyk dans son rapport VulnBench, l’audit à l’aide de LLM n’est pas vraiment fiable :

1 « J'aime »

L’utilisation d’agents IA pour écrire des thèmes Discourse me semble tout à fait appropriée.

Ce serait super. Il serait peut-être aussi utile de déterminer la configuration idéale pour quelqu’un qui n’a pas de solides compétences en programmation. Je suppose que cela ressemblerait à un agent IA ayant accès à une instance de développement Discourse et à un bon fichier de compétences. Et à une sorte de revue de sécurité automatisée.

2 « J'aime »

Bien sûr, Sam et l’équipe sont l’autorité incontestée et peuvent me corriger si je me trompe, mais après beaucoup d’expérimentations de ma part et heureux de rendre la pareille, j’ai appris au cours des derniers mois que Discourse Vibe et une bonne utilisation du harnais sont ce qui est suggéré et de loin la situation idéale pour commencer.

Il est également possible de travailler avec certains tests sur Github ou même en utilisant Discourse Container, mais la capacité de développement est limitée, surtout pour ceux qui sont moins expérimentés, comme dans mon cas.

Il est possible de « vibecoder » pour Discourse en utilisant l’IA, et il suffit de vérifier ou de déléguer la vérification finale avant de présenter le travail effectué ou de l’utiliser en production.

Pour ma part, je ne suis pas techniquement qualifié pour examiner le code, mais je suis suffisamment compétent pour diriger les fonctionnalités, comment et où les adapter, et demander ce qu’il faut spécifiquement générer ou polir. Je m’imagine donc que quelqu’un viendra contribuer ouvertement à la sécurité et à la fiabilité (examen humain toujours) du code afin qu’il puisse être utilisé par toute la communauté. Non seulement sur Meta, mais Discourse en général. Ce a toujours été mon objectif, dès mon premier prompt.

Hier, j’ai lu ce sujet et j’ai été surpris par la façon dont tout a évolué : How hard would it be for non programmers to be able to use the Discourse AI - AI bot to help them create plugins and/or themes

Il y a des années, je pensais que je ne serais même pas capable de diriger une IA pour me créer le code. Et aujourd’hui, avec les réserves et la controverse légitime qui existent à ce sujet, c’est une réalité.

4 « J'aime »

Oui, les choses ont beaucoup changé au cours de la dernière année. J’aime coder avec des agents d’IA, donc je suis biaisé.

Revenons à ce qui est peut-être le véritable enjeu de ce sujet. Je pense qu’il y a de nombreuses raisons de s’inquiéter de l’impact de l’IA sur la société. Je ne crois pas que l’argument selon lequel les LLM (ou plus précisément les agents d’IA) sont mauvais pour écrire du code tienne très bien dans le temps. Mes propres inquiétudes concernent surtout ce qui se passe quand une telle quantité de travail transite par quelques grandes entreprises technologiques. Il faudrait un essai pour aborder cela en détail ici, cependant.

5 « J'aime »

Les temps changent, les modèles à poids ouverts rattrapent rapidement le retard. Ce qui était autrefois un écart de 12 mois entre les modèles de pointe et les modèles ouverts est désormais réduit à 3 à 6 mois.

Je m’attends à ce que l’IA se diffuse beaucoup plus uniformément au cours des prochaines années. L’IA locale est aujourd’hui un cas isolé, mais elle deviendra plus courante. De plus en plus d’entreprises hébergeront elles-mêmes leur intelligence artificielle, tout comme nous le faisons chez Discourse.

8 « J'aime »