Les grands modèles de langage (LLM) ont fait sensation dans les milieux créatifs lorsqu'ils ont été capables de générer des images, du texte et du code. Au départ, les résultats étaient assez hilarants, avec des dessins de personnes aux mains déformées, hallucinant des faits incorrects et du code. Mais les choses s'améliorent lentement et régulièrement. Avant l'avènement de ces modèles, le principal argument contre l'automatisation de ces tâches était que les machines ne peuvent pas penser de manière créative. Aujourd'hui, cet argument s'affaiblit de jour en jour. Quelle est la suite des événements ?L'inconvénient d'essayer de réfléchir à un problème aussi vague que la prédiction de l'avenir est que les idées s'embrouillent et qu'il est difficile de penser clairement. Nous devons donc trouver des cadres et des analogies sur lesquels nous appuyer.
Cadre : Niveau de capacité du développement de logiciels
Le développement de logiciels ne se limite pas à l'écriture de codes. L'image que les gens ont des programmeurs est celle d'une personne assise dans une pièce sombre, regardant des ordinateurs et tapant furieusement du code. Bien que coder toute la journée semble très attrayant, la majeure partie du temps de développement de logiciels est consacrée à la communication avec d'autres personnes ou à d'autres tâches administratives plutôt qu'à l'écriture de code :
- Recueillir les besoins des utilisateurs professionnels
- Affiner ces exigences pour qu'elles puissent être modélisées sous forme de code
- Discuter avec d'autres membres de l'équipe, comme les concepteurs et les gestionnaires de produits, pour visualiser la solution et élaborer un plan d'attaque.
- Travailler avec d'autres développeurs pour élaborer une conception technique et l'affiner.
- Mettre en place l'infrastructure, la configuration, le modèle de base, etc.
- Écrire du code
- Débogage, tentative de compréhension du code des autres, rédaction de la documentation, etc.
- Déploiement en production
- Lutte contre les problèmes de production
- ... et bien d'autres tâches encore
Ainsi, dire des choses comme "l'IA remplacera les développeurs" exige que l'"IA" soit compétente dans toutes les tâches susmentionnées et pas seulement dans l'écriture du code.
Mais en regardant la liste ci-dessus, il semble que certaines de ces tâches puissent également être automatisées à l'avenir, mais pas encore. Comment structurer cette pensée ?
Le monde des voitures autonomes a mis au point une méthode de classification du niveau d'automatisation. Il s'agit de niveaux distincts allant de l'absence d'automatisation à l'automatisation totale en passant par l'automatisation partielle. Je trouve cela très utile pour de nombreuses raisons :
- Elle décrit clairement ce dont la technologie actuelle est capable
- Elle nous empêche de penser en noir et blanc - il ne s'agit pas d'opposer conducteur humain et conducteur IA où l'IA remplace entièrement les conducteurs humains, il est possible d'avoir des zones grises où les conducteurs humains sont assistés par l'IA pour des choses telles que le freinage d'urgence, le positionnement sur la voie, etc.
À quoi ressemble cette classification pour le développement de logiciels pilotés par l'IA ?
- Le niveau le plus bas correspondrait à ce que nous avions auparavant : aucune IA n'était impliquée dans le travail. Bien sûr, nous avions d'autres types d'automatisation comme les compilateurs, les processus de construction, etc., mais il ne s'agit pas d'IA, il s'agit d'automatisation déterministe écrite par des humains.
- Le niveau suivant est ce que nous avons maintenant - les développeurs utilisent ChatGPT ou GitHub Copilot pour les assister. Ils l'utilisent pour des choses telles que l'écriture de tests, le code de base, la refonte, la compréhension du code/des erreurs, etc. C'est comme parler avec un collègue développeur par chat à qui vous pouvez poser des questions et obtenir de l'aide, mais il n'a pas accès à votre machine et ne peut donc pas créer de fichiers, exécuter des commandes de construction ou déployer en production.
- Le niveau le plus élevé reviendrait à déléguer une partie de votre projet ou le projet entier à un développeur. Ces "codeurs basés sur l'IA" prendraient en compte les exigences, écriraient le code, corrigeraient les erreurs et déploieraient le produit final en production. Je pensais qu'il faudrait encore attendre de nombreux mois avant que cela ne se produise, mais la démonstration de Devin m'a prouvé le contraire : même si l'IA ne peut effectuer que des tâches de développement simples pour l'instant, il y a des chances pour que cela s'améliore à l'avenir.
Outre les capacités du modèle d'IA, il convient de s'interroger sur le degré de précision des solutions. Au départ, ces modèles étaient sujets à des hallucinations ou bien il fallait les solliciter de manière spécifique pour obtenir ce que l'on voulait. Cela ajoute de la friction à l'adoption et la plupart des gens abandonnent les assistants d'IA à ce stade. Mais la situation s'améliore et les nouveaux modèles n'ont plus besoin de ce niveau de prompt engineering. En outre, les modèles devraient pouvoir "apprendre" en naviguant sur le web au lieu de s'appuyer sur leurs données d'apprentissage. Cela est important à mesure que de nouvelles versions de bibliothèques et de langages de programmation sont introduites.
Cadre : Développement de logiciels externalisés
Maintenant que nous avons établi les capacités, comment celles-ci influenceraient-elles la structure de l'équipe ou de l'organisation ? Les entreprises développent des logiciels de différentes manières :
- Entièrement en interne
- Principalement en interne avec quelques fournisseurs
- Principalement par des fournisseurs et peu en interne
- Entièrement par des vendeurs
D'une certaine manière, nous pouvons considérer les codeurs basés sur l'IA comme des vendeurs/consultants en logiciels externalisés. Certaines entreprises les utilisent beaucoup, d'autres moins. Quelle que soit leur composition, je pense qu'il est toujours important qu'une équipe interne supervise leur travail. Il s'agit de s'assurer que les résultats du fournisseur sont alignés sur les objectifs à long terme de votre organisation. Bien sûr, vous pouvez résoudre ce problème au moyen de contrats, mais ils ne s'appliquent généralement qu'à un fournisseur spécifique ou à un projet, et vous ne pouvez pas imposer des objectifs à long terme en utilisant cette méthode. Il est toujours préférable d'avoir au moins une petite équipe interne qui peut guider les fournisseurs. De même, même si les codeurs basés sur l'IA peuvent être loués comme des instances EC2, il est préférable d'avoir une équipe interne de développeurs de logiciels pour superviser leur travail.
Cadre : Le développement de logiciels est une modélisation de la complexité
Si nous parlons de résoudre des problèmes d'entreprises, prenons le temps de parler du sujet qu'on évite d'aborder, à savoir Excel. C'est un secret bien connu que le monde tourne sur Excel et que plus d'un milliard de personnes l'utilisent. Il offre une très faible barrière à l'entrée pour les utilisateurs professionnels qui souhaitent organiser des données, effectuer des analyses de données ou automatiser certains processus. Cependant, nous ne pouvons pas utiliser Excel pour des flux de travail complexes car il ne dispose pas de fonctionnalités telles que le contrôle d'accès granulaire, la capacité d'intégration avec des systèmes non pris en charge, la testabilité, la réutilisation, ou tout simplement le verrouillage du fournisseur, etc. Il en va de même pour les solutions "Low Code" telles que Power Automate, etc.
Pour en revenir à la question initiale, les utilisateurs professionnels seraient-ils en mesure d'utiliser des codeurs basés sur l'IA pour créer ces flux de travail complexes sans l'aide de développeurs de logiciels ?
Si l'on y réfléchit bien, Excel et les outils Low Code existent depuis plusieurs décennies, alors pourquoi la profession de développeur logiciel existe-t-elle encore ? Cela revient à considérer que le développement de logiciels se résume à l'écriture de code. Pour les problèmes complexes, nous avons besoin de personnes capables de gérer efficacement cette complexité et de traduire les problèmes de l'entreprise du monde réel en modèles numériques.
En d'autres termes, si vous êtes capable de construire une cabane en bois à partir de tutoriels YouTube sans l'aide d'un ingénieur civil, cela ne signifie pas que vous pouvez/devez faire la même chose pour un immeuble de 10 étages. Si vous apprenez à le faire correctement, vous deviendrez petit à petit un ingénieur civil ! Il s'agit simplement de savoir si vous êtes prêt à consacrer le temps nécessaire à cet apprentissage ou à engager un ingénieur expérimenté pour le faire à votre place.
Ainsi, que ces personnes utilisent Excel ou le dernier codeur basé sur l'IA, qu'elles modélisent une logique complexe, elles restent à mon avis des développeurs de logiciels ! Ils utilisent simplement des outils différents pour exprimer les besoins de l'entreprise - formules de feuilles de calcul, code ou invites.
Cadre : La taille du gâteau
La plupart des inquiétudes qui entourent ce sujet reposent sur l'hypothèse que la taille du marché du développement de logiciels reste inchangée - les codeurs basés sur l'IA prendront peu à peu des "parts de marché" aux humains.
D'après la section précédente, nous savons que la taille du marché de la "résolution des problèmes d'entreprise" est bien plus importante que celle du seul développement de logiciels. Il n'y a donc aucune raison de penser que le développement de logiciels disparaîtra bientôt.
Cadre : Définition formelle de la logique d'entreprise
La logique d'entreprise doit toujours être définie dans un format non ambigu. C'est pourquoi les langages de programmation, même s'ils utilisent des mots anglais tels que "if", "switch", etc., sont très précis quant à la signification de ces mots et ne fonctionneront pas si vous utilisez les mauvais mots. Si vous y réfléchissez, il en va de même pour les formules Excel ou les flux Low Code.
À l'avenir, même si les codeurs basés sur l'IA pouvaient générer un produit logiciel à partir d'instructions données en anglais conversationnel, je pense qu'il y aurait toujours une définition formelle sous-jacente de la logique d'entreprise générée dans le backend. Elle pourrait être très différente des langages et des cadres que nous utilisons aujourd'hui, mais une définition formelle de la logique d'entreprise ressemble beaucoup à du "code".
Jusqu'à ce que les codeurs basés sur l'IA puissent commencer à générer ces logiques d'entreprise à partir d'un anglais conversationnel de manière déterministe, il faudra toujours des personnes capables de comprendre le code généré dans le backend et d'y apporter des modifications si nécessaire. Ces personnes seraient des développeurs logiciels.
Conclusion
En résumé, je pense qu'il y aura toujours un marché pour les développeurs de logiciels dans un avenir prévisible, même si la nature du travail changera et que les outils que nous utiliserons pourraient être très différents de ceux dont nous disposons aujourd'hui.
Source : "Thoughts on the Future of Software Development" (par Sheshbabu Chinnakonda, Vice-président, Technologie numérique chez Temasek)
Et vous ?
Qu'en pensez-vous ? Trouvez-vous le point de vue de M. Chinnakonda crédible ou pertinent ? Quel est l'avenir du développement de logiciels selon vous ?Voir aussi :
« Apprendre à programmer sera inutile à l'avenir », d'après le PDG de Nvidia selon lequel l'intelligence artificielle fera de tous des programmeurs au travers du langage naturel Le code auto-réparateur est-il l'avenir du développement logiciel ? Ou une simple anarque qui essaie de prendre de l'ampleur à l'ère des IA génératives ?