1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le COO d’Uber estime qu’il devient de plus en plus difficile de justifier les dépenses en IA si les résultats ne sont pas à la hauteur des coûts engagés
  • Le débat interne a pris de l’ampleur après que le CTO d’Uber a révélé que le budget 2026 pour Claude Code était déjà entièrement dépensé
  • Le lien entre une consommation accrue de tokens et une hausse proportionnelle de fonctionnalités utiles pour les consommateurs n’a pas encore été démontré
  • Le CEO d’Uber a indiqué que l’entreprise ralentissait son rythme de recrutement pour compenser ses investissements en IA
  • À l’inverse de la tendance tokenmaxxing dans la Big Tech, Duolingo est revenu sur sa décision d’intégrer l’usage de l’IA à l’évaluation des performances après les réactions des employés

Le problème de la justification des coûts de l’IA chez Uber

  • Andrew Macdonald, COO d’Uber, estime qu’il devient de plus en plus difficile de justifier les coûts de l’IA au sein de l’entreprise
  • Dans l’interview Rapid Response publiée samedi, il a expliqué que l’IA ne produisait pas des effets à la hauteur de l’argent dépensé par l’entreprise
  • Le débat interne s’est intensifié après que le CTO d’Uber, Praveen Neppalli Naga, a déclaré dans une interview accordée à The Information en avril qu’Uber avait déjà épuisé son budget 2026 pour Claude Code
  • Cette déclaration a conduit à une situation que Macdonald a décrite comme un « moment où la tête explose », déclenchant dans l’entreprise une discussion sur le compromis entre la consommation de tokens IA et la taille des effectifs

L’absence de lien entre usage des tokens et résultats produit

  • Après avoir échangé avec les principaux responsables de l’ingénierie chez Uber, Macdonald a conclu qu’une consommation accrue de tokens ne se traduisait pas par une augmentation proportionnelle de fonctionnalités utiles pour les consommateurs
  • En disant que « ce lien n’existe pas encore », il estime qu’il est possible que davantage de fonctionnalités soient publiées, mais qu’il reste difficile de relier directement certains indicateurs à la conclusion selon laquelle « nous produisons réellement 25 % de fonctionnalités utiles en plus pour les consommateurs »
  • Plus les dépenses en IA sont difficiles à relier directement aux résultats, plus il devient compliqué de justifier le coût d’arbitrage qu’elles impliquent
  • Le CEO Dara Khosrowshahi a déclaré plus tôt ce mois-ci lors de la publication des résultats qu’Uber ralentissait son rythme de recrutement pour compenser ses investissements en IA

Pour les utilisateurs, cela paraît gratuit, mais c’est l’entreprise qui paie

  • Macdonald estime que l’IA peut sembler gratuite si l’on se place du point de vue des utilisateurs, qui imaginent des « cas d’usage intéressants » sans en supporter le coût
  • Mais au final, c’est l’entreprise qui paie
  • L’extension de l’usage de l’IA n’est donc pas traitée comme une simple expérimentation de productivité, mais comme une structure de coûts qui influe sur le budget et la gestion des effectifs

Une dynamique différente du tokenmaxxing dans la Big Tech

  • La Big Tech pousse fortement le tokenmaxxing, c’est-à-dire l’usage maximal possible de l’IA, et certaines entreprises intègrent le niveau d’utilisation de l’IA dans leurs évaluations
  • Meta, Google et JPMorgan sont cités parmi les entreprises qui lient l’usage de l’IA aux évaluations de performance, aux objectifs, aux augmentations salariales et aux promotions
  • À l’inverse, certaines entreprises commencent à reculer sur l’idée de pousser l’usage de l’IA pour lui-même
  • Duolingo est revenu sur sa décision d’inclure l’usage de l’IA dans l’évaluation des performances après que des employés ont demandé s’il fallait « utiliser l’IA pour utiliser l’IA »
  • Le CEO de Duolingo, Luis von Ahn, a déclaré dans une interview podcast en avril que cela donnait, dans certains cas, l’impression de forcer quelque chose qui n’était pas adapté, plutôt que de responsabiliser sur les résultats réels

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Hacker News
  • Entre 2007 et 2009, quand Google augmentait fortement la taille de ses datacenters, il y avait beaucoup de capacité inutilisée, surtout en dehors des heures de travail
    N’importe quel ingénieur pouvait lancer autant de tâches qu’il voulait en priorité 0, avec l’idée qu’elles seraient les premières à être tuées si un travail plus important avait besoin des ressources
    J’ai fait tourner beaucoup d’expériences MapReduce pendant la nuit, et pendant un temps certains services internes tournaient aussi en priorité 0, ce qui les rendait pratiquement « gratuits » à exploiter
    À mesure que l’usage augmentait, ces services sont devenus de plus en plus instables, et il a finalement fallu soit justifier leur consommation de ressources, soit réduire leur échelle, ce qui me semblait être une bonne évolution
    L’usage des tokens en IA gagnerait sans doute à suivre un modèle similaire. Les grandes entreprises tech pourraient avoir leurs propres datacenters LLM pour couvrir la demande interne, puis ouvrir la capacité inutilisée hors horaires de bureau aux expérimentations des employés
    Dans le travail quotidien, il faudrait encourager non pas le nombre de tokens en soi, mais l’efficacité des tokens. Utiliser beaucoup de tokens pour une automatisation qui fait gagner plusieurs heures de travail humain chaque semaine, c’est un bon usage ; en utiliser beaucoup pour déboguer un bug frontend trivial qui pourrait être corrigé à la main et y passer 4 heures, c’est du gaspillage

    • Ce n’est pas similaire au batch processing d’OpenAI ? Les requêtes sont traitées sous 24 heures et le coût est divisé par deux
      https://developers.openai.com/api/docs/guides/batch
    • Je ne pense pas que les utilisateurs de LLM se comporteront de façon aussi rationnelle. Pas mal de gens semblent persuadés qu’il faut sortir Opus pour la moindre petite tâche
    • La plupart des frontends IA sont conçus pour du travail interactif, ce qui rend difficile la définition de tâches de priorité 0 qui peuvent être exécutées quand l’occasion se présente
      Pour quelque chose comme le développement piloté par spécification, où l’humain ne reste pas en permanence dans la boucle mais supervise au-dessus, cette approche est bien plus naturelle, mais au moins d’après mon expérience des frontends Google, je n’ai encore vu aucun bon support pour ça
    • Empêcher quelqu’un de brûler beaucoup de tokens pendant 4 heures sur un bug frontend facile, ça ne va pas être simple
      Ce qui se passe actuellement paraissait très prévisible pour beaucoup de monde. C’est comme dire à un nouveau toxicomane, conçu délibérément pour devenir accro, de « consommer un peu plus prudemment » : il y a peu de chances que ça marche
    • Au final, il me semble plus probable que tout le monde finisse par accepter les modèles chinois 10 fois moins chers
  • Je n’aime pas utiliser l’IA, et je n’ai pas l’impression qu’elle m’aide beaucoup
    Mais comme l’entreprise impose son usage et suit les métriques, je lui balance chaque jour des petites tâches absurdes juste pour donner l’impression que je l’utilise
    Même si ça crée plus de problèmes que ça n’en résout, sur les métriques je deviens quelqu’un qui utilise l’IA

  • Si une entreprise annonce qu’elle utilise le volume de consommation de tokens comme signal de performance des employés, pour moi c’est quasiment un signal d’alarme qui dit qu’il faut l’éviter
    Une entreprise dotée d’un bon leadership en ingénierie ne devrait jamais traiter ça comme une idée acceptable

    • Si vous dépassez 100 dollars de plafond de repas en déplacement, vous devez avoir une conversation pénible avec votre manager ou la finance
      Mais dans mon entreprise, on dit en plaisantant qu’on peut claquer 500 dollars en tokens IA de manière improductive et être quand même reconnu comme un champion de l’adoption de l’IA
    • Ça peut surprendre, mais je connais plusieurs développeurs de grandes entreprises tech connues de tous, même si ce ne sont pas des FAANG, et ils ont tous une forme de classement des tokens
      Dans certaines boîtes, on dit même aux développeurs qu’on préférerait qu’ils n’écrivent plus une seule ligne de code eux-mêmes
      Le point de vue des dirigeants est probablement quelque chose comme ça : si les 20 % meilleurs employés produisent 80 % du code avec des LLM et que l’entreprise continue de tourner, alors on peut réduire les 80 % de développeurs du bas et économiser des coûts
    • Même des entreprises qui avaient autrefois un leadership raisonnable se sont mises à agir dans la précipitation et à prendre des décisions douteuses depuis l’arrivée des LLM et de l’IA
      Utiliser la consommation de tokens dans l’évaluation des performances des employés n’en est qu’un exemple
    • Les tokens sont le nouveau nombre de lignes de code par ingénieur. C’est facile à mettre en graphique et tout aussi facile à « gérer »
    • Meta fait ça. Il suffit de se demander quel a pu être l’un des critères de ses licenciements récents
  • Il n’y a pas tant de choses vraiment nouvelles sous l’immense réacteur à fusion du ciel
    J’ai lu dans The Information de James Gleick quelque chose qui ressemblait à du tokenmaxxing dans l’industrie du télégraphe
    Les télégrammes étaient facturés au caractère, donc il existait un gros marché des codebooks pour réduire le nombre de caractères transmis. La compression, c’était de l’argent, et les compagnies de télégraphe détestaient ça mais n’avaient pas d’autre choix que de l’accepter
    L’industrie des codes télégraphiques a commencé dès les débuts de la commercialisation du télégraphe et s’est prolongée jusqu’aux années 1920
    Mais cela avait aussi un coût. Les codes réduisaient fortement la redondance, et la moindre petite erreur pouvait entraîner un énorme malentendu
    Comme l’explique Gleick, c’était exactement l’inverse de la manière dont les tambours africains ajoutaient de la redondance pour renforcer la relation entre le rythme et la langue imitée par les tambours

    • Ce n’est pas exactement l’inverse du tokenmaxxing ? Si on veut filer la métaphore du télégraphe, il faudrait plutôt une situation où les télégraphistes sont évalués non pas sur le débit client traité, mais sur la durée pendant laquelle ils occupent la ligne dans la journée
      Autrement dit, celui qui brûle le plus de tokens ou d’argent gagne, et non pas le programmeur qui livre des fonctionnalités
      Ce que tu décris ressemble non pas à une maximisation des tokens, mais plutôt à une minimisation des tokens
    • Intéressant, mais le tokenmaxxing ne consiste pas à maximiser l’efficacité de l’usage des tokens ; il consiste à maximiser l’usage lui-même
    • Ce qui est décrit ici est en fait l’inverse même du tokenmaxxing
  • C’est une question que je me posais déjà avant les LLM à propos de la stack logicielle, et elle paraît encore plus pertinente aujourd’hui
    À quel moment une entreprise comme Uber sera-t-elle « terminée » ? Cela fait 16 ans qu’ils développent du logiciel
    C’est une entreprise qui met en relation conducteurs et passagers, et le fait de développer davantage de logiciel n’augmente pas énormément la probabilité que je choisisse Uber plutôt que le bus ou le train
    Dans 20 ans, le logiciel sera-t-il fini ? Dans 80 ans ?

    • L’essentiel de la base de code correspond à des intégrations sur mesure par marché local. Une partie peut être standardisée, mais c’est de là que vient la majeure partie de la complexité
    • Si le navigateur, Android et iOS restaient figés pendant plus de 16 ans, ce serait peut-être plus facile
      Sans compter l’évolution de l’environnement réglementaire et les nouveaux produits. Il suffit de voir quand Uber Eats est arrivé
      Pendant ces 16 années, il y a eu le Covid-19, l’arrivée d’une conduite autonome réellement exploitable et le partenariat avec Waymo
      Une application grand public connectée à un réseau ne peut jamais être « terminée » à moins de disposer d’une prescience parfaite
      La stack technique interne ressemble à un organisme vivant, et même maintenir un service qui semble inchangé en surface demande énormément de travail. Le passage à l’échelle est déjà un énorme sujet, et mise à l’échelle et maintenance se renforcent mutuellement en permanence
    • On sous-estime sans doute à quel point les opérations internationales et l’optimisation sont complexes
      Chaque pays a ses propres lois sur ce qu’Uber peut ou ne peut pas faire, et il faut les formaliser dans le code
      Par exemple, dans certains endroits, l’app Uber sert en réalité à appeler un taxi, et le tarif peut être calculé au kilomètre au lieu d’être fixé à l’avance
      À cela s’ajoutent les lois propres à chaque ville. Que faut-il faire si l’on prend un Uber de la ville A à la ville B, alors que les règles diffèrent ? Les juristes ont sans doute la réponse, mais l’app doit la respecter
      Et en plus, la loi change constamment
      L’optimisation n’a pas de fin non plus. Il y a toujours des choses à améliorer : vitesse, coût, itinéraire, etc.
      En tant que consommateur, on ne voit probablement qu’un tout petit fragment de la complexité qu’un tel service doit construire et exploiter
    • Il y a toujours de nouvelles technologies et techniques à mettre en œuvre. Il faut de meilleurs algorithmes, des déploiements plus vastes et une fiabilité accrue
      Et il y a presque toujours des bugs à corriger. Vraiment beaucoup de bugs
    • Uber n’a-t-il pas aussi essayé de développer sa propre conduite autonome ?
      C’est aussi le problème d’une entreprise qui a levé des montants énormes. La valeur d’Uber repose moins sur ce qu’elle fait aujourd’hui que sur l’idée qu’elle rendra obsolètes la possession d’une voiture individuelle ou l’usage des transports publics
      C’est exagéré, mais moins qu’on pourrait le croire
  • Le tokenmaxxing n’a aucun sens. C’est comme écrire des jobs SQL/Spark inefficaces pour consommer autant de calcul, de mémoire et d’entrées-sorties que possible
    C’est comme y injecter délibérément des produits cartésiens et des jeux de données extrêmement déséquilibrés
    Quand une métrique devient l’objectif, cela finit toujours ainsi. Les entreprises devraient créer un environnement où l’IA est utilisée aussi efficacement que possible, et commencer par se demander : « Cette tâche a-t-elle vraiment besoin d’un agent ? »
    Si oui, il faut ensuite déterminer quel agent, quel modèle et quel niveau de raisonnement sont nécessaires
    Il faut aussi encourager l’économie de tokens, l’augmentation du taux de hit du cache et la structuration de l’information pour permettre son usage avec moins de contexte. Les graphes de connaissances sont plutôt bien adaptés à cela

    • C’est un raisonnement de niveau maternelle. « Utiliser X peut produire de bons résultats. Donc, pour maximiser les bons résultats, il faut utiliser un maximum de X. »
      C’est comme mettre le feu à une station-service pour gagner une course
    • Si le tokenmaxxing existe, c’est parce que les dirigeants pensent que les employés résistent au changement
      Ce n’est qu’un moyen d’inciter ou de contraindre tous les employés à expérimenter la nouvelle technologie
      Une fois qu’ils considéreront que tout le monde utilise effectivement l’IA, le tokenmaxxing disparaîtra naturellement
    • L’argument en faveur du tokenmaxxing est généralement qu’il laisse aux employés la liberté d’explorer largement ce nouvel espace qu’est le workflow de travail piloté par l’IA
      J’ai vu beaucoup de cas d’usage dont la création de valeur semblait douteuse, mais j’ai aussi vu des équipes résoudre d’anciens problèmes avec des workflows de type agentique qui auraient été difficiles à justifier devant un comité d’examen des coûts
      D’après ce que je comprends, le travail sur l’économie de tokens, l’augmentation du taux de hit du cache et la structuration de l’information pour utiliser moins de contexte est déjà mené en parallèle par des équipes dédiées dans la plupart des grandes entreprises pratiquant le tokenmaxxing
  • Je comprends que les entreprises dépensent de l’argent dans le développement assisté par IA. Mais qu’en est-il du retour sur investissement global ? Est-ce que cela a réellement créé autant de valeur que les gains d’efficacité annoncés ?
    C’est le seul point vraiment intéressant dans la vague IA, et je ne comprends pas pourquoi personne n’en parle

    • Je pense que c’est parce qu’il n’y a pas beaucoup de gens capables de le mesurer correctement
      On peut produire avec Claude cinq fonctionnalités inutiles ou mauvaises en une journée, ou une fonctionnalité utile en deux jours. Laquelle a le meilleur impact sur le retour sur investissement ?
      À travers cet exemple, la réponse semble simple, mais dans la réalité c’est bien plus subtil et bien plus difficile à mesurer
      Donc beaucoup d’entreprises semblent renoncer à mesurer et choisissent la voie facile : suivre le battage médiatique
  • Je suis convaincu que, lorsqu’on l’utilise correctement, y compris avec code review, le gain maximal durable que l’on peut obtenir avec l’IA sur l’usage d’un ingénieur senior correctement qualifié est d’environ 20 %
    Le budget tokens d’un ingénieur ne devrait jamais aller au-delà
    Je ne crois pas du tout qu’un ingénieur qui fait du tokenmaxxing soit réellement productif, et je n’ai jamais vu la moindre preuve en ce sens. Cela pourrait même être plutôt l’inverse
    Avec le bon flux de travail et une bonne connaissance de la base de code, j’ai moi-même constaté qu’un tel niveau est atteignable de façon durable

  • L’IA pour la productivité en ingénierie semble largement mal comprise comme un bouton magique qui produit le même résultat plus vite et moins cher
    Avec cette logique, il est naturel de vouloir imposer le tokenmaxxing aux employés. Si l’on peut obtenir plus de résultats, plus vite et à moindre coût, pourquoi s’en priver ?
    Une lecture plus nuancée serait la suivante : l’IA permet d’atteindre la roadmap un peu plus vite, mais au prix d’une dette technique comparable à celle qu’on accumulerait en embauchant des développeurs temporaires pour produire des fonctionnalités
    Cela ne signifie pas forcément qu’au sein de l’équipe quelqu’un comprendra réellement le nouveau code
    De la même manière, la montée en compétence des profils juniors est plus faible. Il devient plus difficile de capter comme avant l’arbitrage entre niveau de compétence et salaire
    Le produit peut aussi devenir plus complexe. Si une fonctionnalité est classée P2, c’est pour une raison ; avec l’IA, on risque d’inclure aussi des fonctionnalités à faible gain marginal, ce qui complexifie le produit

  • Je suis sidéré que quelqu’un ait pu croire que le tokenmaxxing était une bonne idée
    Les maximalistes de l’IA comparent souvent cette technologie à l’électricité. Il suffit d’imaginer, au début de l’électrification, un CEO qui récompense ses employés pour augmenter leur consommation d’électricité au lieu de chercher comment l’utiliser pour améliorer les résultats de l’entreprise
    À l’époque, il était courant d’interner les personnes montrant des signes de maladie mentale, et j’imagine que cela se serait terminé ainsi

    • Le problème, c’est qu’au niveau individuel, c’est une bonne stratégie. Un mauvais management l’interprète comme un signal de productivité