
Et surtout sur son aptitude à remplacer les humains dans la filière
Une remarque clé ressort de cette étude : ChatGPT peut s’avérer très bon à résoudre des problèmes de codage qui existaient sur la plateforme LeetCode avant 2021. Passé cette période, ChatGPT fait montre de piètres performances en raison de la qualité du jeu de données d’entraînement. Grosso modo, l’étude permet d’arriver à la conclusion que l’intelligence artificielle reste un outil à utiliser avec des pincettes. Pourtant elle atterrit dans un contexte de battage médiatique autour de l’intelligence et de sa capacité à remplacer les humains dans la filière du développement de logiciels.
En effet, après ChatGPT, c’était au tour de l’IA d’ingénierie logicielle dénommée Devin de secouer la filière du développement de logiciels en raison de son aptitude annoncée à remplacer les humains dans la filière. Sa présentation faisait suite à celle de l’intelligence artificielle dénommée Magic.dev et annoncée au public comme un « ingénieur logiciel superhumain. ».
Magic.dev et Devin partagent un dénominateur commun : une proposition de valeur qui passe par une présentation musclée ; « ingénieur logiciel superhumain » ou encore « première IA d’ingénierie logicielle entièrement autonome. » Les retours à ce sujet font néanmoins état de ce que toutes ces IA, dans leur forme actuelle, sont plutôt des assistants de codage.
Une récente étude est en effet arrivée à la conclusion que l’IA générative ne remplacera pas les développeurs de sitôt. Des chercheurs de l'université de Princeton ont développé un cadre d'évaluation basé sur près de 2300 problèmes courants de génie logiciel montés à partir de rapports de bogues et de feature requests soumis sur GitHub afin de tester la performance de divers modèles de grands langages (LLM).
Les chercheurs ont fourni à différents modèles de langage le problème à résoudre et le code du dépôt. Ils ont ensuite demandé au modèle de produire un correctif réalisable. Ce dernier a ensuite fait l’objet de tests pour s'assurer qu'il était correct. Mais le LLM n'a généré une solution efficace que dans 4 % des cas.
Leur modèle spécialement entraîné, SWE-Llama, n'a pu résoudre que les problèmes d'ingénierie les plus simples présentés sur GitHub, alors que les LLM classiques tels que Claude 2 d'Anthropic et GPT-4 d'OpenAI n'ont pu résoudre que 4,8 % et 1,7 % des problèmes, de façon respective.
Et l’équipe de recherche de conclure : « le génie logiciel n’est pas simple dans la pratique. La correction d'un bogue peut nécessiter de naviguer dans un grand référentiel, comprendre l'interaction entre des fonctions dans différents fichiers ou repérer une petite erreur dans du code alambiqué. Cela va bien au-delà des tâches de complétion de code. »
C’est la raison pour laquelle Linux Torvalds a tenu à se désolidariser de tout le battage médiatique autour de l’intelligence artificielle. Il la considère comme un outil au stade actuel de son évolution. Il suggère d’ailleurs la révision de code comme domaine d’application de l’intelligence artificielle. La capacité de l’intelligence artificielle à « deviner » l’intention du développeur lui sera utile pour obtenir du code fiable en un temps réduit. Une condition demeurera toutefois nécessaire : le développeur devra à son tour examiner ce que l’intelligence artificielle lui propose.
Malgré les avancées de l'IA, la vigilance humaine reste indispensable
L’erreur de ChatGPT qui a coûté 10 000 dollars à une startup est un rappel que, malgré les avancées de l’IA, la vigilance humaine reste indispensable. Les outils d’IA sont puissants, mais ils ne remplacent pas le jugement critique et l’expertise des développeurs. En fin de compte, c’est la responsabilité des équipes humaines de s’assurer que la technologie qu’elles utilisent est sûre et fiable.
D'ailleurs, l'erreur ne saurait être imputable entièrement à ChatGPT : les développeurs auraient du prendre la peine d'analyser le code au lieu de se limiter à quelques tests avant la copie. Ils semblent le reconnaitre lorsqu'ils déclarent :
« Je voudrais commencer par dire que les pratiques en question sont très mauvaises et embarrassantes (et nous avons depuis ajouté des tests unitaires et d'intégration robustes ainsi que des alertes et des enregistrements), qu'elles auraient pu et dû être évitées, qu'il s'agissait d'erreurs humaines au-delà de tout, et qu'elles sont très évidentes avec le recul.
« Cela s'est passé à une autre époque, avec d'importantes contraintes de temps, aux tout premiers stades (premières semaines) de la création d'une entreprise. Je partage surtout cette histoire comme une anecdote amusante avec des circonstances uniques entourant la reproductibilité des bogues en prod (encore une fois à cause de notre propre stupidité) ».
Quoi qu'il en soit, tout est bien qui finit bien : « Rétrospectivement, aussi pénibles qu'aient été ces cinq jours, c'est l'un de ces moments de la vie d'une startup que nous n'oublierons jamais. Comme toutes les startups, nous avons fait une tonne d'erreurs tout au long de notre parcours, celle-ci étant peut-être la pire. J'évoquerai peut-être les autres plus tard. Nous sommes simplement heureux de pouvoir regarder ces jours-là en arrière et d'en rire. Oui, nous aurions dû faire plus de tests. Oui, nous n'aurions pas dû copier-coller du code. Oui, nous n'aurions pas dû passer directement à l'application principale. Quoi qu'il en soit, je ne regrette pas cette expérience ».
Source : Etude
Et vous ?









Voir aussi :




Vous avez lu gratuitement 9 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.