Comment les développeurs peuvent garder leur emploi (1)
Les entreprises pensent avoir besoin de moins de développeurs parce que l'IA fait le travail ingrat. Je trouve cela à courte vue, et nous devrions y regarder de plus près.
Architecture logicielle
Le pari que font les entreprises en ce moment
Les entreprises en ont conclu que les agents de programmation font le travail ingrat et qu'il leur faut donc moins de développeurs. Les coupes frappent surtout les personnes en début de carrière :
Une étude de Stanford constate que les jeunes occupant des emplois exposés à l'IA sont particulièrement touchés, alors qu'aucun effet de ce type n'apparaît chez les personnes expérimentées :
We find no evidence of widespread, economy-wide job displacement. However, employment of young workers (ages 22–25) in AI-exposed occupations now stands 19% below where it would be had it kept pace with that of their less-exposed peers; experienced workers show no comparable gap.
Une étude de Harvard portant sur 65 millions de salariés va dans le même sens : dans les six trimestres suivant l'adoption de l'IA par une entreprise, ses embauches de juniors (et pas seulement de développeurs) ont baissé de 9 à 10 %, tandis que celles de seniors sont restées stables.
(Certains articles très connus en ligne font même état d'une baisse de 67 %, mais ce chiffre semble impossible à étayer, je ne cite donc pas ces articles ici.)
À mon avis, le comportement des entreprises repose sur une erreur de raisonnement : d'où viendront les seniors de demain si vous cessez d'embaucher des juniors et de leur transmettre l'expérience ?
Ce que produit le vibe coding
Des développeurs moins expérimentés livrent aujourd'hui des logiciels qui fonctionnent sans les comprendre. Le code tourne, et c'est précisément pour cela que le problème reste invisible. Une analyse de GitClear portant sur 623 millions de modifications de code montre que, par rapport à l'époque d'avant l'IA, la duplication de code a augmenté de 81 % et la réutilisation a baissé de 70 %.
D'après mon expérience, la duplication est loin d'être le seul problème. Imaginons que je dise à Claude Code que je voudrais une application web basée sur bun et que je décrive quelques user stories. Claude génère bel et bien quelque chose qui fait ce que je veux.
Mais quand je regarde le code, la logique métier est mélangée n'importe comment avec l'accès à la base de données, ce qui fera grimper l'effort de maintenance plus tard.
Vient alors le vrai coup de théâtre. Si je demande maintenant à Claude Code s'il trouve cela correct, il répond « absolument pas, nous devrions séparer la technique de la logique métier » et refactorise en conséquence.
Donc, si je n'avais pas posé la question, ce code serait tout simplement parti en production. Les personnes sans expérience en architecture produiront du mauvais code avec des agents d'IA, sans s'en apercevoir.
Deux sortes de dette, pas une
La dette technique vit dans le code. La dette de compréhension vit dans l'équipe : c'est l'écart entre la quantité de code qui existe et la part que quelqu'un comprend vraiment. La seconde est plus dangereuse, car aucun tableau de bord ne la mesure.
« Comprehension debt », la dette de compréhension, est un terme forgé par Addy Osmani (ancien Director, Google Cloud AI - Gemini, Vertex, Agents). Dans son article, Osmani décrit ce qui se passe lorsqu'un système contient de plus en plus de code, mais que la part qu'un humain saisit encore vraiment ne suit pas.
Une étude d'Anthropic a montré que les développeurs qui déléguaient à l'IA pendant qu'ils apprenaient à programmer obtenaient des résultats nettement plus faibles aux tests de compréhension. Cela voudrait dire que les juniors ont intérêt à résoudre à la main quelques problèmes difficiles, car ils apprendraient plus vite ainsi. Les développeurs qui utilisaient l'IA comme partenaire de réflexion et pour se faire expliquer les choses s'en sont mieux sortis qu'un groupe qui lui déléguait entièrement le travail. Ce qui compte, c'est donc comment vous utilisez l'IA, pas seulement si vous l'utilisez.
Le jour où cela tournera mal
Avec des applications nouvelles et assez petites en particulier, le vibe coding sans compréhension approfondie ne fait aucun mal. Vous pouvez donner à un junior la recette suivante, et il ira assez loin avec :
- Dites à l'agent de programmation ce qu'il faut
- Laissez-le générer du code jusqu'à ce que tous les tests soient de nouveau au vert
- Demandez-lui ensuite une revue approfondie de ce qu'il vient de générer
- Si la revue a trouvé des bugs ou des défauts, faites-les corriger par l'agent
- Répétez les étapes 3 et 4 jusqu'à ce que la revue ne trouve plus que des problèmes classés « minor ».
- Faites une pull request des modifications et confiez-la à quelqu'un d'autre.
Cela fonctionne jusqu'à ce qu'arrive la première exigence qui contredit l'architecture existante. À ce moment-là, quelqu'un doit tout de même comprendre l'ensemble du système pour décider quoi faire. Il se peut que cette personne ne soit plus dans les effectifs, car c'était quelqu'un d'expérimenté qui a depuis franchi l'étape suivante de sa carrière.
Que fait alors une telle entreprise ? Elle laisse simplement ceux qui sont là prendre les décisions nécessaires, et l'architecture commence à se dégrader.
L'objection que je n'ai pas pu écarter
Quand j'ai cherché des gens qui partagent cette inquiétude, j'en ai trouvé beaucoup, y compris de très connus. Par exemple Mark Russinovich, CTO, Deputy CISO et Technical Fellow de Microsoft Azure, et Scott Hanselman, VP et Member of Technical Staff chez Microsoft/GitHub.
Dans leur article pour Communications of the ACM, ils soutiennent que l'IA générative a fissuré l'économie du développement logiciel, d'une manière que le secteur ne voit pas encore tout à fait.
Mais j'ai aussi trouvé des ingénieurs sérieux qui disent que tout le problème se résoudra de lui-même, et leurs arguments sont en réalité meilleurs que je ne le pensais. Dans le prochain épisode de cette série, vous lirez pourquoi ils pourraient avoir raison. Restez à l'écoute.