Les ordinateurs vont-ils remplacer les développeurs ?
AUTEURS : Adrien Burgun, Alexandre Viala
Depuis sa création, l’informatique a révolutionné de nombreux domaines, en simplifiant grandement les tâches autrefois faites à la main, comme le calcul numérique ou le travail des opérateurs téléphoniques. Avec l’avènement des technologies permettant aux machines de comprendre le langage humain mieux que jamais, est-il possible que les développeurs soient les prochains à voir leur métier menacé ? Si on se pose la question, c’est à la vue de l’émergence et du succès foudroyant des Large Language Models, dont GPT-3 est l’emblème. Représentant l’état de l’art en Machine Learning, GPT-3 peut apprendre à écrire des poèmes1, créer du jeu de rôle2, rédiger des articles de presse3, voire même des articles scientifiques, ou encore rendre des oracles en matière éthique4 ! Pourquoi ne pourrait-il pas produire du code ?
Techniquement, le programme GPT-3 se base sur un modèle essayant de prédire le prochain mot dans une phrase. À partir de ce modèle et avec assez de données d’entraînement, il peut « comprendre » ce que vous dites et y répondre de manière satisfaisante. Si GPT-3 fonctionne sur des mots d’une phrase, il peut aussi fonctionner sur les symboles d’un programme informatique : c’est ce que Codex, développé par OpenAI en partenariat avec GitHub (un hébergeur de code source, possession de Microsoft depuis 2018), tente de faire. Grâce à l’énorme quantité de code disponible sur GitHub, GPT-3 a pu être entraîné pour produire un réseau capable d’écrire de nouveaux programmes. GitHub Copilot est un outil qui propose au développeur les suggestions de Codex en même temps que le codeur programme.
Codex à l'essai
Avec ces éléments en tête, on serait tenté de penser que GPT-3 est une IA particulièrement performante. Pour vérifier ces promesses, nous avons essayé Codex d’OpenAI en le configurant pour qu’il génère le code que l’on désirait. Nous avons fait des séries de tests principalement en Python et en JavaScript. Il s’agit de deux langages particulièrement utilisés de nos jours, dotés d’une syntaxe peu restrictive : ce sont les langages qui composent la plupart des programmes scannés sur Github et que Codex semble le mieux maîtriser5.
Pour indiquer à Codex ce que l’on désire programmer, il suffit d’écrire une ligne de commentaire en langage naturel expliquant la tâche à réaliser. Par exemple, en mettant en commentaire : « Calcule-moi les forces gravitationnelles s’appliquant sur plusieures particules », Codex semble avoir compris ce que nous désirions, en programmant une série de calculs basés sur la relation : . Mais dans d’autres situations, le logiciel, a parfois plus de mal, notamment quand le but n’est pas bien défini. Nous avons par exemple essayé de faire générer le « code d’un jeu vidéo » sans plus de précision et Codex a proposé quelques fonctions génériques (créer un objet, lui donner un nom, etc.) avant de se répéter en boucle.
On remarque que de nombreux objets sont créés, comme des armes, un joueur et des ennemis, mais qu’ils ne sont que très sommaires. Cependant, Codex donne des commentaires au-dessus de chaque classe, pour expliquer le rôle de chaque fonction, ce qui permet par la suite de facilement retravailler le code. Il peut ainsi aider à commencer un projet de jeu vidéo, mais sans vraiment en créer un. On peut également noter que lors de nos premiers essais, nous n’avions pas précisé quelle syntaxe il était préférable d’utiliser pour rédiger les classes. Codex a choisi, par défaut, une déclaration de classes désuète, utilisant le mot-clé « function ». Néanmoins, en précisant que l’on voulait une méthode plus actuelle, le mot-clef « class » a été utilisé.
La révolution qui fait ce qu'on savait déjà faire ?
Les résultats sur l’écriture complète de code restent donc pour l’instant quelque peu mitigés. En baissant le niveau d’exigence et en demandant simplement des auto-complétions, les résultats sont cependant bien différents. Sur les fonctions complexes, Codex aura tendance à générer du code imprécis et rempli de bugs, mais sur des fonctions plus simples, le taux de bugs diminue drastiquement.
Cependant, cela fait déjà quelques années que les environnements de développement sont affublés d’auto-complétions. On parle alors de snippets, des petits bouts de codes encodés dans l’éditeur de texte réutilisables selon le contexte. On les utilise pour des fonctions prédéfinies dans le langage comme par exemple la méthode __init__() en python qui permet d’initialiser un objet. Le snippet va simplement reconnaître le début de la fonction et va compléter la ligne en pressant la touche « entrer ». Cette technologie ne permet cependant pas de réellement écrire du code, elle ne fait que reconnaître des bouts de codes prédéfinis. C’est à partir de 2018 que des logiciels tels que TabNine et Kite ont fait leur apparition. Il s’agit de moteurs de complétions de code basés sur GPT-2, le prédécesseur de GPT-3. Ces logiciels sont capables d’effectuer des opérations similaires à Codex ou Copilot en complétant du code entamé. Ces logiciels plus sommaires vont tenter de prédire une partie de la réponse attendue, tandis que Codex et Copilot vont proposer une réponse correcte correspondant à une interprétation de la tâche demandée.
Des limites plus ou moins drastiques
Ces quelques démonstrations sont plutôt encourageantes pour l’essor de l’intelligence artificielle dans le domaine de la programmation informatique. Mais l’IA reste encore limitée sur bien d’autres aspects. En effet, au fil des essais, nous nous sommes rendus compte que les résultats varient grandement selon la tâche qu’on lui demande à cause de l’absence de sémantique. Il est aussi nécessaire pour l’informaticien de revérifier tous les programmes conçus par la machine fonctionnent correctement. Enfin, le principe de fonctionnement de GPT-3 peut sembler dysfonctionnel du fait de l’évolution constante des langages de programmation et des bonnes pratiques.
La limitation qui nous frappe le plus est que les résultats varient d’une démonstration à l’autre. Si dans certaines démonstrations, tout semble fonctionner parfaitement, cela cache souvent une grande quantité d’essais infructueux réalisés en variant quelques paramètres. Nous avons par exemple demandé à Codex de calculer une intégrale en utilisant une méthode d’approximation particulière, mais il ne s’est résolu à respecter cette consigne qu’après 2 à 3 essais infructueux. S’il est si difficile pour GPT-3 de comprendre une consigne si simple, c’est parce qu’il n’est pas doté d’une sémantique. Il n’est par exemple pas capable de comprendre les négations, ainsi si on lui demande « un rouge-gorge est », GPT-3 répondra un oiseau6. A contrario, si on lui demande « Un rouge-gorge n’est pas », il répondra également un oiseau. GPT-3 ne fait que reconnaître des mots-clefs et ne peut donc pas comprendre des phrases complexes demandant d’utiliser une méthode particulière.
L’IA est également limitée par un aspect fondamental de l’informatique. Cette limite est énoncée par Alan Turing dans son article On Computable Numbers, With An Application to Entscheidungsproblem7, 1936 : il est impossible de vérifier qu’un programme informatique est bien formé à priori. Cela signifie qu’il est impossible de démontrer mathématiquement qu’un programme informatique quelconque fonctionne sans le faire tourner et observer son comportement. Les programmes obtenus avec Codex sont soumis à la même règle : il y aura toujours la possibilité qu’un de ses programmes soit mal formé. Il n’existe donc aucun moyen de vérifier la qualité d’un programme. Laisser la machine programmer toute seule peut donc s’avérer contre-productif : déboguer un programme est en effet souvent plus long que de l’écrire, encore plus lorsque le programme est écrit par quelqu’un d’autre. Pour gagner du temps, nous risquons de finir par en perdre. Il serait donc plus intéressant de créer des logiciels capables de déboguer des programmes ou seulement d’aider sur des tâches plus simples.
Il paraît donc déjà impossible qu’une machine puisse un jour programmer par elle-même. À cela s’ajoutent d’autres inconvénients liés à GPT-3. D’abord, le fonctionnement même de GPT-3 implique d’apprendre d’autres programmeurs dans le monde. Cela signifie qu’à chaque mise à jour d’un langage de programmation comme JavaScript, alors que les bonnes pratiques ne seront pas encore appliquées par tous les développeurs, la machine va continuer à apprendre à écrire du code désuet : il est possible de déjà voir cet effet, avec par exemple l’utilisation du mot-clé « var », qui est très rarement utilisé de nos jours. On peut également imaginer que certains codes délaissés ou oubliés par leur créateur servent encore d’exemples à Codex, et que ceux-ci vont contribuer à la qualité des réponses du réseau. Codex, par sa nature, ne pourra jamais réellement écrire du code vraiment innovant, étant donné qu’il apprend d’autres, et qu’il commettra sûrement les mêmes erreurs et mêmes biais que ceux dont il s’inspire. Il est d’ailleurs intéressant de noter que Codex est doté d’un biais qui le pousse à produire du code de meilleure qualité si l’on ajoute le nom d’un contributeur GitHub connu pour la qualité de son code dans l’entête du fichier8.
En conclusion, et pour tempérer ce jugement sévère, nous devons reconnaître que le modèle sur lequel Codex est basé, GPT-3, présente tout de même une forme d’intelligence émergente, parfois stupéfiante. GPT-3 est capable, avec un très petit nombre d’addition (ou de données), de « comprendre » comment fonctionne cette opération. C’est un fait plutôt encourageant de prime abord. Mais en remettant les choses en perspective : GPT-3 est basé sur un réseau de neurones avec 175 milliards de paramètres, dont la consommation électrique est gigantesque. Et pourtant avec autant de ressources, nous ne sommes capables que d’avoir le début d’une pensée émergente de la machine. Si nous devions concevoir une intelligence plus performante, combien de ressources faudrait-il engager9 ? Est-ce vraiment envisageable ? En l’état des techniques, si une IA était amenée à programmer un jour, il serait plus probable que ce soit en qualité d’assistance que de remplaçant pour un programmeur.
- Exemple : Duncan Anderson, « When AI writes poetry », Humanise, jan. 2021 (https://humanise.ai/blog/ai-writes-poetry/)
- Exemple : Nick Walton, « AI Dungeon Dungeon », AI Dungon, 2019 (https://play.aidungeon.io/main/home)
- Exemple : GPT-3, « A robot wrote this entire article. Are you scared yet, human? », The Guardian, sep. 2020 (https://www.theguardian.com/commentisfree/2020/sep/08/robot-wrote-this-article-gpt-3)
- Exemple : « AskDelphi », The Allen Institute for Artificial Intelligence, oct. 2021 (https://delphi.allenai.org/)
- D’après la promotion de GitHub (https://copilot.github.com/) ; on sait aussi que Codex a été entrainé sur 159GB de code Python (https://venturebeat.com/2021/07/08/openai-warns-ai-behind-githubs-copilot-may-be-susceptible-to-bias/)
- Gary Marcus and Ernest Davis, « Has AI found a new Foundation? », The Gradient, 11 sep. 2021. (https://thegradient.pub/has-ai-found-a-new-foundation/)
- A. M. Turing, « On Computable Numbers, With An Application To The Entscheidungsproblem », London Mathematical Society, 1936.
- Hammond Pearce et al. « Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions », scénario M-1 : https://arxiv.org/pdf/2108.09293.pdf
9; Neil C. Thompson, Kristjan Greenewald, Keeheon Lee, Gabriel F. Manso, « Deep Learning’s Diminishing Returns », IEEE Spectrum, 24 Sep. 2021 (https://spectrum.ieee.org/deep-learning-computational-cost)
