Discussion :

[Wendy Breiding]

5 instructions générative de Copilot Chat que les développeurs .NET devraient adopter dès aujourd'hui, par Wendy Breiding

L'intelligence artificielle est en train de devenir un élément clé de la boîte à outils du développeur .NET moderne. Avec GitHub Copilot Chat, vous pouvez gagner un temps considérable, éliminer les frictions et libérer votre créativité en posant simplement les bonnes questions. Mais que devez-vous demander exactement ? Voici cinq instructions générative (prompt) de GitHub Copilot Chat que tous les développeurs .NET devraient utiliser dès maintenant !

1. « Expliquez ce code et suggérez des optimisations. »

Lorsque vous héritez d'un projet existant ou que vous revisitez un ancien code, il peut être difficile de comprendre ce qui se passe. Ajoutez les fichiers de votre code C# dans Copilot Chat et demandez non seulement une explication, mais aussi des recommandations pour améliorer les performances, la lisibilité ou la maintenabilité. Vous gagnerez du temps et apprendrez peut-être une ou deux nouvelles astuces !

2. « Écrivez des tests unitaires pour cette méthode/classe. »

Les tests sont essentiels, mais souvent négligés lorsque les délais approchent. Placez votre curseur dans la méthode ou la classe et laissez Copilot Chat générer des tests unitaires robustes à l'aide de xUnit, MSTest ou NUnit. C'est un excellent moyen de garantir la couverture et de détecter les cas limites que vous auriez pu manquer.

3. « Convertissez ce code pour utiliser async/await. »

Les applications .NET modernes doivent tirer parti de la programmation asynchrone pour gagner en évolutivité et en réactivité. Si vous avez du code synchrone, demandez à Copilot Chat de le réécrire avec des modèles async/await. Cela vous aidera à pérenniser votre base de code et à améliorer l'expérience utilisateur.

4. « Trouvez et corrigez les problèmes de sécurité potentiels dans cet extrait de code. »

La sécurité est la responsabilité de tous, mais il peut être difficile de repérer toutes les vulnérabilités. Demandez à Copilot Chat d'examiner votre code à la recherche de failles de sécurité courantes telles que les injections SQL, les XSS ou les validations d'entrée incorrectes. Laissez l'IA être votre paire d'yeux supplémentaire avant de passer en production.

5. « Générez des données d'exemple ou des objets fictifs pour ce modèle. »

Que vous créiez un prototype d'API ou que vous écriviez des tests, il est essentiel de disposer de données réalistes. Copilot Chat peut générer instantanément des données ou des objets fictifs pour n'importe quel modèle, vous aidant ainsi à simuler des scénarios réels et à lancer votre application plus rapidement.

Conclusion

Ces instructions générative ne sont qu'un début ! Expérimentez avec Copilot Chat, adaptez ces idées et créez vos propres raccourcis. Avec les bonnes questions, vous pouvez faire de l'IA votre assistant de codage et faire passer votre développement .NET au niveau supérieur. Découvrez d'autres instructions générative intéressantes dans le dépôt Awesome GitHub Copilot Customizations.

Source : "5 Copilot Chat Prompts .NET Devs Should Steal Today"

Et vous ?

Pensez-vous que ces instructions générative sont crédibles ou pertinentes ?
Quelles instructions générative utilisez-vous avec Copilot Chat ?

Voir aussi :

Personnaliser les réponses de l'IA à partir de GitHub Copilot : En mode Agent, l'IA peut créer des parties ou même des applications entières à partir de vos instructions écrites ou parlées, par Matt Soucoup

Mon guide d'ingénierie des prompts ou instructions génératives d'IA pour les développeurs, par Namanyay

Ne dites plus « prompt » mais « instruction générative », recommande la Commission d'enrichissement de la langue française, qui propose des traductions françaises du vocabulaire entourant l'IA

[Matthieu Vergne]

À part le async/await, je ne vois pas ce qu'il y a de spécifique à .NET.

Par contre celui-là est scandaleux :

2. « Écrivez des tests unitaires pour cette méthode/classe. »

Les tests sont essentiels, mais souvent négligés lorsque les délais approchent. Placez votre curseur dans la méthode ou la classe et laissez Copilot Chat générer des tests unitaires robustes à l'aide de xUnit, MSTest ou NUnit. C'est un excellent moyen de garantir la couverture et de détecter les cas limites que vous auriez pu manquer.

On ne génère pas un test à partir du code qu'on cherche à tester. Cela revient à dire "écrit moi un test qui passe avec ce code". On écrit un test parce qu'on a un besoin à satisfaire : les tests sont à générer à partir du cahier des charges, pas du code. Générer des tests à partir du code revient à faire de la couverture de test pour le plaisir d'en faire. Ça n'a aucune valeur ajoutée et au contraire augmente l'effort quand on doit changer quelque chose, car on doit désormais retoucher le code ET le test.

Je comprends la simplicité de la chose qui le rend très alléchant, mais ce n'est pas parce que quelque chose est facile que ça le rend recommendable.

[OuftiBoy]

Matthieu,

On ne génère pas un test à partir du code qu'on cherche à tester. Cela revient à dire "écrit moi un test qui passe avec ce code". On écrit un test parce qu'on a un besoin à satisfaire : les tests sont à générer à partir du cahier des charges, pas du code. Générer des tests à partir du code revient à faire de la couverture de test pour le plaisir d'en faire. Ça n'a aucune valeur ajoutée et au contraire augmente l'effort quand on doit changer quelque chose, car on doit désormais retoucher le code ET le test. Je comprends la simplicité de la chose qui le rend très alléchant, mais ce n'est pas parce que quelque chose est facile que ça le rend recommendable.

100% d'accord, voilà un exemple d'une "fonctionnalité" ajoutée non pas parce qu'elle est nécessaire, mais simplement parce qu'il possible de le faire... C'est avec ce genre de "pratique" qu'on obtient des software "bourssouflés" de fonctionnalités inutiles.

BàT et Peace & Love.

[Aspartame]

quelle est la plus-value de l'IA, en général ds outils CLI font tout ça sans tuer de dauphins
ps : j'adhère aux remarques sur les tests unitaire

[Matthieu Vergne]

quelle est la plus-value de l'IA, en général ds outils CLI font tout ça sans tuer de dauphins
ps : j'adhère aux remarques sur les tests unitaire

L'IA, ou pour être plus précis les outils à base de LLM, brillent dans le traitement du langage naturel. Or il se trouve que les langages de programmation modernes s'en rapprochent. Pas forcément d'un point de vue "naturel", mais d'un point de vue "medium de communication". Contrairement à l'assembleur des débuts, les langages modernes reprennent des éléments du langage naturel, et de plus en plus vu que c'est justement une des pratiques poussées : utiliser les termes du métier dans le code et structurer le code pour qu'il se lise facilement.

Des outils classiques ne s'appuient généralement pas sur le langage naturel, mais sur des métriques plus ou moins claires. Par exemple tu peux utiliser Sonar pour trouver des améliorations, mais ça se base sur des règles très précises genre regexp (si un code ne passe pas la règle, c'est mort pour lui) et ne peux suggérer que certains types d'améliorations. Le LLM offre la flexibilité du langage naturel : si un coup il peut ne pas penser à telle amélioration, le coup d'après il peut le suggérer. Si des caratéristiques de ton code ressortent typiquement dans des discussions liées à telle optimisation, même s'il n'y a pas de règle claire sur les cas où il faut l'appliquer, le LLM peut te le suggérer quand même (à toi de confirmer son application).

Pour reprendre la structure proposée par l'article :

1. « Expliquez ce code et suggérez des optimisations. »

La traduction de ton code en langage naturel (partie "expliquez") permet de voir si le LLM associe les bons concepts et relations sur la base de ton code, autrement tu peux être tenté de revoir ton code pour le rendre mieux interprétable par le LLM, il sera alors probablement plus lisible pour le lecteur humain aussi. La suggestion d'optimisations peut te faire gagner du temps en te faisant penser à des aspects que tu ne penses pas habituellement (et donc ne penserais pas automatiquelemnt à chercher par toi-même). Dans les deux cas, le LLM offre un moyen simple d'avoir une revue réactive sans déranger personne.

2. « Écrivez des tests unitaires pour cette méthode/classe. »

À condition d'inclure le cahier des charges dans le contexte du LLM, qui fournit un gros morceau de langage naturel exploitable, cela peut donner une structure (voire une suite) de tests rapidement. Ne reste alors qu'a fignoler. Le piège étant de le laisser faire des tests redondants qui ne change qu'une petite chose par ci par là. En Java, sous jUnit, on peut faire des tests paramétrés. Je préfère de loin faire 2-3 tests à la mains puis les généraliser sous forme de tests paramétrés afin de ne rajouter que des cas de tests par la suite (plutôt que des tests entiers et répétitifs). Voire faire une hiérarchie de classes de tests étendables pour avoir des classes enfant qui n'ont qu'à définir les cas de tests, les tests eux-même étant définis une fois pour toute. C'est maintenable à la main sur le long terme, même sans LLM.

3. « Convertissez ce code pour utiliser async/await. »

Spécifique .NET, je ne m'étend pas, mais la transformation de code en général n'est pas quelque chose de trivial via du CLI. Tu peux en arriver à faire du grep/sed/awk qui te prend une heure à concevoir. Le LLM peut se baser sur de nombreux exemples du Web pour te suggérer une transformation. Par contre, si tu souhaites faire une transformation massive, je te conseille plutôt de demander de générer la commande CLI ou le script pour la faire de manière déterministe, comme ça tu n'auras que le script à vérifier plutôt que devoir vérifier toutes les modifs une par une (un LLM est stqtistiaue, ce ,'est pas parce qu'il te modifie 9 éléments de la même manière sur le 10e le sera aussi). Sinon demander le script de vérification si c'est plus simple, comme ça tu laisses le LLM faire les modifs mais tu passe le vérificateur derrière (et demander au LLM de repasser sur ceux-là, jusqu'à finition).

4. « Trouvez et corrigez les problèmes de sécurité potentiels dans cet extrait de code. »

Idem au point 1, le sujet change mais le problème du point de vue LLM est le même.

5. « Générez des données d'exemple ou des objets fictifs pour ce modèle. »

Similaire au point 3, il s'agit de transformer une structure vide en une structure pleine. Similaire seulement, car il y a de la création de données, mais ça c'est le b.a.-ba du LLM (c'est littéralement fait pour génèrer du texte à la demande). Le tout étant de vérifier derrière qu'il a bien respecté la structure. Encore une fois, en cas de besoin massif, privilégier la génération de script pour rendre la modif déterministe si possible.