GitHub Copilot : premières impressions

<p>- Ce que j’ai ressenti après l’avoir utilisé pendant quelques semaines <br /> → "D’ici 3 à 5 ans, nous écrirons tous davantage de commentaires, utiliserons des noms plus descriptifs pour tout, écrirons beaucoup moins de code et ferons d’innombrables revues de code"<br /> <br /> - Avantages <br /> → Excellent pour écrire du code boilerplate répétitif et ennuyeux <br /> → Capable de générer du code pour découper un dataset, puis l’entraîner et l’évaluer avec un contexte minimal<br /> → "Plus besoin d’écrire de quick macros"<br /> <br /> - Inconvénients <br /> → Pour les fonctionnalités avancées, l’utilité de Copliot reste nuancée<br /> → Il faut faire attention lorsqu’il génère de gros volumes de code qui peuvent faire — ou non — la bonne chose <br /> → Il lui arrive de recommander d’anciennes versions de bibliothèques, d’utiliser du code syntaxiquement incorrect, ou de remplir des paramètres d’algorithmes de ML qui n’existent pas <br /> → "Il faut toujours rester vigilant"<br /> <br /> [ Recherche ] <br /> J’ai tiré des enseignements importants de l’article sur Codex de GPT <br /> <br /> - Possibilités <br /> → "Codex peut être utile de différentes manières. Par exemple, pour onboarder des utilisateurs sur une nouvelle codebase, réduire les changements de contexte chez les développeurs expérimentés, permettre à des non-développeurs d’écrire des spécifications afin que Codex produise une ébauche d’implémentation, ou encore aider à l’apprentissage et à l’exploration"<br /> → Autrement dit, s’il apprend la codebase de l’entreprise et recommande les patterns ou modules utilisés à l’échelle de l’organisation, il pourrait aider à standardiser les patterns et les pratiques (même si cela n’arrivera pas tout de suite)<br /> → L’idée que des non-développeurs puissent aussi écrire des spécifications est également très enthousiasmante. En particulier les testeurs. Ils ne peuvent pas forcément écrire du code pour tester une API ou une UI, mais ils peuvent décrire ce qu’ils veulent faire ; or, la plupart du code dont ils ont besoin est suffisamment simple pour que Copilot puisse en écrire une grande partie, ce qui pourrait fortement améliorer la productivité. C’est déjà possible dans une certaine mesure avec la version preview actuelle de Copilot <br /> <br /> - Limites <br /> → Comme Codex peut proposer des solutions qui n’exécutent pas réellement la tâche visée, la "revue de code" est importante <br /> → À cause de l’"automation bias" (biais d’automatisation), plus Copilot s’améliorera, moins on sera enclin à chercher des bugs dans le code généré, alors même que ces bugs risquent d’être subtils et difficiles à identifier <br /> <br /> - Il peut recommander du code erroné </p>

[steadyslow]

<p>J’ai moi aussi trouvé qu’il faisait des suggestions bien meilleures que prévu. Il semble aussi que la capacité à rédiger en (anglais) va devenir encore plus importante. En revanche, cela paraît encore assez loin de pouvoir aider des non-développeurs ou des développeurs juniors à écrire facilement du code de logique métier, alors que cela semble déjà très utile pour permettre à des développeurs expérimentés de réduire le temps passé à écrire du code fastidieux.<br /> <br /> J’ai ressenti des inconvénients similaires à ceux mentionnés ici. En particulier sur le point qu’il arrive de « recommander du code syntaxiquement incorrect ». Pour l’instant, comme les suggestions ne sont pas encore complètement abouties, on se dit plutôt « ah, c’est pour ça qu’il a suggéré ça », et on s’en inspire un peu pour écrire le code ; mais j’ai l’impression qu’à mesure que la qualité des suggestions s’améliorera, comme cela a été écrit plus haut, il y aura aussi davantage de bugs causés par le fait de les utiliser telles quelles.</p>