Rule Taxonomy and Evolution in AI IDEs: A Mining and Survey Study
Cet article présente une étude à méthodes mixtes extrayant 7 310 règles à partir de 83 projets open source et interrogeant 99 praticiens afin d'établir une taxonomie pour les règles des IDE d'IA, révélant un écart entre les priorités des développeurs et les configurations réelles tout en démontrant que l'évolution des règles améliore significativement la conformité des artefacts logiciels.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous ayez engagé un assistant personnel super intelligent, incroyablement rapide, mais légèrement chaotique pour vous aider à construire une maison. Cet assistant est une IA, et il est très doué pour poser des briques et peindre des murs. Mais parfois, il s'embrouille. Il peut décider de construire une porte là où devrait se trouver une fenêtre, ou utiliser un type de bois que vous lui avez spécifiquement interdit d'utiliser.
Pour corriger cela, vous donnez à l'assistant un Livre de Règles. Ce n'est pas juste une note ponctuelle ; c'est un document vivant qui reste avec le projet pour toujours. Chaque fois que l'assistant commence à travailler, il lit ce Livre de Règles pour se souvenir exactement de l'aspect que votre maison doit avoir.
Ce document est une analyse approfondie de la manière dont les développeurs du monde réel utilisent ces « Livres de Règles » (appelés Règles dans les IDE d'IA) et comment ils les font évoluer au fil du temps. Les chercheurs ont examiné 83 projets réels et ont interrogé 99 développeurs pour voir ce qui se passe réellement.
Voici ce qu'ils ont découvert, présenté simplement :
1. La taxonomie du « Livre de Règles » (Que contient le livre ?)
Les chercheurs ont classé des milliers de règles dans un immense classeur composé de 5 tiroirs principaux et 25 sous-dossiers :
- Architecture et Conception : La vue d'ensemble (ex : « Utilisez ce style de plan spécifique »).
- Implémentation du Code : Le détail technique (ex : « Écrivez le code de cette façon », « N'utilisez pas de classes »).
- Flux de Travail et Gestion : Comment l'équipe travaille (ex : « Exécutez toujours les tests avant d'enregistrer »).
- Assurance Qualité : Les contrôles de sécurité (ex : « Testez tout », « Pas de failles de sécurité »).
- Collaboration avec l'IA : Comment l'IA doit se comporter (ex : « Soyez concis », « Ne devinez pas »).
La Grande Surprise :
Il y avait un énorme décalage entre ce que les développeurs disaient être important et ce qu'ils écrivaient réellement.
- Ce qu'ils valorisent : Les développeurs ont déclaré lors de l'enquête : « La chose la plus importante est l'Architecture (la vue d'ensemble) et le Contexte (comment l'IA comprend le projet) ».
- Ce qu'ils ont réellement écrit : Les Livres de Règles dans les projets réels étaient principalement remplis de détails de bas niveau comme « Utilisez cette police », « Placez les fichiers dans ce dossier » et « Exécutez ce test en premier ».
- L'analogie : C'est comme engager un architecte pour concevoir un gratte-ciel, mais passer 90 % de votre temps à lui écrire une note sur la marque de café qu'il doit boire et comment organiser l'agrafeuse, tout en mentionnant à peine l'acier de structure.
2. Comment les règles évoluent (Comment le livre change)
Les règles ne sont pas statiques ; elles sont mises à jour constamment. Les chercheurs ont observé 1 540 changements.
- L'action principale : La plupart du temps, les développeurs ajoutent de nouvelles règles. Ils ne réécrivent généralement pas les anciennes ; ils ajoutent simplement de nouvelles instructions.
- L'écart de motivation (Le "Pourquoi") :
- Ce que les données disent : En examinant les changements de code réels, les développeurs ajoutaient principalement des règles pour étendre le projet (ajouter de nouvelles fonctionnalités) ou enrichir le contexte (donner plus d'informations de fond à l'IA).
- Ce que les développeurs disent : Lorsqu'ils ont été interrogés, les développeurs ont affirmé qu'ils modifiaient principalement les règles pour corriger les erreurs commises par l'IA.
- L'analogie : C'est comme un parent qui dit : « J'ajoute principalement de nouvelles corvées à la liste pour aider les enfants à acquérir de nouvelles compétences », mais les enfants disent : « Nous n'ajoutons des corvées que lorsque nous avons mal fait la vaisselle ». La réalité est une croissance constructive, mais le ressenti est celui d'une gestion de crise.
- L'habitude de la « Correction » : Lorsque les développeurs tentent de corriger une erreur de l'IA, ils modifient rarement l'ancienne règle. Au lieu de cela, ils ajoutent une nouvelle règle qui dit : « Ne faites PAS X ». C'est comme mettre un panneau « Défense d'entrer » à côté d'une porte plutôt que de repeindre la porte.
3. Est-ce que cela fonctionne vraiment ? (Le contrôle de conformité)
Les chercheurs voulaient savoir : si vous mettez à jour le Livre de Règles, l'IA suit-elle mieux les nouvelles instructions ?
- Le résultat : Oui, de manière significative.
- Les chiffres : Avant une mise à jour de règle, l'IA suivait les instructions environ 49 % du temps. Immédiatement après la mise à jour, ce chiffre est passé à 72 %. Cela représente une amélioration de 23 %.
- Le bémol : Cela fonctionne mieux pour des choses concrètes et faciles à vérifier (comme « Les noms de fichiers doivent se terminer par .ts »). Cela fonctionne beaucoup moins bien pour des idées vagues et de haut niveau (comme « Suivez de bons principes d'architecture »).
- L'analogie : Si vous dites à l'assistant : « Portez toujours un chapeau rouge », il le fera parfaitement une fois que vous lui aurez rappelé. Mais si vous dites : « Soyez un bon leader », il pourrait encore s'embrouiller. Le Livre de Règles est excellent pour les commandes spécifiques, mais moins efficace pour la philosophie abstraite.
Résumé des conclusions de l'étude
- Les développeurs se soucient de la vue d'ensemble, mais écrivent sur les petits détails. Ils valorisent l'architecture, mais passent leur temps à régler les détails de formatage et de flux de travail.
- La stratégie « Ajouter plutôt que Modifier ». Les développeurs préfèrent accumuler de nouvelles règles pour corriger les problèmes plutôt que de nettoyer les anciennes, ce qui rend les Livres de Règles longs et désordonnés avec le temps.
- Les mises à jour fonctionnent, mais seulement pour des choses spécifiques. Modifier les règles améliore considérablement le respect des instructions par l'IA, mais seulement si ces instructions sont claires et concrètes.
- Le problème des « Contraintes Négatives ». Les développeurs corrigent souvent les erreurs de l'IA en ajoutant des règles de type « Ne faites pas ceci ». C'est une solution rapide, mais cela peut encombrer et rendre le Livre de Règles confus à long terme.
En bref, les IDE d'IA sont puissants, mais les « Livres de Règles » que nous utilisons pour les contrôler sont actuellement un peu désordonnés. Nous les utilisons pour résoudre des problèmes immédiats et de petite taille plutôt que pour guider la conception globale et complexe, et nous les construisons pièce par pièce plutôt que de les maintenir propres et organisés.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.