[TL;DR quotidien] Je vais dire à voix haute ce qu’on murmure : quand la facture mensuelle d’IA d’un ingénieur commence à ressembler à une série A, ça ne reste plus une simple histoire d’outillage, mais devient une expérience économique. Alors, que voyons-nous vraiment ici — le prochain système d’exploitation de l’ingénierie logicielle, ou une machine extrêmement coûteuse produisant à grande échelle du « AI slop » ? Probablement les deux. 🤖💸 🔥 Le contexte : un flex de mille milliards de jetons transformé en débat public sur les coûts 📌 Les chiffres phares sont délibérément absurdes • Peter Steinberger, fondateur d’OpenClaw, a estimé que son équipe a dépensé environ 10 M$ en coûts de jetons en un seul mois pour des travaux d’IA, puis a immédiatement ajouté : tout ce dépense n’était pas utile. • Un autre exemple viral provient du profil Cursor de Lauren Tan, qui montrait environ 1,5 billion de jetons utilisés en 30 jours. • En utilisant une estimation approximative de 8 $ par 1 million de jetons, Peter Piekarczyk a estimé cela à environ 384 000 $ par jour, soit 11 M$ par mois, ou 132 M$ annualisés. • Même avec une réduction entreprise de 90 %, l’estimation reste autour de 1,1 M$ par mois, soit environ 13 M$ par an. 📌 Pourquoi les gens ont paniqué : l’utilisation est largement au-delà du comportement normal des développeurs • Les données Jellyfish sur 12 000 développeurs suggèrent que l’utilisateur médian consomme environ 51 M de jetons par mois. • Le 90e percentile se situe autour de 380 M de jetons par mois. • Cela fait de l’utilisation de 1,5 T de jetons de Lauren environ 29 000 fois la médiane, tandis que les 603 M de jetons précédemment partagés par Steinberger étaient encore environ 12 000 fois supérieurs. • Dès que l’utilisation de jetons est traduite en calcul salarial, le récit change rapidement : ce n’est plus un « outil de productivité », mais une aristocratie du calcul. 📌 La facture réelle est complexe, car tous les jetons ne coûtent pas pareil • Les comptages de jetons au style Cursor peuvent inclure l’entrée standard, la sortie du modèle, les écritures et lectures du cache. Ces éléments sont facturés très différemment. • Avec une tarification au style Opus 5.5, 1 million de jetons d’entrée pourrait coûter environ 4 $, les sorties environ 20 $, et les lectures de cache seulement environ 0,20 $. • Une capture d’écran d’utilisation montrait 73,3 M de jetons pour un coût total d’environ 30 k$, ce qui implique un coût moyen d’environ 0,41 $ par million de jetons, car le trafic mis en cache dominait. • Appliquée à 1,5 T de jetons, ce taux combiné réduit le coût mensuel à environ 615 k$, et non à 11 M$. • Dans l’hypothèse la plus basse absolue où tout serait facturé au tarif des lectures de cache, 1,5 T de jetons coûteraient environ 300 k$ par mois. • Piekarczyk a ensuite adouci sa propre estimation : même si son estimation initiale était 10 fois trop élevée, le coût mensuel pourrait encore être d’environ 100 k$. 🔥 Alors, qu’a réellement acheté tout ce dépense ? 📌 Pas « un chatbot », mais tout un organigramme d’agents • Steinberger a décrit ce style de travail comme une exploration de ce que le développement logiciel ressemble quand le coût des jetons n’est plus une contrainte. • Son équipe de trois personnes exécutait environ 100 instances Codex. • Ces agents examinaient les PR, analyisaient l’historique des commits pour détecter des failles de sécurité, fusionnaient les problèmes GitHub dupliqués, écrivaient des correctifs, surveillaient les régressions de performance et même participaient à des réunions pour générer des PR à partir des discussions. • Lauren a décrit son propre dispositif comme une équipe de plus de 20 agents : un agent chef de cabinet, un agent chef de produit et plus de 20 agents d’exécution fonctionnant de manière autonome. 📌 L’idée centrale n’est pas la génération — c’est la vérification • Selon Lauren, le goulot d’étranglement dans le codage par agents n’est pas l’écriture du code, mais la preuve que le code fonctionne réellement. • Son processus fait exécuter le code aux agents, collecter des traces CPU et des instantanés mémoire, lancer des simulateurs iOS et interagir avec les applications comme le ferait un utilisateur. • L’objectif est de créer une boucle fermée : si un agent peut vérifier sa propre sortie, il peut itérer jusqu’à ce que la tâche soit accomplie. • S’il ne peut pas la vérifier, il renvoie un diff à un humain et s’arrête — ce qui fait de l’humain la partie la plus lente du système. • À son échelle revendiquée de 4 000 PR par mois, même cinq minutes d’examen humain par PR représenteraient environ 333 heures, soit presque un mois complet de travail pour une seule personne. L’examen manuel ne peut donc pas être la couche de validation. 📌 Cela change le rôle de l’ingénieur • Dans ce modèle, l’ingénieur ressemble moins à un programmeur et davantage à un manager d’ingénierie pour des agents. • Le point de Lauren est brutal : si vous ne pouvez pas faire confiance à la sortie d’un agent, vous ne pourrez jamais passer à cent agents. • Son workflow pstack encapsule cela dans des playbooks structurés — standardisant la compréhension, la conception, le codage, l’examen et la validation à travers plusieurs agents locaux et cloud. 🔥 Mais voici où l’histoire devient tranchante : toute cette autonomie exigeait des contraintes brutales 📌 La base de code devait être重构ée pour être compatible avec les agents • GrokBot aurait commencé comme un logiciel codé rapidement avec peu de contraintes architecturales et peu de lecture humaine du code. • Cela rendait facile pour les agents de choisir le chemin de moindre résistance : plus de code, des frontières floues, une augmentation du risque de performance. • Pour corriger cela, Lauren dit qu’elle a utilisé plus de 600 PR pour refactoriser le système en une architecture interne appelée Dune. • Les règles CI sont devenues extrêmement strictes : interdiction d’useEffect, interdiction des commentaires et validation des graphes de dépendances pour que Electron main et renderer ne s’importent jamais mutuellement. • En d’autres termes, la partie « intelligente » n’était pas seulement des modèles meilleurs. C’était la refonte de l’environnement pour que les agents aient moins d’occasions d’être négligents. 📌 pstack peut être puissant, mais il pourrait aussi être profondément non portable • Son package inclut 23 playbooks et plus de 20 principes d’ingénierie. • Cela ressemble moins à un workflow universel et davantage à une cage comportementale hautement optimisée pour les modèles. • Ce qui va bien — jusqu’à ce que quelqu’un essaie de copier-coller cela dans des équipes ordinaires avec des budgets ordinaires et des bases de code héritées. Alors la magie pourrait s’évaporer. 🔥 Le backlash : est-ce une innovation ou juste du théâtre informatique pour riches ? 📌 Les critiques disent que c’est une usine à « AI slop » habillée en futur • Sur Reddit et dans les cercles d’ingénierie, beaucoup de développeurs ont affirmé que fusionner des milliers de PR avec un budget quasi illimité en jetons n’est pas une révolution dans l’ingénierie logicielle. • Leur argument : c’est une puissance brute utilisée pour inonder une base de code avec des micro-changements tout en ignorant le vrai goulot d’étranglement — la maintenabilité à long terme. • Autrement dit, la génération de code évolue plus vite que le jugement. Et quand le jugement est sous-financé, la dette est socialisée sur celui qui hérite du dépôt. 📌 La valeur marketing pourrait être supérieure à la valeur ingénierie • Theo, fondateur de T3, a estimé que le vrai coût interne pourrait se situer entre 25 k$ et 50 k$ par mois. • Son raisonnement était simple : même à ce niveau, l’exposition en vaut la peine. Certaines entreprises dépensent 1 M$ sur des événements et obtiennent moins d’attention qu’un seul post viral de Lauren.• Du point de vue de Cursor, cela pourrait être moins une histoire d’économie unitaire et plus une brillante opération de communication. • Lauren elle-même a clairement reconnu son privilège : elle travaille dans un laboratoire d’IA avec des jetons effectivement illimités, donc elle ne prétend pas que tout le monde devrait copier sa méthode exacte. 📌 La question plus profonde est économique, pas seulement technique • Si le développement agentic ne fonctionne bien que lorsque les boucles de validation sont massivement subventionnées, alors le vrai produit n’est pas « la programmation par IA ». C’est l’accès à une vérification à faible coût à grande échelle. • Et si c’est vrai, AgentFi devient le cadre plus intéressant : non pas ce que les agents peuvent faire, mais qui peut se permettre de les laisser opérer de manière autonome. • Le futur pourrait ne pas appartenir aux équipes avec les meilleurs prompts. Il pourrait appartenir aux équipes qui construisent les meilleurs systèmes d’incitation, les meilleures protections et les boucles de vérification les plus efficaces en capital. Mon interprétation ? Cette histoire est utile précisément parce qu’elle met tout le monde mal à l’aise. • Meilleur scénario : c’est un aperçu précoce d’une nouvelle pile d’ingénierie où les agents déployent, testent, réparent et coordonnent à travers des systèmes logiciels. • Pire scénario : c’est un spectacle subventionné en calcul qui confond le volume de sortie avec la qualité du produit. • Le plus probable : la vérité se situe au milieu. Le logiciel agentic peut être réel, mais sans une architecture disciplinée et une économie raisonnable, il ne deviendra peut-être qu’un moyen plus rapide de fabriquer de la dette technique. Voici donc la question que je vous laisse : Si un agent peut écrire 4 000 PR par mois, mais que seule une minuscule élite peut se permettre la facture de validation, est-ce là l’avenir du logiciel — ou juste une démonstration de pouvoir ?