# Amazon dit avoir fait passer des dizaines de milliers de ses propres applications Java de production de Java 8 ou 11 à Java 17 avec un agent, et estime l'équivalent manuel à plus de 4 500 années de travail de développement

Page: https://flyvolo.ai/fr/changes/ev-20240801-backend-developer-1
Date: 2024-08-01 · Étape: Déploiement réel
Ce relevé peut-il faire évoluer un jugement sur une tâche ? oui
Métier: https://flyvolo.ai/fr/careers/backend-developer

## Périmètre

L'estimation interne d'Amazon sur l'ingénierie d'Amazon, publiée par l'entreprise qui vend l'outil — la partie qui fait le travail, celle qui le mesure et celle qui le vend sont la même, ce qui est dit ici parce que cela ne peut pas être vérifié de l'extérieur. L'entreprise publie aussi sa méthode : le temps économisé a été estimé à partir du nombre de dépendances Java migrées, en supposant un jour ou plus de temps de développeur par dépendance à la main. Notez ce qu'est la migration : une montée de version de langage a un compilateur et une suite de tests existante pour oracle, donc la réussite est vérifiable par machine à chaque étape — la forme la plus favorable possible pour ce genre d'automatisation, et non un résultat général sur le travail côté serveur. Et notez ce qui est affirmé et ce qui ne l'est pas : 4 500 années sont du travail non fait, par plus d'un millier de développeurs, sans aucune déclaration que l'un d'eux soit parti ou qu'un poste ait été supprimé.

## Source

- AWS DevOps & Developer Productivity Blog (Amazon's own) — https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/ (source primaire)

## Ce que cela veut dire

Une montée de version sur un grand parc est la chose la plus nette qu'on ait montré un agent faire à grande échelle dans une vraie entreprise, et il vaut la peine d'être précis sur le pourquoi : le travail est énorme, répétitif, et il a un arbitre automatique. Le compilateur rejette ce qui est faux et la suite de tests attrape l'essentiel du reste, donc une machine peut essayer, échouer et réessayer sans personne pour regarder. Là où une tâche côté serveur a cette propriété, attendez-vous à ce qu'elle bouge. La migration est aussi la tâche que les ingénieurs chevronnés veulent le moins et que l'on confie le plus aux débutants.

## Ce qu’il ne montre pas encore

Amazon a mesuré son propre travail avec son propre outil et publié son propre contrefactuel ; personne d'extérieur n'a vérifié l'hypothèse d'un jour par dépendance sur laquelle tout le chiffre repose. Rien là-dedans n'établit un changement d'effectifs — l'affirmation porte sur des heures non passées par des développeurs qui faisaient autre chose à la place. Et la propriété qui a fait fonctionner cela ne se transpose pas : écrire un nouveau point d'entrée, décider d'une frontière de cloisonnement ou choisir quoi dégrader à trois heures du matin n'ont aucun compilateur pour dire non.

## Comment le vérifier vous-même

Regardez les tickets de montée de version ouverts de votre propre service et triez-les selon qu'une machine pourrait distinguer réussite et échec sans vous. Ceux où elle pourrait sont ceux pour lesquels il faut cesser de se porter volontaire ; ceux où elle ne pourrait pas sont le sujet de votre prochain entretien.


Plus : https://flyvolo.ai/llms.txt