Réflexions sur l’avenir du développement logiciel

xguru · 2024-03-25T10:31:01+09:00

Les grands modèles de langage (LLM) ont provoqué une onde de choc dans les domaines créatifs en rendant possible la génération d’images, de texte et de code Au début, ils produisaient souvent des résultats amusants, comme des dessins avec des mains humaines mal formées ou des affirmations factuellement erronées, mais ils s’améliorent progressivement Avant l’apparition de ces modèles, l’un des principaux arguments contre l’automatisation était qu’une machine ne pouvait pas penser de manière créative, mais cet argument s’affaiblit désormais de plus en plus Où aller maintenant ? Framework: niveaux de capacité en développement logiciel Le développement logiciel ne se résume pas à écrire du code L’image du programmeur est celle de quelqu’un qui tape frénétiquement du code dans une pièce sombre face à son ordinateur, mais en réalité il consacre plus de temps à d’autres tâches qu’à l’écriture de code Recueillir les exigences auprès des utilisateurs métier Affiner ces exigences pour pouvoir les modéliser en code Visualiser et planifier des solutions avec des membres de l’équipe comme les designers et les product managers Concevoir et affiner l’architecture technique avec d’autres développeurs Mettre en place l’infrastructure, la configuration, le boilerplate, etc. Écrire réellement le code Déboguer, comprendre le code des autres, rédiger de la documentation, etc. Déployer en production Gérer les incidents en production Et bien d’autres tâches Dire que « l’IA remplacera les développeurs » signifie que l’IA doit être compétente dans l’ensemble des tâches ci-dessus Mais quand on regarde cette liste, certaines de ces tâches pourront peut-être être automatisées à l’avenir, tandis que d’autres ne semblent pas encore pouvoir l’être Classification des niveaux d’automatisation des voitures autonomes Le domaine des voitures autonomes a mis au point une manière de classifier les niveaux d’automatisation Cette classification explique clairement ce que la technologie actuelle peut faire et évite une vision binaire Si l’on applique cette idée au développement logiciel fondé sur l’IA Le niveau le plus bas correspond à ce que nous avions auparavant, c’est-à-dire une étape où l’IA n’intervient pas dans le travail. Bien sûr, il existait déjà d’autres formes d’automatisation comme les compilateurs ou les processus de build, mais il s’agit d’automatisation déterministe écrite par des humains, et non d’IA Le niveau suivant est celui que nous avons aujourd’hui Des développeurs assistés par ChatGPT ou GitHub Copilot Les développeurs les utilisent pour écrire des tests, produire du code boilerplate, refactorer et comprendre du code ou des erreurs Ils peuvent discuter avec eux comme avec un collègue développeur, poser des questions et obtenir de l’aide, mais comme ces outils n’ont pas accès à l’ordinateur, ils ne peuvent ni créer des fichiers, ni exécuter des commandes de build, ni déployer en production Le niveau le plus élevé consiste à confier une partie ou la totalité d’un projet à un « codeur IA » Le codeur IA reçoit les exigences, écrit le code, corrige les erreurs, puis déploie le produit final en production Je pensais auparavant qu’il faudrait encore quelques mois avant d’en arriver là, mais même si cela ne permet aujourd’hui d’effectuer que des tâches de développement simples, la démo de Devin a montré qu’il existe un potentiel d’amélioration pour la suite Devin, le premier ingénieur logiciel IA Au-delà des capacités du modèle d’IA, il faut aussi se demander dans quelle mesure la solution est correcte Ces modèles sont sujets aux hallucinations ou ont tendance à devoir être sollicités d’une certaine façon pour obtenir ce que l’on veut Cela crée des frictions à l’adoption, et c’est à ce stade que la plupart des gens abandonnent leur assistant IA Mais cela aussi s’améliore, et les modèles les plus récents ne nécessitent plus ce niveau de prompt engineering Le modèle doit également être capable d’« apprendre » en explorant le web, plutôt que de dépendre uniquement de ses données d’entraînement C’est important à mesure que de nouvelles versions de bibliothèques et de langages de programmation apparaissent Framework: le développement logiciel externalisé Maintenant que nous avons défini les capacités, quel impact cela aura-t-il sur les équipes ou la structure des organisations ? Les entreprises développent des logiciels de différentes manières : Entièrement en interne Majoritairement en interne avec quelques prestataires Un peu en interne avec de nombreux prestataires Entièrement via des prestataires On peut considérer les codeurs IA comme des prestataires ou des consultants externalisés en développement logiciel Il est important qu’une équipe interne à l’entreprise supervise le travail du prestataire On peut tenter de résoudre cela par contrat, mais les contrats ne s’appliquent généralement qu’à un fournisseur ou à un projet donné, et ils ne permettent pas d’imposer des objectifs de long terme de cette manière Il vaut mieux disposer au moins d’une petite équipe interne capable d’orienter le prestataire De la même manière, même si l’on pouvait louer des codeurs IA comme des instances EC2, il serait avantageux d’avoir une équipe interne composée de développeurs logiciels pour superviser le travail Framework: le développement logiciel comme modélisation de la complexité Quand on parle de résolution de problèmes métier, on peut prendre Excel comme exemple. Excel a une barrière d’entrée très faible, ce qui permet d’y organiser des données, de faire de l’analyse de données ou d’automatiser certains processus Mais il n’est pas adapté à des workflows métier complexes, car il lui manque des fonctionnalités comme le contrôle d’accès fin, l’intégration avec des systèmes non pris en charge, la testabilité, la réutilisabilité ou encore l’indépendance vis-à-vis d’un fournisseur Il en va de même pour les solutions « low-code » comme Power Automate « Un utilisateur métier peut-il créer ces workflows complexes avec un codeur IA sans l’aide d’un développeur logiciel ? » Quand on y pense, Excel et les outils low-code existent depuis des décennies ; alors pourquoi le métier de développeur logiciel existe-t-il toujours ? C’est parce qu’on considère trop souvent le développement logiciel comme le simple fait d’écrire du code Les problèmes complexes exigent quelqu’un capable de gérer efficacement cette complexité et de transformer des problèmes métier en modèles numériques ancrés dans un domaine réel Autrement dit, ce n’est pas parce qu’on peut construire un abri en bois à partir de tutoriels YouTube sans l’aide d’un ingénieur civil qu’on peut — ou qu’on devrait — construire de la même façon un immeuble de 10 étages En apprenant progressivement à bien faire ce travail, on peut peu à peu devenir ingénieur civil La question est simplement de savoir si l’on veut investir du temps pour bien l’apprendre, ou embaucher un ingénieur expérimenté Ainsi, qu’on utilise Excel ou le codeur IA le plus récent, si l’on modélise une logique complexe, on reste selon moi un développeur logiciel Seuls changent les outils permettant d’exprimer les exigences métier, qu’il s’agisse de formules de tableur, de code ou de prompts Framework: la taille du gâteau La plupart des inquiétudes autour de ce sujet reposent sur l’hypothèse que la taille du marché du développement logiciel restera inchangée, autrement dit que les codeurs IA grignoteront progressivement des « parts de marché » aux humains Comme le marché de la « résolution de problèmes métier » est bien plus vaste que celui du développement logiciel, le développement logiciel ne disparaîtra pas de sitôt Framework: définition formelle de la logique métier La logique métier doit toujours être définie dans une forme claire et formelle C’est pour cela que les langages de programmation, même lorsqu’ils utilisent des mots anglais comme if ou switch, définissent le sens de ces mots de manière très stricte, et qu’utiliser un mot incorrect empêche le programme de fonctionner. Si on y réfléchit, il en va de même pour les formules Excel ou les flux low-code À l’avenir, même si un codeur IA peut générer un produit logiciel à partir d’instructions formulées en anglais conversationnel, je pense qu’une définition formelle fondamentale de la logique métier générée en back-end existera toujours Cela pourrait être très différent des langages ou frameworks que nous utilisons aujourd’hui, mais une définition formelle de la logique métier ressemble beaucoup à du « code » Tant qu’un codeur IA ne sera pas capable de générer cette logique métier de manière déterministe à partir d’un anglais conversationnel, il faudra encore quelqu’un pour comprendre le code généré en back-end et le modifier si nécessaire. Cette personne, c’est le développeur logiciel Conclusion La nature du travail va changer, et les outils que nous utilisons seront très différents de ceux d’aujourd’hui, mais je pense qu’il existera encore un marché pour les développeurs logiciels dans un avenir proche

(sheshbabu.com)

39 points par xguru 2024-03-25 | 7 commentaires | Partager sur WhatsApp

Les grands modèles de langage (LLM) ont provoqué une onde de choc dans les domaines créatifs en rendant possible la génération d’images, de texte et de code
Au début, ils produisaient souvent des résultats amusants, comme des dessins avec des mains humaines mal formées ou des affirmations factuellement erronées, mais ils s’améliorent progressivement
Avant l’apparition de ces modèles, l’un des principaux arguments contre l’automatisation était qu’une machine ne pouvait pas penser de manière créative, mais cet argument s’affaiblit désormais de plus en plus
Où aller maintenant ?

Framework: niveaux de capacité en développement logiciel

Le développement logiciel ne se résume pas à écrire du code
L’image du programmeur est celle de quelqu’un qui tape frénétiquement du code dans une pièce sombre face à son ordinateur, mais en réalité il consacre plus de temps à d’autres tâches qu’à l’écriture de code
- Recueillir les exigences auprès des utilisateurs métier
- Affiner ces exigences pour pouvoir les modéliser en code
- Visualiser et planifier des solutions avec des membres de l’équipe comme les designers et les product managers
- Concevoir et affiner l’architecture technique avec d’autres développeurs
- Mettre en place l’infrastructure, la configuration, le boilerplate, etc.
- Écrire réellement le code
- Déboguer, comprendre le code des autres, rédiger de la documentation, etc.
- Déployer en production
- Gérer les incidents en production
- Et bien d’autres tâches
Dire que « l’IA remplacera les développeurs » signifie que l’IA doit être compétente dans l’ensemble des tâches ci-dessus
Mais quand on regarde cette liste, certaines de ces tâches pourront peut-être être automatisées à l’avenir, tandis que d’autres ne semblent pas encore pouvoir l’être

Classification des niveaux d’automatisation des voitures autonomes

Le domaine des voitures autonomes a mis au point une manière de classifier les niveaux d’automatisation
Cette classification explique clairement ce que la technologie actuelle peut faire et évite une vision binaire
Si l’on applique cette idée au développement logiciel fondé sur l’IA
- Le niveau le plus bas correspond à ce que nous avions auparavant, c’est-à-dire une étape où l’IA n’intervient pas dans le travail. Bien sûr, il existait déjà d’autres formes d’automatisation comme les compilateurs ou les processus de build, mais il s’agit d’automatisation déterministe écrite par des humains, et non d’IA
- Le niveau suivant est celui que nous avons aujourd’hui
  - Des développeurs assistés par ChatGPT ou GitHub Copilot
  - Les développeurs les utilisent pour écrire des tests, produire du code boilerplate, refactorer et comprendre du code ou des erreurs
  - Ils peuvent discuter avec eux comme avec un collègue développeur, poser des questions et obtenir de l’aide, mais comme ces outils n’ont pas accès à l’ordinateur, ils ne peuvent ni créer des fichiers, ni exécuter des commandes de build, ni déployer en production
- Le niveau le plus élevé consiste à confier une partie ou la totalité d’un projet à un « codeur IA »
  - Le codeur IA reçoit les exigences, écrit le code, corrige les erreurs, puis déploie le produit final en production
  - Je pensais auparavant qu’il faudrait encore quelques mois avant d’en arriver là, mais même si cela ne permet aujourd’hui d’effectuer que des tâches de développement simples, la démo de Devin a montré qu’il existe un potentiel d’amélioration pour la suite Devin, le premier ingénieur logiciel IA
Au-delà des capacités du modèle d’IA, il faut aussi se demander dans quelle mesure la solution est correcte
- Ces modèles sont sujets aux hallucinations ou ont tendance à devoir être sollicités d’une certaine façon pour obtenir ce que l’on veut
- Cela crée des frictions à l’adoption, et c’est à ce stade que la plupart des gens abandonnent leur assistant IA
- Mais cela aussi s’améliore, et les modèles les plus récents ne nécessitent plus ce niveau de prompt engineering
Le modèle doit également être capable d’« apprendre » en explorant le web, plutôt que de dépendre uniquement de ses données d’entraînement
- C’est important à mesure que de nouvelles versions de bibliothèques et de langages de programmation apparaissent

Framework: le développement logiciel externalisé

Maintenant que nous avons défini les capacités, quel impact cela aura-t-il sur les équipes ou la structure des organisations ? Les entreprises développent des logiciels de différentes manières :
- Entièrement en interne
- Majoritairement en interne avec quelques prestataires
- Un peu en interne avec de nombreux prestataires
- Entièrement via des prestataires
On peut considérer les codeurs IA comme des prestataires ou des consultants externalisés en développement logiciel
Il est important qu’une équipe interne à l’entreprise supervise le travail du prestataire
- On peut tenter de résoudre cela par contrat, mais les contrats ne s’appliquent généralement qu’à un fournisseur ou à un projet donné, et ils ne permettent pas d’imposer des objectifs de long terme de cette manière
- Il vaut mieux disposer au moins d’une petite équipe interne capable d’orienter le prestataire
- De la même manière, même si l’on pouvait louer des codeurs IA comme des instances EC2, il serait avantageux d’avoir une équipe interne composée de développeurs logiciels pour superviser le travail

Framework: le développement logiciel comme modélisation de la complexité

Quand on parle de résolution de problèmes métier, on peut prendre Excel comme exemple.
Excel a une barrière d’entrée très faible, ce qui permet d’y organiser des données, de faire de l’analyse de données ou d’automatiser certains processus
Mais il n’est pas adapté à des workflows métier complexes, car il lui manque des fonctionnalités comme le contrôle d’accès fin, l’intégration avec des systèmes non pris en charge, la testabilité, la réutilisabilité ou encore l’indépendance vis-à-vis d’un fournisseur
Il en va de même pour les solutions « low-code » comme Power Automate
« Un utilisateur métier peut-il créer ces workflows complexes avec un codeur IA sans l’aide d’un développeur logiciel ? »
Quand on y pense, Excel et les outils low-code existent depuis des décennies ; alors pourquoi le métier de développeur logiciel existe-t-il toujours ?
C’est parce qu’on considère trop souvent le développement logiciel comme le simple fait d’écrire du code
Les problèmes complexes exigent quelqu’un capable de gérer efficacement cette complexité et de transformer des problèmes métier en modèles numériques ancrés dans un domaine réel
Autrement dit, ce n’est pas parce qu’on peut construire un abri en bois à partir de tutoriels YouTube sans l’aide d’un ingénieur civil qu’on peut — ou qu’on devrait — construire de la même façon un immeuble de 10 étages
- En apprenant progressivement à bien faire ce travail, on peut peu à peu devenir ingénieur civil
- La question est simplement de savoir si l’on veut investir du temps pour bien l’apprendre, ou embaucher un ingénieur expérimenté
Ainsi, qu’on utilise Excel ou le codeur IA le plus récent, si l’on modélise une logique complexe, on reste selon moi un développeur logiciel
Seuls changent les outils permettant d’exprimer les exigences métier, qu’il s’agisse de formules de tableur, de code ou de prompts

Framework: la taille du gâteau

La plupart des inquiétudes autour de ce sujet reposent sur l’hypothèse que la taille du marché du développement logiciel restera inchangée, autrement dit que les codeurs IA grignoteront progressivement des « parts de marché » aux humains
Comme le marché de la « résolution de problèmes métier » est bien plus vaste que celui du développement logiciel, le développement logiciel ne disparaîtra pas de sitôt

Framework: définition formelle de la logique métier

La logique métier doit toujours être définie dans une forme claire et formelle
C’est pour cela que les langages de programmation, même lorsqu’ils utilisent des mots anglais comme if ou switch, définissent le sens de ces mots de manière très stricte, et qu’utiliser un mot incorrect empêche le programme de fonctionner. Si on y réfléchit, il en va de même pour les formules Excel ou les flux low-code
À l’avenir, même si un codeur IA peut générer un produit logiciel à partir d’instructions formulées en anglais conversationnel, je pense qu’une définition formelle fondamentale de la logique métier générée en back-end existera toujours
Cela pourrait être très différent des langages ou frameworks que nous utilisons aujourd’hui, mais une définition formelle de la logique métier ressemble beaucoup à du « code »
Tant qu’un codeur IA ne sera pas capable de générer cette logique métier de manière déterministe à partir d’un anglais conversationnel, il faudra encore quelqu’un pour comprendre le code généré en back-end et le modifier si nécessaire. Cette personne, c’est le développeur logiciel

Conclusion

La nature du travail va changer, et les outils que nous utilisons seront très différents de ceux d’aujourd’hui, mais je pense qu’il existera encore un marché pour les développeurs logiciels dans un avenir proche

7 commentaires

xguru 2024-03-31

Devin, le premier ingénieur logiciel IA
OpenDevin - implémentation open source de Devin, l’ingénieur logiciel IA

dhlee0305 2024-03-25

Avant même qu’OpenAI ne gagne en notoriété, on considérait que l’art faisait partie des domaines où l’adoption de l’IA serait la plus tardive, voire impossible ; mais en voyant l’IA y étendre elle aussi son champ d’action, je me suis soudain dit que ce que nous pensons aujourd’hui possible uniquement pour les « humains » n’est peut-être pas si « à l’abri » que cela.

edunga1 2024-03-25

Comme dans le corps de l’article et dans ce billet https://fr.news.hada.io/topic?id=13557,
la part du marché des développeurs va clairement diminuer, et cela va sans doute s’accélérer, n’est-ce pas ?

ahwjdekf 2024-03-25

À mesure que l’importance des prompts IA se renforce de jour en jour, de plus en plus d’utilisateurs prendront conscience qu’une définition claire des spécifications et une organisation rigoureuse des exigences deviennent indispensables, et cela pourrait finalement jouer en faveur des développeurs dans leur travail à l’avenir.

colus001 2024-03-25

Le code est fait pour les humains, et si les machines écrivent du code, cela signifie que les humains restent malgré tout nécessaires ; je ne pense donc pas que ce soit la direction du développement à très long terme. Je pense que cela évoluera plutôt vers une forme où, comme avec backend-GPT (https://github.com/RootbeerComputer/backend-GPT) que j’avais expérimenté au début, on envoie la requête souhaitée dans une sorte de boîte noire, qui accède à la base de données pour traiter les données, tandis que des humains interviennent partiellement dans l’expérience en amont et en aval.

kaistj 2024-03-25

On parle beaucoup de chat GPT et de Copilot, et il semble que l’ingénierie de prompt fasse souvent partie des sujets évoqués. Je pense qu’un élément important est aussi de savoir comment transmettre efficacement à un codeur IA et communiquer avec lui les processus que nous utilisons principalement pour programmer, comme tenir des réunions, échanger rapidement à l’oral, puis organiser et vérifier ce qui a été dit ^^.

vbmania 2024-03-25

> « Dire que "l’IA remplacera les développeurs" signifie que l’IA doit être capable de bien accomplir toutes les tâches ci-dessus. »

-> Il se peut que ces procédures ne soient nécessaires que parce qu’elles sont effectuées par des humains et, au final, je pense que le résultat produit — le code — peut présenter certains motifs particuliers une fois toutes ces étapes franchies. Un peu comme au go, où l’on pensait que des concepts comme les ouvertures ou les joseki étaient indispensables, avant de découvrir qu’il ne s’agissait en fait que de méthodes inévitables pour traiter l’information dans les limites de la cognition humaine.