Chez Amazon, certains développeurs disent que leur travail commence à ressembler à celui d’un entrepôt

• Les développeurs d’Amazon subissent, depuis l’adoption de l’IA, une pression accrue sur la cadence de travail et une simplification des tâches
• Les managers recommandent fortement l’usage d’outils d’IA au nom du gain de productivité
• Certains estiment que la réduction des tâches répétitives améliore la qualité du travail, mais des inquiétudes subsistent sur la perte d’opportunités de progression pour les développeurs juniors
• À mesure que le codage passe d’une création directe à un travail centré sur la relecture et la vérification, certains ont le sentiment de ne plus vraiment faire leur propre métier
• Des groupes internes comme Amazon Employees for Climate Justice y compris sur ce sujet partagent leurs inquiétudes sur le stress au travail et l’incertitude quant à l’avenir

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

Le code aussi entre dans l’ère de la course à la vitesse

• Un phénomène de simplification des emplois lié à la mécanisation, observé à répétition depuis la révolution industrielle, est désormais aussi à l’œuvre dans le développement logiciel
• L’IA, plutôt que de supprimer les emplois, transforme les postes existants en travail plus simple et plus rapide à exécuter
• Selon une étude de Microsoft, la productivité des développeurs utilisant l’assistant IA Copilot a augmenté de plus de 25 %
• Amazon a intégré cette logique et exige, via l’IA, un travail plus rapide et plus efficace, en le présentant dans sa lettre aux actionnaires comme un levier essentiel de réduction des coûts et de maintien de la compétitivité
• Par exemple, une équipe de développement fonctionne avec deux fois moins d’effectifs que l’an dernier tout en devant produire le même volume de code

Une tendance à l’échelle des entreprises

• Shopify a fait de l’usage de l’IA une exigence de base pour tous les employés et précise que cela est pris en compte dans l’évaluation des performances
• Google fait des outils d’IA destinés à améliorer la productivité quotidienne un thème de ses hackathons internes. Plus de 30 % du code y est déjà généré à partir de suggestions de l’IA

Les aspects positifs et les inquiétudes

• Certains managers soutiennent que l’adoption de l’IA réduit les tâches ennuyeuses et répétitives, permettant de se concentrer sur un travail plus créatif
• Amazon affirme avoir économisé, grâce à l’IA, 4 500 années de travail de développement
• Mais l’économiste de Harvard Lawrence Katz souligne que, pour les développeurs débutants, les opportunités de progression professionnelle risquent de disparaître
• Comme autrefois pour les ouvriers d’usine confrontés à la course à la cadence, les développeurs subissent eux aussi une pression pour aller plus vite et produire davantage

Les changements ressentis par les développeurs

• Comme dans les entrepôts logistiques d’Amazon, les développeurs ressentent eux aussi l’automatisation des tâches et la division du travail provoquées par l’IA
• L’usage de l’IA est présenté comme un « choix », mais il devient de fait indispensable pour atteindre les objectifs de performance
• Le développement d’une fonctionnalité qui prenait autrefois plusieurs semaines doit désormais être bouclé en quelques jours, avec pour cela moins de réunions et davantage de code produit par l’IA
• L’IA peut aller jusqu’à générer des programmes entiers, mais le temps passé à lire et vérifier le code augmente, tandis que le plaisir et l’immersion diminuent

Baisse de l’engagement et de la progression de carrière

• Les développeurs juniors risquent, avec l’automatisation des tests, de perdre l’occasion de comprendre le code en profondeur
• L’IA aide sur de nombreuses tâches, comme la rédaction de documents de conception ou les tests de code, mais l’environnement d’évaluation évolue vers une logique centrée sur les outils plutôt que sur l’humain
• Harper Reed, ancien CTO de la campagne d’Obama, estime que nous entrons dans une époque où il n’est plus nécessaire de comprendre chaque partie en profondeur, et décrit cela comme une transformation comparable à celle de l’industrie manufacturière
• À l’inverse, Simon Willison porte un regard positif sur l’IA, notamment parce qu’elle accélère la concrétisation des idées

Mécontentement et réactions collectives

• En raison de l’usage de l’IA et des transformations du travail qui en découlent, de nombreux développeurs partagent leur anxiété et leur stress au sein du groupe Amazon Employees for Climate Justice
• Les inquiétudes portent notamment sur la dégradation de la qualité du travail et l’incertitude de carrière, dans un ressenti comparable au stress de la course à la cadence autrefois éprouvé par les ouvriers de l’automobile
• Il n’existe pas encore de mouvement en faveur d’un syndicat de développeurs, mais un consensus interne et une empathie croissante sont en train d’émerger

Contexte historique et perspectives

• Comme lors de la grève de GM en 1936, les questions de cadence et d’autonomie au travail peuvent servir de catalyseur à l’action collective des salariés
• Autrefois, chacun pouvait régler sa propre manière de travailler et son rythme, alors qu’aujourd’hui l’ensemble du processus est surveillé et évalué selon des critères de vitesse

[GN⁺]

Commentaires Hacker News

• Partage du lien archive.ph/HVZRL
• J’ai l’impression que le développement fondé sur les LLM est un effet de mode survendu, un peu comme la crypto ou la VR. Après avoir récemment dû corriger des bugs dans une base de code écrite en « vibe coding », j’ai eu le sentiment que cette approche n’était qu’un amas de chaos où des problèmes métier non structurés sont transposés en code sans structure. Comme on colmate les points à améliorer avec des correctifs étroits, on finit avec un code complexe et désorganisé. Une fois atteint la limite de la context window, le LLM ne se souvient même plus de ses propres patches. L’anglais (ou le langage humain en général) reste trop ambigu pour décrire précisément le code que je veux, et expliciter dans un prompt tout le cumul d’expérience et d’essais-erreurs qu’un développeur senior a incorporé dans le code est une tâche extrêmement lourde. Contrairement à « pourquoi c’est écrit ainsi », la vraie différence est qu’il faut une liste énorme, très spécifique et sans fin de consignes du type « dans cette situation, ne fais pas ceci, fais cela »
  • Une observation qui correspond exactement à la description de la plupart des codebases que j’ai vues ces 30 dernières années (à une seule exception près)
  • Contre-argument — l’IA m’a aussi aidé à trouver des patterns dans le code à une trentaine d’endroits où il fallait extraire de la structure. Le problème du vibe coding, selon moi, c’est l’attitude. Ceux qui cherchent à éviter de coder eux-mêmes ont tendance à privilégier le confort immédiat plutôt que la structure et la qualité à long terme ; c’est en quelque sorte un amplificateur de paresse
  • En réalité, beaucoup de code de production n’est qu’un assemblage de snippets qui marchent, rafistolés patch après patch. Dans les faits, les CPU sont tellement rapides que même ce genre de code tourne, ce qui est assez triste
  • Je suis d’accord sur le fait que le langage humain n’est pas clair. Après tout, on a déjà tenté plusieurs fois de manipuler clairement le logiciel en langage naturel, et comme en droit, les zones grises d’interprétation reviennent sans cesse. Si à l’avenir les développeurs doivent débattre du sens d’un programme avant la compilation, ce sera un avenir bien sombre
  • Oui, l’IA semble aussi survendue que la crypto ou la VR. Mais même des métiers très techniques comme l’ingénierie logicielle finiront par subir les effets de l’automatisation. Ces dix dernières années, beaucoup de gens de la tech se sont imaginé qu’ils étaient à l’abri des problèmes des autres travailleurs, mais avec la culture des réductions d’effectifs, la pression sur les salaires commence réellement. Même si l’IA ne remplace pas tout immédiatement, si 5 personnes faisaient le travail et que désormais 4 le font avec l’IA, cela supprime 1 poste, et les personnes restantes n’osent plus demander d’augmentation. Les métiers de la tech doivent comprendre qu’eux aussi sont des travailleurs
• À propos de l’opinion de Harper Reed selon laquelle « il n’est pas nécessaire de comprendre profondément le code », ce genre de propos ressemble plutôt à une logique de fortune du type « tant que ça compile, on déploie ». Sur une chaîne automatisée, on mesure en permanence la qualité, mais les vraies machines n’ont pas d’hallucinations comme se tromper d’angle ou souder n’importe où ; les logiciels fondés sur les LLM, eux, répètent ce type de petites erreurs
• Je me demande si les outils fondés sur les LLM ont réellement augmenté de façon spectaculaire la productivité des développeurs, ou si les organisations ont simplement découvert qu’elles pouvaient se contenter de moins de développeurs — et de développeurs moins privilégiés qu’avant. Je vois peu d’exemples de « gains de productivité révolutionnaires » dans les grandes entreprises tech ; jusqu’ici, on semble surtout avoir de modestes améliorations qui compensent à peine les investissements
  • C’est en grande partie une question de perception. Avant, le développement était vu comme difficile, mais avec l’arrivée des outils d’IA, on a le sentiment que la barrière à l’entrée du coding a baissé. Le développement logiciel ressemble de plus en plus à un travail d’usine, avec moins de gratification intellectuelle
  • J’ai des doutes sur la maintenabilité à long terme des codebases. Le vibe coding accumule progressivement complexité, bugs subtils et problèmes d’abstraction, ce qui finit par rendre la maintenance et le développement de nouvelles fonctionnalités plus difficiles. On risque de se laisser enfermer dans un gain de productivité à court terme au prix d’une baisse de qualité à long terme
  • Les organisations cherchent depuis longtemps, via des procédures bureaucratiques, à « sortir de la technique », c’est-à-dire à remplacer les profils qualifiés par une standardisation avec une main-d’œuvre moins qualifiée. C’est une stratégie potentiellement toxique à long terme, mais tant qu’il y a de la cohérence, elles se contentent d’une « solution moyenne mais acceptable »
  • Pour que ce raisonnement tienne, il faut supposer que la direction d’Amazon accorde plus d’importance au profit de court terme qu’à la qualité de long terme, et je n’en suis pas certain
• En tant que personne proche de la retraite, les changements récents me laissent assez désemparé. Quand j’ai commencé dans les années 1990, on avait le temps de se plonger longtemps dans l’expérimentation et la créativité. Aujourd’hui, il faut enchaîner les tâches unitaires, les rapports d’avancement et les justifications permanentes. Il y aura encore des développeurs intéressants à l’avenir, mais ces occasions se raréfient. En réalité, nous suivons simplement la même trajectoire que d’autres métiers rendus plus pénibles par l’automatisation, ce qui est, au fond, un résultat équitable
  • Les stand-up quotidiens et autres rapports d’état prennent du temps et ne sont souvent qu’une réponse formelle pour gagner une journée de tranquillité vis-à-vis de personnes qui ne comprennent pas mon travail ; cela dévalorise le travail lui-même
  • Moi aussi, je suis entré dans le métier dans les années 1990 et je me reconnais dans ce contrôle minutieux via JIRA. Cela dit, je ne pense pas que le passé ait été un âge d’or absolu. Il y a sans doute aussi un biais nostalgique qui ne retient que les bons souvenirs. Mais même aujourd’hui, il existe encore des défis intéressants, du bon travail et beaucoup à apprendre
  • Plus que l’automatisation des emplois d’ingénieur, on semble aller vers le remplacement de facto des fonctions managériales par une surveillance centrée sur l’IA
• Pour accélérer radicalement le développement logiciel, il existe aussi une autre méthode : copier tel quel le code open source de quelqu’un, effacer les traces de copyright ou de licence, puis l’utiliser. Si l’on craint d’être pris, on peut passer par un sous-traitant pour « blanchir » cela, ou aujourd’hui le faire blanchir rapidement et à bas coût par une IA. Google se retenait autrefois de ce genre de pratiques, par manque d’audace. Mais les petites jeunes pousses, elles, visent un succès rapide en utilisant l’IA tout en ignorant les risques de violation du droit d’auteur
  • Dans mon secteur, le vrai problème n’est pas tant l’absence de code que la définition de « quoi construire et comment le construire ». Il y a aussi beaucoup de problèmes spécifiques que ni Stackoverflow ni GitHub ne résolvent
  • En réalité, Google faisait déjà cela depuis longtemps : récupérer le contenu des sites et l’exposer directement dans les résultats de recherche, en exploitant le contenu d’autrui sans lui renvoyer de trafic. Cette fois encore, ils sont simplement arrivés en retard
  • Ironiquement, certains disent même qu’ils préféreraient que les grandes entreprises plagient du code open source. C’est toujours mieux, du point de vue de l’utilisateur, que d’être forcé d’utiliser les méthodes froides et inefficaces qu’elles ont elles-mêmes conçues
  • Je comprends aussi les limites du fait de publier son code en open source. Les grandes entreprises ont tendance à encourager l’open source comme moyen d’obtenir du travail gratuit. Même si les contributions diminuent à court terme, je pense qu’à long terme le secteur y gagnerait en santé
  • Critique du manque de responsabilité entourant l’arrivée de ChatGPT et le leadership de Sam Altman
• La remarque de Simon Willison selon laquelle lire du code est plus difficile et moins amusant que l’écrire, ainsi que le cas d’un développeur Amazon expliquant que l’IA aide beaucoup pour la documentation et les tests, m’ont marqué. Le rôle évolue désormais davantage vers la revue du code existant et la correction de bugs que vers l’écriture de nouveau code
  • Je repense à l’époque où écrire du code était un plaisir. Aujourd’hui, corriger des bugs me semble plus amusant, et le LLM prend en charge le coding répétitif et simple, ce qui me permet de me concentrer sur les vrais défis. Grâce aux LLM, une partie du plaisir du développement survit encore
  • L’atmosphère qui se dégage de cet article est assez négative
• À chaque nouvelle technologie de productivité, les entreprises en captent rapidement les bénéfices et la standardisent. Pour suivre, il faut apprendre en permanence, et il faut parfois envisager de basculer vers un cadre où l’on peut soi-même capter les gains de sa propre progression (travail indépendant, etc.). Mais travailler seul signifie aussi affronter la concurrence de personnes très à l’aise avec l’IA, donc il n’y a pas de solution simple
  • Trois scénarios d’avenir sont envisagés. 1) Les codebases s’effondrent progressivement dans le chaos et l’instabilité, et il faudra peut-être réembaucher très cher des développeurs expérimentés. 2) L’IA produit un code globalement utilisable, avec une qualité et une fiabilité faibles mais sans catastrophe majeure. 3) L’IA devient soudainement si intelligente que la notion même de codebase disparaît, remplacée par des logiciels générés et évoluant dynamiquement à la demande. Les LLM actuels sont encore très loin de cela. Les dirigeants d’entreprise croient au scénario 3, mais aujourd’hui la réalité se situe plutôt entre 1 et 2. Avec une bonne gouvernance, on pourrait aussi tendre vers une version équilibrée du scénario 2
  • Il existe aussi des modèles où les gains de productivité sont distribués plus équitablement, par exemple via une réduction du temps de travail comme autrefois en Europe. Aujourd’hui, on a parfois l’impression que même les travailleurs passent leur temps à s’agiter sur des tâches obscures juste pour avoir l’air occupés
  • Tu exprimes en fait une perspective quasi marxiste, et c’est amusant de voir qu’elle débouche malgré tout sur l’aliénation individuelle. Avec un minimum d’action collective, on pourrait améliorer les choses, mais cela n’arrive pas
  • Il ne faut pas accepter comme une fatalité l’idée de devoir se réinventer sans cesse ; il est aussi possible de s’unir aux autres membres de la société pour exiger ensemble des comptes aux employeurs. La semaine de 5 jours, la journée de 8 heures et l’interdiction du travail des enfants sont aussi le fruit de l’action collective. Pas besoin de se contenter de bien faire son propre travail en regardant seulement les autres réussir
• Je suis toujours surpris de voir à quel point notre secteur devient infantile. Toute personne ayant de l’expérience dans les grandes entreprises et sur de grosses codebases sait que la génération de nouveau code n’est qu’une petite partie du développement
  • En pratique, tout ce qui ne relève pas de l’écriture de nouveau code — donc tous les à-côtés — est également inefficace dans les grandes entreprises. L’IA pourrait aussi changer cela et réduire les réunions incessantes ou les discussions abstraites
  • Beaucoup de ceux qui s’enthousiasment aujourd’hui sont en réalité des gens pour qui l’écriture de code est devenue difficile à cause des paradigmes récents. Ils fabriquent rapidement un POC avec Copilot ou d’autres outils LLM, l’envoient jusqu’en production, sans vraiment réfléchir en profondeur à la qualité, à l’évolutivité, etc. Ensuite, ils présentent automatiquement cela comme une preuve de hausse de productivité liée à l’IA, en répétant surtout des arguments alignés sur les intérêts des grandes entreprises. Pourtant, tous ceux qui utilisent réellement ces outils savent qu’il y a aussi beaucoup de limites dans la pratique
  • Moi aussi, je ne passe qu’environ 20 % de mon temps à coder ; le reste va à la collecte des besoins, à la conception, aux tests et à la gestion du planning. Si ce travail de code de 20 % était réduit de moitié, je pourrais probablement consacrer ce temps gagné à davantage de tests ou de documentation
• Il existe une illusion selon laquelle les LLM vont fortement accroître l’efficacité du développement. En réalité, le gain de productivité sans perte de qualité n’est possible que lorsqu’on a déjà de solides compétences. Autrement dit, c’est un amplificateur de productivité pour les experts ; si l’on donne des LLM à une armée de débutants grossie en effectifs, obtenir un logiciel de qualité reste difficile
  • On répète souvent cet argument, mais la vraie question est de savoir où l’on place le seuil de « qualité ». Dans les faits, j’ai un ami SRE qui fait une revue hebdomadaire avec une jeune équipe de développement qui utilise activement les LLM, et la qualité du code comme l’évolutivité sont tout à fait suffisantes. C’est plus lent, mais le niveau final n’est pas mauvais
  • Seuls certains contextes ont besoin de « bon » logiciel ; quand on regarde le modèle économique de sociétés comme Deloitte ou Accenture, on voit bien que la plupart des entreprises ne se soucient même pas vraiment de la qualité. Pour la majorité, un logiciel « suffisamment crédible » suffit