Les développeurs du projet LLVM ont approuvé des règles concernant l'utilisation des outils AI lors du développement. La nécessité de réglementer l'utilisation de l'AI s'explique par l'augmentation du nombre de modifications inutiles proposées pour intégration dans la base de code LLVM. Par modifications inutiles, on entend celles générées par des outils AI et soumises telles quelles, sans compréhension du sujet, vérification, en adoptant une position où « le mainteneur s'en chargera ». Cette activité crée une surcharge pour les mainteneurs et les oblige à passer du temps à examiner un code inutile.
Tout en reconnaissant que, si elle est utilisée correctement, l'AI peut être un outil utile qui accélère le développement, les développeurs de LLVM soulignent que les conditions d'utilisation de l'AI adoptées sont en partie basées sur des règles publiées l'année dernière par le projet Fedora. L'idée principale des règles adoptées est que les développeurs ne doivent pas transférer aux mainteneurs le travail de révision de code généré par des assistants AI.
En plus de la responsabilité mentionnée dans les règles de Fedora concernant le changement soumis, les règles de LLVM introduisent l'exigence d'une révision manuelle obligatoire du code généré par l'AI avant de proposer un changement au projet. De plus, la personne ayant préparé le changement doit bien comprendre le code envoyé et être prête à répondre aux questions qui y sont liées. Il est recommandé de rédiger manuellement des descriptions pour les pull requests, plutôt que de laisser l'AI préparer le texte d'accompagnement.
Lors de la soumission d'un changement, dont une partie significative a été générée par des outils AI, il est nécessaire d'ajouter des informations dans les notes de la pull request concernant l'utilisation de l'AI, en indiquant par exemple la balise « Assisted-by: nom de l'assistant AI ». L'utilisation d'outils AI automatisés, tels que l'agent AI intégré à GitHub @claude, qui effectuent des actions ou envoient des commentaires sans intervention humaine, est interdite.
Les règles adoptées s'appliquent non seulement au code dans les demandes de changements, mais également aux documents RFC proposant de nouvelles fonctionnalités, aux notifications de vulnérabilités et de bogues, ainsi qu'aux commentaires et retours sur les pull requests.
On peut également noter la décision de Daniel Stenberg, l'auteur de l'outil de transmission de données par réseau curl, d'arrêter le programme de récompense pour la divulgation de vulnérabilités dans Curl. Les paiements de récompenses cesseront fin janvier en raison d'un grand nombre de demandes indésirables générées par des assistants AI et envoyées sans vérification de l'existence réelle de la vulnérabilité.
Il a été rapporté que pendant les deux premières semaines de janvier, 20 demandes de récompense ont été soumises, affirmant la présence de vulnérabilités. L'analyse de ces demandes a montré qu'aucune d'entre elles ne révélait de véritables vulnérabilités. Les auteurs de rapports de vulnérabilités sont encouragés à ne pas signaler de problèmes s'ils ne comprennent pas la nature du problème et ne peuvent pas reproduire l'erreur. La vérification de telles demandes demande beaucoup de temps à l'équipe chargée de la sécurité. Il est prévu que l'arrêt des paiements de récompenses réduira la motivation des gens à envoyer des rapports indésirables et mal vérifiés sur les vulnérabilités, qu'ils soient générés par AI ou non.
Note : Le projet Node.js a également annoncé une restriction sur l'acceptation des demandes de récompenses pour la découverte de vulnérabilités, n'acceptant désormais que les demandes de participants ayant une bonne réputation, ayant déjà de l'expérience dans l'envoi de rapports corrects sur les problèmes (signal > 1). La raison de ce changement est l'augmentation significative du nombre de demandes de mauvaise qualité. L'analyse des demandes indésirables prend du temps et des ressources qui pourraient être mieux utilisées pour réellement améliorer la sécurité de la plateforme. Du 15 décembre au 15 janvier, le projet a reçu plus de 30 telles demandes.
Source : opennet.ru
