Chez Amazon, des employés gonflent la consommation de jetons d’IA en créant des tâches inutiles sous la pression d’utiliser l’IA
(fastcompany.com)- Alors qu’Amazon suit la consommation de jetons d’IA de ses employés, certains gonflent artificiellement leur usage en utilisant l’outil d’IA interne MeshClaw pour créer des agents d’IA inutiles
- Selon des employés, le suivi de la consommation de jetons d’IA a installé une culture où le volume d’usage passe avant la qualité, créant ainsi une structure de contre-incitations
- Amazon nie l’existence d’indicateurs d’usage de l’IA à l’échelle de l’entreprise ou de classements internes, mais des employés affirment qu’il existe un objectif hebdomadaire de 80 % d’usage de l’IA chez les développeurs ainsi qu’un leaderboard de consommation de jetons
- MeshClaw est un outil inspiré d’OpenClaw, qui s’exécute de manière autonome sur le matériel local de l’utilisateur et dispose d’une forte autonomie
- Ce cas met en lumière un problème structurel : quand l’adoption de l’IA est imposée via des indicateurs quantitatifs, cela peut gaspiller des ressources sans améliorer réellement la productivité
Pression sur l’usage de l’IA et recours à MeshClaw
- Les employés d’Amazon subissent une pression pour intégrer davantage d’IA dans leurs flux de travail, mais sans consignes claires sur les usages attendus, ce qui ouvre la voie à un gaspillage de ressources d’IA sur des tâches inutiles
- D’après un article du Financial Times, certains employés d’Amazon utilisent l’outil d’IA interne MeshClaw non pas pour améliorer leur productivité, mais pour créer des agents d’IA inutiles afin d’augmenter leur volume d’activité lié à l’IA
- Un employé explique qu’« il y a énormément de pression pour utiliser ces outils », ajoutant que certains se servent de MeshClaw pour maximiser leur consommation de jetons
Désaccords autour des indicateurs d’usage
- Des employés estiment que le suivi par Amazon de la consommation de jetons d’IA pousse certains collègues à privilégier la quantité d’usage de la technologie plutôt que sa qualité
- Plusieurs employés anonymes d’Amazon considèrent que la hausse des attentes en matière d’usage de l’IA détériore l’environnement de travail
- Amazon aurait indiqué à ses employés que les statistiques d’usage de l’IA n’entrent pas dans l’évaluation des performances, mais tous ne semblent pas le croire
- Un autre employé estime que ce suivi crée des contre-incitations (perverse incentives) qui faussent les comportements et poussent certains à agir de manière très compétitive
- Les employés interrogés affirment que l’entreprise vise chaque semaine un objectif où 80 % des développeurs utilisent l’IA, et que la consommation de jetons des employés est suivie dans un leaderboard interne
- Un porte-parole d’Amazon a déclaré qu’il n’existe aucun indicateur à l’échelle de l’entreprise concernant l’usage de l’IA, ni de leaderboard interne comparant les employés entre eux
- À la place, il a expliqué que les employés peuvent consulter leur propre usage de l’IA via un tableau de bord individuel
OpenClaw et les risques de l’exécution locale
- MeshClaw, utilisé par certains employés d’Amazon pour gonfler leur usage de l’IA, est un outil inspiré d’un autre outil d’IA, OpenClaw
- Contrairement à d’autres modèles d’IA, OpenClaw et MeshClaw s’exécutent localement sur le propre matériel de l’utilisateur, ce qui leur confère une grande indépendance
- Plus tôt cette année, la directrice de l’alignement chez Meta Superintelligence Labs a fait parler d’elle après qu’OpenClaw a failli supprimer l’intégralité de sa boîte de réception, mettant en évidence les risques liés à un accès trop large accordé à l’IA
4 commentaires
Avant, on évaluait déjà les développeurs au nombre de lignes de code qu’ils écrivaient, hein lol
Du coup, il y avait plein de code poubelle avec des dizaines, voire des centaines de milliers de lignes écrites pour rien d’un coup, alors qu’au final ça n’apportait qu’une ou deux fonctionnalités.
Ça me fait penser, de façon similaire, au fait d’évaluer les performances uniquement sur le temps de travail mdr.
Une situation où, même sans résultat concret, on reçoit une bonne évaluation simplement parce qu’on a fait beaucoup d’heures sup lol
Les effets secondaires d’une efficacité excessive (2022)
La sélection aléatoire est nécessaire pour mettre en place une méritocratie stable
Réactions sur Hacker News
Ce n’est pas propre à Amazon : on a l’impression que toute la grande tech et même certaines plus petites boîtes deviennent folles en même temps
C’est un peu comme si le PDG disait un jour : « Il faut encourager les dépenses de déplacement, donc réservez autant de voyages que possible et dépensez un maximum d’argent. Prenez la première classe pour aller dans les bureaux satellites, une limousine au lieu d’un Uber, mangez dans des restos haut de gamme. Si vous ne dépensez pas assez en frais de déplacement, vous serez mal noté à l’évaluation. »
On vit vraiment une époque complètement anormale
Si j’étais vice-président chez Amazon, j’étudierais même une offre de rachat, et je travaille aussi sur une version enterprise avec des fonctionnalités supplémentaires
Show HN : https://news.ycombinator.com/item?id=48151287
Il pensait se faire réprimander, mais il a au contraire été félicité et on lui a même demandé de faire une courte présentation pour expliquer sa méthode aux autres
Désormais, 20 % de nos dépenses d’infrastructure sont des tokens, et le nombre hebdomadaire de pull requests par développeur est passé de 4,2 à 5,1
Une grande partie correspond juste à des agents qui changent une ou deux lignes de fichier de config, donc tout ça ressemble à de la pensée magique
Sur d’autres vols, il aurait pu voyager en première classe pour moins cher, mais la politique de l’entreprise interdisait la première classe
En fait, on a toujours vécu à des époques anormales
Comme cela ne s’est pas produit, elles semblent supposer que c’est parce que les employés n’utilisent pas assez souvent l’IA magique
Les entreprises qui construisent leurs propres produits IA peuvent aussi vouloir que leurs employés utilisent l’IA autant que possible afin de récupérer des données d’entraînement pour remplacer ensuite la plupart, voire la totalité, de ces employés
Punir les salariés qui refusent d’entraîner leur propre remplaçant IA peut leur sembler rationnel si elles considèrent que le coût présent sera largement compensé par les économies futures
J’ai assisté il y a environ six mois à une présentation d’un employé AWS sur des outils IA adaptés à notre cas d’usage
En plein milieu, pendant le partage d’écran, il a soudain dit : « Regardez combien de tokens j’ai utilisés ce mois-ci. Je fais tourner Opus à fond », et le chiffre était insultant de grandeur
Je me suis alors dit : « Drôle de flex. Vu le prix de ce truc, le simple fait d’en utiliser autant n’est-il pas déjà un signal d’alerte ? »
Il a montré plusieurs cas d’usage de Claude Code pour gérer et ajuster de l’infrastructure AWS, mais à mes yeux de vieux sysadmin barbu plus âgé qu’Internet, cela ressemblait surtout à : « on a utilisé l’IA pour faire quelque chose qui tenait en une seule commande »
Donc cette histoire me paraît crédible. Ils étaient déjà encouragés à en faire un usage débridé il y a six mois
Mais si vous appuyez sur
tab, cette ligne est comptée comme une ligne modifiée par l’IAUne bonne partie du reste, on aurait déjà pu la faire à vitesse comparable en apprenant juste le multi-cursor, les déplacements vim et les macros
En pratique, je ne les ai jamais vraiment appris parce que je n’ai jamais été assez lent à écrire du code à l’écran pour que cela devienne le goulot d’étranglement
Ce n’est probablement pas binaire et cela dépend sans doute de plusieurs facteurs, mais c’est étrange de voir circuler simultanément des récits aussi contradictoires
Du coup, on comprend mieux d’où peuvent venir ces injonctions, et pourquoi elles ne sont ni prudentes ni équilibrées
C’est une grande faiblesse dans le développement de systèmes, et cela peut devenir une énorme surface d’attaque pour un adversaire
Une part importante de la valeur de l’IA est précisément là
Il n’est plus nécessaire de connaître cette commande, il suffit de comprendre le contrat fonctionnel pour accomplir le travail nécessaire
C’est un changement énorme
On voit passer beaucoup d’histoires du genre « il fallait utiliser des tokens, alors on les a gaspillés inutilement », ce qui est difficile à croire en pleine urgence climatique
À ce rythme, on pourrait bien pousser jusqu’à +3 °C de réchauffement
Ça me fait penser à l’histoire selon laquelle l’URSS a failli conduire les baleines à la quasi-extinction juste pour atteindre des quotas de viande de baleine dont personne ne voulait manger
On a de facto une planification centrale, avec toutes les pathologies du système ; la seule différence avec l’Union soviétique, c’est que notre GOSPLAN est dirigé par quelques personnes devenues riches par hasard ou en arrosant les bonnes personnes
Non pas pour un « vrai » gain de productivité, mais juste pour consommer des tokens
Si vous ne brûlez pas de tokens, vous n’atteindrez pas vos KPI, et vous risquez d’être étiqueté comme luddiste et viré avant même que l’IA vous prenne votre poste
J’adhère à l’idée que cette dynamique et les va-t-en-guerre sont en train de bousiller la planète
L’affirmation selon laquelle « personne n’en voulait » manque aussi de fondement
Heureusement, je travaille côté gestion d’applications et je sais qu’on ne peut voir que la dernière date d’utilisation, donc une requête par jour suffit
Mais je suis vraiment épuisé par cette surchauffe autour de l’IA
Je travaille dans une FAANG, mais pas chez Amazon, et j’ai beaucoup entendu ce genre d’histoires en interne comme en externe
Cela dit, je n’ai jamais entendu les personnes importantes, c’est-à-dire la direction, le dire officiellement
Ça commence toujours par des rumeurs ou par des dashboards et des métriques bricolés par quelqu’un en interne, puis ça prend de l’ampleur
J’ai aussi entendu des dirigeants dire : « Ce n’est pas ce que nous regardons, et il ne faut pas gaspiller des tokens coûteux »
Bien sûr, il est déjà arrivé qu’on utilise des métriques absurdes comme le nombre de lignes de code ou de commits sans vraiment l’assumer pleinement, mais je ne crois pas que ce soit aussi simple que plus il y a de tokens, mieux c’est
Quand on répond que ce n’est pas une bonne métrique et qu’elle est très facile à détourner, la direction l’admet… puis enchaîne immédiatement en nous disant d’augmenter quand même la dépense de tokens de nos équipes
Je le sais parce qu’il existe un dashboard de suivi des tokens que la direction consulte et qu’elle affiche directement en réunion
Heureusement, cela n’a pas encore été rendu public sous forme de classement pour tout le monde
Il y a beaucoup de rumeurs selon lesquelles la dépense de tokens entrera dans les évaluations ; la direction le nie, puis organise de nouvelles réunions sur l’importance d’augmenter cette dépense et discute des insuffisances visibles dans le dashboard
Dans les entreprises qui créent des classements de consommation de tokens ou laissent entendre que les ingénieurs refusant les outils IA pourraient être licenciés, le problème explose
Une course à qui brûlera le plus de tokens pour survivre s’enclenche alors
C’est particulièrement marqué chez les développeurs qui lisent beaucoup les réseaux sociaux
Sur Twitter, Threads, Mastodon, LinkedIn, etc., les récits viraux sur la nécessité de devenir AI-native et de licencier ceux qui n’utilisent pas assez l’IA sont recyclés en boucle, et les développeurs anxieux finissent par croire qu’ils doivent brûler plus de tokens que leurs collègues pour éviter d’être inclus dans la prochaine vague de licenciements
Ensuite, on a dit aux contributeurs individuels de l’organisation qu’ils devaient utiliser l’IA pour tout, sous peine de conséquences possibles sur leur carrière
On enchaîne les formations obligatoires, ateliers et hackathons pour « encourager » l’usage de l’IA dans le travail quotidien
Même pour des tâches qu’un simple shell script ferait très bien, on demande : « comment pourrait-on transformer ça en agent ? »
On a beaucoup payé pour Copilot, donc ils veulent voir les gens s’en servir
Le but est peut-être précisément d’amener les gens à jouer avec la métrique
Si on pousse les gens à utiliser davantage l’IA, ils essaient, expérimentent et « gaspillent » du temps tout en apprenant
C’est peut-être le véritable objectif
En ce moment, ils brûlent des tokens sur des tâches inutiles pour découvrir où cela aide vraiment
Et c’est aussi comme ça qu’ils apprennent où cela n’aide pas
Mon entreprise fait la même chose
Oui, cela peut être gaspilleur, mais c’est aussi la façon la plus rapide d’explorer où l’IA peut réellement être utile à l’entreprise
Même si 80 % des employés ne font que gaspiller des tokens, les 20 % restants sont en train de trouver comment s’en servir
Si on a tant d’argent à brûler, je peux imaginer de pires manières de le gaspiller, mais si on est sérieux, c’est idiot
A-t-on déjà vu des entreprises dépenser des millions de dollars et autant de temps humain pour « découvrir à quoi cet outil pourrait bien servir » ?
C’est une solution à la recherche d’un problème
Si, au départ, on n’a pas une idée claire des problèmes que cet outil résout, il faut l’abandonner et passer à autre chose
L’argent restant vaudrait mieux être rendu aux salariés et aux actionnaires
C’est dommage que l’IA dispose désormais d’un programme de revenu universel de base en emploi, alors que les humains n’en ont toujours pas
Les entreprises paient des IA pour creuser des trous, puis d’autres IA pour les reboucher
[1] https://locusmag.com/feature/cory-doctorow-full-employment/
L’URSS a atteint le plein emploi à 100 % il y a longtemps[0], avec la pauvreté qui allait avec
Ce n’est pas la même chose ici, puisque ce n’est pas financé par l’impôt
Des entreprises privées expérimentent avec leur propre argent et prennent aussi le risque de voir leurs clients partir ailleurs si les coûts montent plus tard
C’est bien préférable à un système où l’on donne de l’argent aux gens via l’impôt forcé, indépendamment de la productivité
[0] https://nintil.com/the-soviet-union-achieving-full-employmen...
En interne chez Amazon, avec Kiro, la consommation de tokens est gamifiée
Ce n’est pas comme chez AWS où les coûts sont refacturés aux équipes, ni comme dans l’ancien système où il fallait justifier la capacité
Bien avant que quiconque ne regarde des classements internes, il était déjà crédible d’entendre que les gens jouaient avec cette métrique, et les utilisateurs enthousiastes créent et partagent toutes sortes de projets internes
Il est certain que les managers, qui entendent dans les présentations internes des promesses du type N00 % de gain de productivité, exercent une pression, mais là où je suis, on repérerait assez vite quelqu’un qui fabrique de faux travaux au lieu de faire son vrai boulot
La pression vient plutôt de délais agressifs et du passage, dans le processus annuel OP1, à un mode de fonctionnement plus agile
J’ai entendu des histoires similaires venant d’AWS mais aussi d’employés FAANG hors AWS
Tous les classements de tokens portent une mention du type « ceci n’est pas pris en compte dans les évaluations », mais avec derrière une impression implicite de clin d’œil entendu
Dans une organisation dont on m’a parlé, quelqu’un fait tourner GasTown 24 h/24 pour dévorer des tokens
Il ne contribue pas beaucoup, mais reste confortablement en tête du classement
Il fait tourner GasTown et laisse des agents tripoter toute la base de code, ce qui produit environ 50 commits par jour
Des versions compatibles, du formatting, ce genre de choses
Le problème, cependant, ce n’est pas la technologie, c’est lui
Il était déjà comme ça avant les LLM
Il « refactorisait » le dépôt en plus petits dépôts pour que son nom se retrouve soudain associé à tout le code, donnant l’impression au premier coup d’œil qu’une grosse partie du code de l’entreprise venait de lui
Il refusait parfois que je fasse quelque chose, puis le faisait lui-même plus tard
Il pinaillait sans fin sur mes pull requests, ou me disait carrément qu’il ne fallait pas faire telle chose, avant de se retourner et de l’implémenter lui-même
Il ne copiais-collait pas mon code, mais après l’ouverture de ma PR, il réimplémentait la même idée qu’il avait refusée
Il est très intelligent, mais aussi très malhonnête, et très bon pour le dissimuler
Si on le confronte, il répond des choses comme « je trouvais juste que cette approche serait plus propre »
Vu de l’extérieur, on peut toujours soutenir qu’une approche vaut mieux qu’une autre, donc la malhonnêteté n’apparaît pas clairement, mais moi je vois à 100 % ce qu’il fait, et le schéma est totalement évident
En plus, une fois, quand j’ai dit que je prendrais des congés une semaine précise, il ne les a pas refusés explicitement, mais m’a demandé si je pouvais les décaler en disant qu’il y avait une forte pression pour livrer The Thing
J’ai répondu que non, je ne les décalerais pas, et il a approuvé
Puis, quand la semaine en question est arrivée, il a lui-même posé des congés cette même semaine
Je n’ai pas cherché à le confronter là-dessus. Je savais déjà très bien qu’il n’a aucune honte à exiger des autres ce qu’il n’accepterait jamais pour lui-même
Si le porte-parole d’Amazon a dit qu’il n’existait ni métrique d’usage de l’IA à l’échelle de l’entreprise, ni classement interne comparant les employés, et que chacun ne voyait que son propre usage dans un dashboard personnel, alors c’est complètement faux
Il existe un dashboard global qui classe les employés par usage de Kiro/QuickSuite (anciennement Amazon Q) en nombre de tokens
Le dashboard lui-même est dans QuickSight, qui fait désormais lui aussi partie de QuickSuite
Les données sont non seulement ouvertes à tout le monde, mais peuvent aussi être triées par rang ainsi que par usage quotidien, hebdomadaire, mensuel ou annuel
Les employés actuels comme anciens y figurent tous sous leur alias interne
Il existe même un système interne de « récompenses » visible dans les profils PhoneTool, avec des titres Kiro/AmazonQ/QuickSuite comme « Blaze », « Thunderstorm », etc. attribués aux employés
On peut cliquer pour voir tous les autres ayant reçu la même récompense
Pour info, PhoneTool est l’annuaire interne permettant de consulter les profils des autres employés
De l’autre côté, je connais plusieurs personnes incapables d’écrire elles-mêmes du code correct ou d’intégrer quoi que ce soit directement
Ces gens qu’il faut constamment tenir par la main produisent d’énormes volumes avec Kiro/AmazonQ et se classent désormais au-dessus des SDE
Ils ressemblent davantage à des SysDev, des ingénieurs support ou des TPM qu’à des SDE
Ce n’est pas intrinsèquement bien ou mal, mais si on fait du stack ranking sur la consommation de tokens, les bons ingénieurs qui s’efforcent d’écrire du « bon » code risquent d’être moins bien notés que ceux qui ne cherchent pas des solutions concises
La qualité finira donc par baisser, et quand la direction comprendra ce qui s’est passé, il sera trop tard
On a déjà vu des incidents liés à Amazon-Q/Kiro, et pourtant ils continuent à nier
Cette tendance arrive aussi chez nous
Si je n’utilise pas Copilot dans MS Office tous les jours, ça m’envoie une notification agacée, donc je tape juste Hello