Camilla Moraes, chef de produit chez GitHub, a lancé une discussion sur l'ajout d'une fonctionnalité sur GitHub pour bloquer automatiquement les pull requests indésirables générées par des assistants AI, soumises sans vérification manuelle et ne répondant pas aux exigences de qualité. De telles modifications créent une charge supplémentaire pour les mainteneurs, qui doivent consacrer du temps à analyser du code inutile.
Comme solutions à court terme, on envisage la possibilité de supprimer rapidement des pull requests via l'interface web (suppression sans laisser de trace dans l'historique, au lieu de les marquer comme fermées) et l'utilisation de droits personnalisés pour la soumission de pull requests, permettant aux propriétaires de dépôts d'autoriser la transmission de modifications uniquement aux contributeurs ayant déjà effectué des modifications.
Parmi les solutions à long terme, on mentionne l'élargissement du modèle d'autorité et la fourniture d'outils aux mainteneurs pour définir de manière flexible les règles concernant qui a le droit de créer et de réviser des pull requests et quelles exigences doivent être respectées par celles-ci. En outre, il est proposé d'utiliser l'AI pour déterminer si la modification soumise respecte les règles et normes de qualité de chaque projet (par exemple, celles énoncées dans le fichier CONTRIBUTING.md), ainsi que pour identifier et marquer spécialement les changements préparés avec l'aide de l'AI.
Parmi les suggestions formulées au cours de la discussion, on peut également noter la création d'un filtre interdisant la soumission de pull requests sans l'ouverture préalable de discussions issues avec une explication des raisons de la mise en œuvre des changements, ainsi que l'information des mainteneurs sur la réception de pull requests de nouveaux contributeurs uniquement après avoir réussi les tests dans le système d'intégration continue.
Selon les statistiques d'un des principaux développeurs du framework genkit, une seule des dix modifications préparées par l'AI répond aux critères pour l'ouverture d'une pull request. Un des participants du projet Azure Core Upstream a résumé les principales inquiétudes des mainteneurs :
- Violation du modèle de confiance lors de la révision — les réviseurs ne peuvent pas être sûrs que la personne ayant envoyé la modification a écrit le code transmis et en comprend l'essence.
- Les pull requests générées par les assistants AI peuvent sembler structurellement correctes, mais être logiquement incorrectes, peu sûres ou non vérifiées en termes de fonctionnement.
- La pratique de la revue ligne par ligne reste obligatoire, mais elle ne peut pas être mise à l'échelle dans des conditions de croissance des changements, générés par les assistants AI.
- Les accompagnateurs ressentent un malaise face à l'acceptation de pull requests qu'ils ne comprennent pas entièrement, alors que les assistants AI simplifient la transmission de changements majeurs sans compréhension approfondie.
- La charge cognitive des accompagnateurs augmente, car ils doivent désormais non seulement vérifier le code, mais également évaluer si son auteur en a une compréhension.
- L'émergence des outils AI n'a pas réduit, mais plutôt augmenté la charge sur les accompagnateurs.
On peut également noter une étude réalisée par plusieurs universités européennes sur l'impact du 'vibe coding' sur l'écosystème des projets ouverts. Les chercheurs ont développé un modèle d'équilibre de l'écosystème du code ouvert, qui a montré que les rétroactions, qui auparavant étaient responsables de la croissance explosive des projets ouverts, créent maintenant un effet inverse après la propagation du 'vibe coding' — le nombre de développeurs prêts à partager du code diminue, la diversité des projets ouverts se réduit et la qualité s'affaiblit. Une des solutions proposées pour ce problème est la mise en place d'un modèle de financement semblable à celui de Spotify, où les plateformes AI redistribuent les revenus des abonnements aux services pour les développeurs parmi les accompagnateurs, en fonction du degré d'utilisation des projets.
Avec le code basé sur l'ambiance, les développeurs cessent d'analyser les solutions disponibles, de lire la documentation, d'envoyer des rapports d'erreurs et d'interagir avec les équipes qui développent des bibliothèques ouvertes. Les projets ouverts perdent le retour d'information des utilisateurs. Il devient plus difficile pour les nouveaux projets de se frayer un chemin, car les assistants IA choisissent eux-mêmes les bibliothèques ouvertes nécessaires en fonction des informations disponibles au moment de l'entraînement du modèle. En raison de la diminution de l'interaction directe avec les utilisateurs, la monétisation des projets ouverts, qui s'appuient sur des services de support et l'affichage de publicités ou la collecte de dons sur les sites, souffre. La qualité souffre également d'un manque de feedback. D'un autre côté, le code basé sur l'ambiance augmente la productivité lors de la création de nouveaux produits reposant sur du code étranger et facilite l'intégration de nouvelles bibliothèques.
À titre d'exemple, le projet Tailwind CSS, dont le nombre de téléchargements depuis le dépôt NPM continue d'augmenter, mais le trafic vers la documentation a diminué de 40 % depuis le début de 2023, tandis que les revenus ont chuté de 80 %. Une baisse de l'activité de discussion sur Stack Overflow d'environ 25 % a également été notée, six mois après le lancement de ChatGPT.
Source : opennet.ru
