Fin juin 2021, GitHub a lancé un « aperçu technique » de ce qu’ils ont appelé Copilote GitHub, décrit comme un « programmeur de paires AI qui vous aide à écrire un meilleur code ». De manière tout à fait prévisible, les réponses à cette annonce ont varié de la joie devant l’arrivée glorieuse de nos suzerains de l’IA générateurs de code, à la consternation et aux prédictions de malheur car avant longtemps les entreprises licencieraient en masse les développeurs de logiciels.

Comme c’est généralement le cas avec des sujets aussi controversés, aucun de ces extrêmes n’est même de loin proche de la vérité. En fait, le modèle d’apprentissage automatique OpenAI Codex qui sous-tend le copilote de GitHub est dérivé du modèle de langage naturel GPT-3 d’OpenAI et présente bon nombre des mêmes trébuchements et gaffes que GTP-3. Donc, si le Codex et avec lui Copilot ne sont pas tout ce qu’il est censé être, quel est le problème et pourquoi le montrer?

Les nombreuses définitions de l’IA

Bibliothèque Baker au Collège DarthMouth. (Crédit : Gavin Huang, CC BY 3.0)

La première grande tentative d’établissement d’un véritable domaine de l’intelligence artificielle fut l’atelier de Dartmouth en 1956. Cela verrait certains des plus grands esprits dans les domaines des mathématiques, des neurosciences et de l’informatique se réunir pour essentiellement réfléchir à un moyen de créer ce qu’ils appellerait «intelligence artificielle», suivant les noms les plus courants à l’époque comme «machines pensantes» et théorie des automates.

Malgré l’attitude optimiste des années 1950 et 1960, il a rapidement été reconnu que l’intelligence artificielle était un problème beaucoup plus difficile qu’on ne le supposait initialement. Aujourd’hui, l’IA capable de penser comme un humain est appelée intelligence artificielle générale (AGI) et reste fermement le domaine de la science-fiction. Une grande partie de ce que nous appelons aujourd’hui « IA » est en fait une intelligence artificielle étroite (ANI, ou Narrow AI) et englobe des technologies qui abordent des aspects de l’IAG, mais qui sont généralement très limitées dans leur portée et leur application.

La plupart des ANI sont basés sur des réseaux de neurones artificiels (ANN) qui copient approximativement les concepts derrière les réseaux de neurones biologiques tels que ceux trouvés dans le néocortex des mammifères, bien qu’avec des différences et des simplifications majeures. Les RNA comme les NN classiques et les NN récurrents (RNN) – ce qui est utilisé pour GPT-3 et Codex – sont programmés pendant l’entraînement en utilisant la rétropropagation, qui est un processus qui n’a pas d’analogue biologique.

Essentiellement, les modèles basés sur RNN comme GPT-3 sont des modèles d’ajustement de courbe, qui utilisent une analyse de régression afin de faire correspondre une entrée donnée avec ses points de données internes, ces derniers étant codés dans les poids attribués aux connexions au sein de son réseau. Cela fait des NN leurs modèles mathématiques de base, capables de trouver efficacement des correspondances probables au sein de leur réseau de paramètres. En ce qui concerne GPT-3 et les systèmes de synthèse de langage naturel similaires, leur sortie est donc basée sur la probabilité plutôt que sur la compréhension. Par conséquent, tout comme avec n’importe quel ANN, la qualité de cette sortie dépend fortement de l’ensemble de données d’apprentissage.

Déchets à l’intérieur, Déchets à l’extérieur

L’historique Pioneer Building à San Francisco, qui abrite OpenAI et Neuralink. (Crédit : HaeB, CC BY-SA 4.0)

Tout cela signifie qu’un ANN n’est pas capable de penser ou de raisonner et n’est donc pas conscient du sens du texte qu’il génère. Dans le cas du Codex d’OpenAI, il n’a aucune connaissance du code qu’il écrit. Cela conduit à l’inévitabilité d’avoir un contrôle humain du travail de l’ANN, comme l’a également conclu un article récent d’OpenAI (Mark Chen et al., 2021). Même si le Codex a été formé sur le code au lieu du langage naturel, il a aussi peu de notions de code fonctionnel que de grammaire anglaise appropriée ou de rédaction d’essais.

Ceci est également confirmé par la FAQ sur la page Copilot de GitHub, qui note que lors de la première tentative de remplissage du code d’une fonction masquée, elle n’a réussi que 43% du temps et 57% après 10 tentatives. Mark Chen et al. testé la sortie Python générée à partir du Codex par rapport aux tests unitaires préparés. Ils ont montré que différentes versions du Codex parvenaient à générer un code correct beaucoup moins de la moitié du temps pour une grande variété d’entrées. Ces entrées allaient des questions d’entrevue aux descriptions de la docstring.

De plus, Chen et al. notez que puisque le Codex n’a aucune connaissance de ce que signifie le code, il n’y a aucune garantie que le code généré fonctionnera, sera fonctionnellement correct et ne contiendra aucun défaut de sécurité ou autre. Considérant que l’ensemble de formation pour le Codex consistait en gigaoctets de code extrait de GitHub sans validation complète pour l’exactitude, la fonction ou les problèmes de sécurité, cela signifie que quels que soient les résultats de l’analyse de régression, ils ont au plus la garantie d’être aussi corrects que le code. copié à partir d’un article StackOverflow vaguement pertinent.

Voyons le code

Il est à noter qu’en ce qui concerne l’utilisation de GitHub Copilot, le codex d’OpenAI étant basé sur GPT-3, il est également sous licence exclusive de Microsoft, ce qui explique également son association avec GitHub, et pourquoi au moins pendant la phase de prévisualisation technique actuelle, il nécessite l’utilisation de l’IDE Visual Studio Code. Après avoir installé l’extension GitHub Copilot dans VSC et vous être connecté, votre code sera envoyé au centre de données Microsoft où s’exécute Codex, pour analyse et suggestions.

Toute suggestion de code par Copilot sera proposée automatiquement sans intervention explicite de l’utilisateur. Il suffit de quelques commentaires qui décrivent la fonctionnalité du code qui devrait suivre, et éventuellement une signature de fonction. Lorsque le système estime qu’il a trouvé quelque chose à contribuer, il affiche ces options et permet à l’utilisateur de les choisir.

Malheureusement, l’aperçu technique de Copilot ne donne accès qu’à un nombre très limité de personnes. Par conséquent, après le premier Zerg Rush qui a suivi l’annonce, je n’ai pas encore pu obtenir l’accès. Heureusement, quelques-uns de ceux qui ont obtenu l’accès ont écrit leurs pensées.

Je doute que j'utiliserai un jour le copilote GitHub au quotidien, certainement pas dans des contextes professionnels comme le travail pour un client ou pendant un emploi.  --Simona WinnekesUn développeur TypeScript (Simona Winnekes) a écrit ses réflexions après avoir utilisé Copilot pour créer une application de quiz minimale dans TypeScript et Chakra. Après avoir décrit l’intention des sections du code dans les commentaires, Copilot suggérait du code, ce qui impliquait d’abord de matraquer Copilot pour qu’il utilise réellement Chakra UI comme dépendance. La vérification des suggestions de Copilot révélerait souvent un code défectueux ou incorrect, qui a été corrigé en écrivant des instructions plus explicites dans les commentaires et en choisissant l’option souhaitée parmi les suggestions de Copilot.

Les découvertes de Simona étaient que même si Copilot fonctionne avec JavaScript, Python et TypeScript et peut aider lors de l’écriture de code répétitif ou de tests unitaires, le code généré nécessitait une validation constante et Copilot refusait souvent d’utiliser les modules et dépendances souhaités. Le code généré avait également un sentiment distinct d’« assemblage », manquant de la cohérence attendue d’un développeur humain. En fin de compte, écrire ce quiz à la main a pris environ 15 minutes à Simona et deux heures tout en amusant ce copain Copilot AI. L’enthousiasme pour l’utilisation continue de Copilot était naturellement faible après cette expérience.

Je pense qu'il faudra encore un peu plus de temps avant que Copilot ne donne un véritable coup de pouce à la productivité.  Mais je suis convaincu que cela arrive.  --Colin EberhardtChez Scott Logic, Colin Eberhardt a eu une expérience très mitigée avec Copilot. Bien qu’il ait reconnu quelques moments « wow » où Copilot était vraiment quelque peu utile ou même impressionnant, mais les points négatifs l’ont finalement emporté. Ses plaintes se sont concentrées sur la latence entre la saisie de quelque chose et l’apparition d’une suggestion de Copilot. Ceci, avec le modèle « autocomplétion » utilisé par Copilot, conduit à un « flux de travail » semblable à un corps de programmation par paire qui vous arrache apparemment au hasard votre clavier pour taper quelque chose.

L’expérience de Colin était que lorsque Copilot s’en tenait à suggérer 2-3 lignes de code, la charge cognitive de la validation des suggestions de Copilot était acceptable. Cependant, lorsque de plus gros blocs de code ont été suggérés, il n’avait pas l’impression que la surcharge de la validation des suggestions de Copilot valait la peine plutôt que de taper le code lui-même. Malgré tout, il voit du potentiel dans Copilot, surtout une fois qu’il devient un véritable partenaire de programmation d’IA.

Copilot peut être plus utile pour les langages très standardisés et dotés de fonctionnalités de méta-programmation limitées, telles que Go.  --Jeremy HowardL’analyse la plus complète vient probablement de Jeremy Howard de Fast.ai. Dans un article de blog intitulé « Le copilote GitHub est-il une bénédiction ou une malédiction ? », Jeremy fait la remarque astucieuse que la plupart du temps est pris non pas par l’écriture de code, mais par sa conception, son débogage et sa maintenance. Cela mène à la partie « malédiction », car le code de Copilot (Python) s’avère plutôt verbeux. Qu’arrive-t-il à la conception et à l’architecture du code (sans parler de la facilité de maintenance) lorsque le code est en grande partie ce que Copilot et ses proches génèrent ?

Lorsque Jeremy a demandé à Copilot de générer du code pour affiner un modèle PyTorch, le code résultant a fonctionné, mais était lent et a conduit à un mauvais réglage. Cela conduit à un autre problème avec Copilot : comment sait-on que la solution présentée est la plus optimale pour un problème donné ? Lorsque vous fouillez dans StackOverflow et que vous programmez des forums et des blogs, vous risquez de tomber sur toute une gamme d’approches possibles, ainsi que sur leurs avantages et leurs inconvénients.

Étant donné que le code généré par Copilot ne passe pas par de telles considérations, quelle est finalement la vraie valeur du code généré au-delà du fait qu’il passe le test unitaire (généré automatiquement) ?

Évolution, pas révolution

Jérémie note également que Copilot n’est pas aussi révolutionnaire qu’il le prétend. Depuis un certain nombre d’années, il existe des options telles que la recherche de code sémantique de GitHub, Tabnine avec un « assistant d’IA » qui fonctionne avec une myriade de langages (y compris des langages sans script), et plus tôt cette année, Microsoft a publié IntelliCode pour Visual Studio. Le modèle commun ici? Complétion de code basée sur l’IA.

Exemple de « développement assisté par IA » de Visual Studio IntelliCode de Microsoft.

Avec autant de concurrence déjà existante pour le copilote de GitHub, il est plus important que jamais de comprendre où il s’intègre dans le processus de développement et comment il pourrait être ajusté pour s’adapter à différents styles de développement. Plus important encore, nous devons nous débarrasser de la notion pétillante et étoilée selon laquelle ce sont des « copains programmeurs de paires d’IA ». De toute évidence, ceux-ci s’apparentent davantage à des algorithmes d’auto-complétion ambitieux, avec tous leurs avantages et inconvénients.

Certains développeurs adorent activer toutes les fonctionnalités d’auto-complétion dans l’IDE, des crochets aux noms de fonction et de classe afin qu’ils puissent pratiquement appuyer sur Entrée pour générer la moitié de leur code, tandis que d’autres préfèrent ciseler minutieusement chaque caractère dans le fichier à côté des écrans remplis avec documentation et références API. De toute évidence, Copilot ne va pas gagner des types de développeurs aussi disparates.

L’argument le plus important contre Copilot et ses proches est peut-être qu’il ne s’agit que d’algorithmes stupides sans aucune considération pour le code qu’ils génèrent. Le développeur humain devant toujours valider le code généré, il semblerait que l’époque de StackOverflow et al. ne sont pas encore tout à fait numérotés et les emplois de développeur de logiciels sont toujours assez sûrs.