Repricing of Software Engineering Labor

J'ai commencé ma carrière à la fin des années 2010, et j'ai eu une vue au premier rang sur la croissance de l'industrie qui m'a tout donné : le software engineering. En repensant à la dernière décennie, j'ai des sentiments mitigés sur certains des choix que j'ai faits. Et je vois les mêmes schémas se rejouer aujourd'hui. Donc pour les ingénieurs qui ne savent pas où tout cela mène et comment naviguer, voici comment j'y pense.

Les SWE généralistes étaient un produit de l'argent facile

À la fin des années 2010, j'ai vu une énorme quantité de financement de startups, à l'échelle mondiale. Flipkart, Snapdeal, Jugnoo et des centaines d'autres scalaient à fond, et un schéma de recrutement que j'observais était que tout le monde voulait des software engineers généralistes. Des gens capables de se mettre rapidement à niveau sur toute la stack — backend, frontend, infra, déploiement — et de simplement shipper.

Construire du logiciel coûtait cher. L'automatisation était encore faible. Kubernetes venait tout juste de devenir mainstream. Shipper signifiait encore une quantité surprenante de travail manuel : se connecter en SSH à des serveurs, copier des artefacts d'un endroit à l'autre, lancer des builds mvn à la main, débugger des déploiements directement en production, rafistoler de l'infrastructure qu'aujourd'hui on ne toucherait jamais.

Les entreprises se battaient pour les ingénieurs qui maximisaient le débit de features. La largeur était une prime, parce que chaque ingénieur supplémentaire augmentait le rythme auquel le logiciel était construit. Cela aidait parce que l'argent était aussi gratuit, que les VC récompensaient la croissance plutôt que l'efficacité, et qu'embaucher des ingénieurs en masse était la façon la plus simple de le dépenser.

Sortez le CV d'un ingénieur ayant débuté à cette époque, et vous y verrez généralement la même forme : une longue liste de technos et de frameworks, large et adaptable, mais rarement profonde sur un seul sujet. Il n'y avait aucune incitation à creuser.

Les LLM ont changé la dynamique

Les LLM n'ont pas tué le software engineering. Ils ont compressé le coût de l'implémentation. Le travail qui a été touché en premier est celui qui était déjà standardisé : applications CRUD ; intégration d'API et glue code ; travail backend lourd en frameworks ; scaffolding frontend ; patterns d'architecture standards.

Ce qui prenait une équipe est maintenant fait par une équipe de deux personnes et de l'IA. C'est pourquoi les rôles centrés sur l'implémentation deviennent du travail à faible levier.

Si votre valeur principale est d'assembler des systèmes à partir de frameworks connus et de patterns bien compris, vous êtes désormais en concurrence avec des développeurs assistés par IA, des PM techniques, des fondateurs et de petites équipes qui atteignent le même résultat avec une fraction des effectifs. Une partie de ce qui ressemble à une correction due à l'IA n'est que la fin de l'ère de l'argent facile. Les deux se produisent en même temps, et il est facile de tout imputer à l'IA.

Le repricing de la couche intermédiaire

Je ne pense pas que le software engineering disparaisse. Je pense que le marché le réévalue. Pendant des années, il a récompensé le débit d'implémentation. Les ingénieurs capables d'aller vite et de construire deviennent obsolètes du jour au lendemain — pas parce que le métier meurt, mais parce que ce qu'il valorisait change.