Claude Code ne rend pas votre produit meilleur

 (ethanding.substack.com)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Les gains de productivité des agents de code ne sont pas uniformes et se scindent selon une courbe en K ; l’indicateur clé n’est pas le nombre de lignes de code par heure, mais le fait que la vitesse d’amélioration du produit par ingénieur augmente réellement
  • Dax, Karri Saarinen et David Cramer ne sont pas des détracteurs de l’IA, mais ils ne sont pas convaincus que les agents de code augmentent nettement la vitesse d’amélioration des produits ; Cramer estime que les LLM accroissent la complexité et le bloat, ce qui ralentit la vitesse à long terme
  • Si Claude Code avait donné à Anthropic un avantage exclusif pendant 7 mois, l’écart avec les concurrents aurait dû se creuser de façon composée ; pourtant Codex, Cursor, Cognition et Factory restent compétitifs, ce qui suggère fortement que le goulot d’étranglement n’est pas la production de code
  • Une bonne culture d’ingénierie considère les lignes de code non comme un actif mais comme un coût ; à mesure que les fonctionnalités et les intégrations se multiplient, la surface de bugs, les dépendances et les fonctionnalités périphériques augmentent elles aussi, et la complexité croît non pas linéairement mais de manière composée
  • À la frontière de la qualité produit, le plus important n’est pas d’écrire du code vite, mais le goût, la capacité de compression, de suppression et de refus ; Claude Code est utile pour passer de 0 au niveau d’une Camry, mais il ne permet pas aux artisans de Ferrari de fabriquer une Ferrari plus rapide

Courbe de productivité en K

  • Les gains de productivité des agents de code ne sont pas uniformes et se scindent selon une courbe en K
    • Les ingénieurs seniors montrent une hausse mesurable de leur production depuis le point d’inflexion des LLM en 2023
    • La production des ingénieurs juniors stagne presque ou diminue
    • L’indicateur important n’est pas le nombre de lignes de code par heure, mais le fait que la vitesse d’amélioration du produit par ingénieur augmente réellement
  • Le développement agentique réduit le temps nécessaire pour produire des Pull Requests sur certaines tâches
    • Des affirmations comme « nous avons résorbé 6 ans de backlog en un trimestre », « nous avons construit le backend en 3 jours avec Cursor » ou « Claude Code a été entièrement codé avec Claude » reviennent régulièrement
    • Mais savoir si la vitesse de production du code constitue un indicateur équivalent à une amélioration de la qualité du produit reste une autre question

Signaux d’alerte chez les ingénieurs qui savent construire de bons produits

  • Dax, Karri Saarinen et David Cramer ne sont pas des critiques de l’IA, mais ils ne sont pas convaincus que les agents de code augmentent nettement la vitesse d’amélioration des produits
    • Dax construit opencode.ai
    • Karri Saarinen est le CEO de Linear
    • David Cramer est la personne qui a créé Sentry depuis zéro et l’a fait croître jusqu’à environ 10 millions de dollars de revenus mensuels
  • David Cramer estime que les LLM ne produisent pas actuellement de gain net de productivité
    • Ils abaissent la barrière à l’entrée, mais créent des logiciels complexes difficiles à maintenir
    • Ils semblent ralentir la vitesse à long terme
    • Il pointe comme problèmes le « manque de performance en développement incrémental dans la complexité », le « manque de capacité à produire une véritable simplification et des interfaces idiomatiques » et les « techniques bancales de génération de tests » des LLM
    • Au final, il juge que l’essentiel relève du bloat
  • Dax déclare ne pas avoir encore trouvé clairement la meilleure manière d’exploiter les agents de code
    • À l’extérieur, en revanche, les affirmations du type « tous les PR sont générés par l’IA », « vitesse sans précédent » ou « 6 ans de backlog résorbés » abondent
    • Mais tous rencontrent des difficultés quand il s’agit d’accélérer réellement la vitesse d’amélioration du produit

L’avantage exclusif de Claude Code ne se traduit pas par un écart

  • Si Claude Code a été entièrement codé avec Claude, alors la vitesse d’amélioration du produit aurait dû s’accélérer
    • Même si l’usage de Claude Code n’augmentait la vitesse d’amélioration du produit que de 1,5x, une équipe qui l’utiliserait depuis le début devrait creuser l’écart avec ses concurrents au fil du temps
    • La productivité d’ingénierie étant une fonction composée, l’écart devrait s’accroître à chaque trimestre
  • La réalité du marché ne montre pas un tel écart composé
    • Codex a été lancé quelques mois après Claude Code, mais il est déjà compétitif sur le plan fonctionnel
    • La dynamique commerciale de Cursor reste forte
    • Cognition et Factory continuent aussi à remporter d’importants contrats enterprise
    • Les gens débattent toujours de l’outil qui est le meilleur
  • Le principal contre-argument empirique est que, si Anthropic avait eu Claude Code en exclusivité pendant 7 mois, alors un véritable avantage de vitesse produit aurait dû creuser un écart impossible à rattraper avec les concurrents
    • Codex aurait dû devenir insignifiant, mais ce n’est pas le cas
    • Si aucun avantage composé n’est visible, il est fort probable que le goulot d’étranglement de la qualité produit n’ait jamais été le code
  • Les objections possibles renforcent en fait la même conclusion
    • Même s’il y a eu un gain, il a pu être absorbé par une dette de complexité
    • L’équipe d’ingénierie d’Anthropic est peut-être trop grande, ce qui aurait dilué le gain marginal par ingénieur
    • Mais dans ce cas aussi, le goulot d’étranglement n’est plus la production de code, mais d’autres facteurs plus difficiles

Les lignes de code ne sont pas un actif mais un coût

  • Une bonne culture d’ingénierie traite les lignes de code non comme une production mais comme une dépense
    • On écrit du code pour les fonctionnalités importantes, et on n’en écrit pas pour celles qui ne le sont pas
    • Une codebase ressemble moins à un actif inscrit au bilan qu’à un passif
  • La filiale logicielle tinychat de comma.ai faisait sonner une alarme quand la codebase dépassait une certaine taille, et célébrait le code supprimé
    • Chaque ligne de code est une surface de bug
    • Chaque fonction devient une dépendance pour la suivante
    • Chaque fonctionnalité engendre des fonctionnalités périphériques
  • La surface du produit s’étend comme un fractal
    • Si vous ajoutez une intégration Slack, il faut une intégration Teams et un chemin de secours par e-mail
    • Si vous ajoutez des notifications, il faut les reconstruire pour le mobile, les SMS et les politiques enterprise de MDM
    • Si vous ajoutez le support MFA, il faut être compatible avec Duo, Okta et SAML
    • La complexité n’augmente pas linéairement mais de manière composée
  • Linear compte 178 personnes, 6 ans d’existence et 100 millions de dollars d’ARR
    • Jira est 56 fois plus gros que Linear en effort d’ingénierie cumulé, mais obtient un score de qualité perçue inférieur de 6 points
    • Le point essentiel est que la qualité et la masse de la codebase ne sont pas la même chose
  • À l’échelle de Facebook, la capacité à produire rapidement du code UI n’est pas le goulot d’étranglement
    • Un ingénieur expérimenté peut produire une maquette du fil Facebook en une journée
    • La vraie contrainte consiste à réduire le nombre de lignes de code nécessaires pour livrer cette expérience à des milliards de personnes, avec uptime garanti quelles que soient la charge et la latence
    • La fonction de récompense n’est pas la production mais la compression
    • Dans ce type de travail, les agents de code ne savent pas évaluer les arbitrages à long terme et n’ont pas de théorie du système

Le vrai goulot d’étranglement est la capacité à faire avancer la frontière des bonnes idées produit

  • À la frontière de la qualité produit, l’amélioration n’est pas limitée par la vitesse à laquelle on écrit du code, mais par la vitesse à laquelle on imagine des idées assez bonnes pour repousser cette frontière
  • La différence entre Jira et Linear ne tient pas au fait d’avoir mieux dessiné des boîtes
    • Linear portait une vision créative précise de ce que devait être l’expérience d’un logiciel de gestion de projet, et l’a exécutée avec discipline pendant des années
    • Cette qualité ne vient pas du débit de tokens mais du goût et de la décision de faire moins
  • L’affirmation « nous avons résorbé 6 ans de backlog » n’est pas aussi impressionnante qu’elle en a l’air
    • Un backlog rempli de fonctionnalités CRUD et d’outils internes correspond bien au type de tâches que les agents de code accélèrent
    • Mais ce type de travail ne fait pas avancer la frontière du produit
    • Sortir plus vite n’améliore pas un produit ; un produit s’améliore quand ce qui est livré donne davantage d’importance aux yeux des utilisateurs
  • Les agents de code IA aident un produit à passer de 0 à 1 plus vite jusqu’à atteindre la frontière de qualité
    • Ils réduisent le temps jusqu’à la première version fonctionnelle
    • Le gain de vitesse existe réellement dans le travail de phase initiale
  • Mais il y a aussi un coût
    • La codebase grossit plus vite que la qualité
    • La dette technique s’accumule de manière composée
    • La vitesse gagnée aujourd’hui s’achète au prix d’un coût qu’il faudra rembourser plus tard

Une Camry pour tout le monde, une Ferrari pour personne

  • Pour les équipes à la frontière, le goulot d’étranglement n’est pas l’agent de code, mais les personnes qui ont du goût
    • La capacité, comme chez Linear et Sentry, à devenir excellent en « retirant plutôt qu’en ajoutant » réside chez certaines personnes spécifiques
    • Nan Yu chez Linear et Kelly Johnson chez Skunk Works sont cités en exemple
    • L’équipe soigneusement sélectionnée de Kelly Johnson a construit le SR-71, qui reste encore 60 ans plus tard l’avion piloté à statoréacteur le plus rapide au monde
    • Si le Blackbird allait vite, ce n’est pas parce qu’il produisait plus de plans, mais parce que Johnson avait une théorie de ce qu’il fallait ne pas conserver
    • Le goût pour supprimer, compresser et refuser ne figure sur aucune roadmap de modèle frontier ; au contraire, plus le niveau plancher monte, plus cette qualité prend de la valeur
  • Si l’on est déjà à la frontière, il n’est pas clair qu’un doublement du budget R&D via la dépense en tokens crée une valeur économique
    • Des ingénieurs de Ramp disent qu’au cours de l’année passée, la dépense en tokens a de fait doublé les salaires
    • Il est difficile de vérifier si le produit Ramp s’est réellement amélioré
    • Quand on est déjà numéro un, le taux de victoire est presque figé, et devenir « numéro un avec un plus grand écart » est difficile à mesurer
    • Pour changer d’avis, il faudrait des données sur le taux de victoire ou sur les résultats financiers de Ramp
    • L’auteur précise qu’en tant que client de Ramp, il ne perçoit pas de différence sensible entre aujourd’hui et l’an dernier
  • Claude Code peut aider tout le monde à construire un concurrent de Camry, mais il n’aide pas les artisans de Ferrari à fabriquer une Ferrari plus rapide
    • Il est très utile pour passer de 0 au niveau d’une Camry
    • Le coût de production d’un logiciel qui n’est pas au plus haut niveau devrait fortement baisser
    • En contrepartie, beaucoup de confusion et de dette s’accumulent dans les chevrons de l’usine, et quelqu’un devra bien finir par nettoyer tout cela

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Commentaires sur Lobste.rs

  • La complexité augmente de façon exponentielle, et peut-être même plus vite. C’est pourquoi même les personnes qui craignent la singularité de l’AGI passent souvent à côté d’un point : peu importe à quel point une personne, un modèle ou un agent est intelligent, dès que les idées, systèmes, projets, bases de code ou ensembles de fonctionnalités grossissent, ils finissent par heurter un mur de complexité qui monte brutalement
    Tous les projets logiciels démarrent relativement bien, mais à un moment, la croissance exponentielle de la complexité finit par tout écraser. Une bonne architecture, une bonne conception et la qualité ne font que repousser ce moment ; des gens compétents, avec une conception solide et un vrai souci de qualité, peuvent peut-être encaisser 10 fois plus de taille, de fonctionnalités, de performances et d’effet waouh, mais on finit quand même par atteindre le mur
    L’assistance par LLM permet de produire beaucoup plus vite des fonctionnalités et du code d’un niveau donné, en général d’une qualité moyenne. Autrement dit, on atteint aussi ce mur beaucoup plus vite. C’est utile pour la croissance, l’expérimentation et les tâches de faible complexité, relativement faciles mais chronophages, mais cela ne permet pas de créer des choses inédites ni de grands projets complexes. Pour cela, il faut des améliorations qui contiennent la complexité, et les LLM actuels ne fournissent pas vraiment cela

    • C’est un problème classique. Quand la cause et l’effet s’enchaînent immédiatement, le bénéfice immédiat est facile à voir ; mais quand il y a un délai entre les deux, les effets négatifs sont bien plus difficiles à percevoir
      http://bastiat.org/en/twisatwins.html
      Le coût de l’usage d’agents de code n’apparaît pas directement, et il vient surtout de la perte de compréhension collective du fonctionnement du système
    • Malgré tout, l’organisation hiérarchique offre une voie pour gérer la complexité à grande échelle. On voit dans la nature des structures extrêmement complexes émerger de cette manière. On peut construire des systèmes à partir d’unités indépendantes qui se combinent pour former des structures plus vastes
      Un système robuste doit pouvoir encaisser des chocs et s’adapter par lui-même ; chaque partie doit donc pouvoir échouer indépendamment et limiter localement les dégâts. En organisant le système en sous-systèmes imbriqués, on obtient des unités comparables à des cellules qui communiquent entre elles pour accomplir le travail. Ces unités fonctionnent comme des sous-ensembles stables sans avoir besoin de connaître les mécanismes internes des autres cellules
      Chaque couche peut ainsi s’auto-organiser dans son périmètre et préserver sa résilience sans être freinée par ce qui se passe ailleurs. C’est en pratique une manière d’encapsuler la complexité accidentelle derrière des interfaces, et de créer des abstractions porteuses de sens. Il vaut mieux voir les couches comme le tissu conjonctif qui relie les composants d’un grand système
      Erlang OTP est un bon exemple logiciel de cette approche : il construit de grands systèmes à partir de processus isolés qui s’échangent des messages. Même si un processus individuel tombe ou rencontre une erreur, l’ensemble du système ne s’effondre pas
    • « Contenir la complexité », à mon sens, exige des décisions, des positions, et parfois de l’opposition ou du conflit
      Si on demande à quelqu’un d’implémenter quelque chose, cette personne peut répondre : « c’est trop complexe », « ça explosera dans un an », « ce n’est pas compatible avec ce que fait l’équipe Y », ou « il n’y a pas assez de monde pour l’implémenter ». Cette dernière réponse peut être littérale, ou une manière indirecte de dire « non »
      Un LLM a très peu de chances de répondre ainsi. En particulier parce qu’il est calibré pour être optimiste et poli. En plus, comme cette tendance est nécessaire pour maximiser l’engagement, il semble peu probable qu’il soit calibré autrement
      Ce problème ressemble à celui des LLM qui ont aidé des utilisateurs à se suicider. C’était assez manifeste, et pourtant les LLM l’ont souvent fait. La mort d’un projet sous le poids d’une complexité non maîtrisée est bien moins évidente ; il y a donc peu de raisons d’attendre des LLM qu’ils gèrent cela beaucoup mieux à court terme

  • Le raisonnement du type « si Claude Code donnait vraiment un avantage de vitesse dans le développement produit, et si Anthropic l’avait gardé exclusivement pendant 7 mois, alors l’écart entre Claude Code et tous ses concurrents devrait être impossible à combler. Codex devrait être sans intérêt. Pourtant, les gens débattent encore activement de savoir lequel est meilleur » ne paraît pas très solide
    Claude Code est un bon logiciel, mais ce n’est pas une sorte de magie AGI étrange qui rendrait toute concurrence impossible

    • En plus, Codex a lui aussi été développé en vibe coding, donc la comparaison est un peu drôle à ce titre aussi. Avoir commencé quelques mois plus tôt n’a peut-être pas beaucoup de sens. Beaucoup des fonctionnalités ajoutées viennent en réalité de ce que les utilisateurs font concrètement avec l’outil
      Claude Code n’avait pas une roadmap complète dès le départ, et le principal obstacle n’était pas la vitesse d’écriture du code. Le vrai obstacle, c’est l’idée. Tout le monde est encore en train de la découvrir en avançant
      Je n’ai fait que survoler l’article dans l’ensemble, donc difficile d’aller plus loin, mais indépendamment du problème de majuscules en début de phrase, cela ressemblait surtout à de la prose écrite par un LLM, donc ça ne m’a pas donné envie de le lire

  • Jusqu’ici, les erreurs des agents ont tendance à s’accumuler de façon multiplicative
    Si l’on crée une API techniquement fonctionnelle mais qui exige un peu de code supplémentaire à l’usage, cela produit davantage de code, donc davantage d’endroits où introduire de la duplication, des branches et des bugs. Puis cela entraîne, de manière fractale, encore plus de code pas terrible
    Un agent a déjà conçu une structure dont le champ id était optionnel. Ce champ n’était nécessaire qu’à cause d’un unique constructeur qu’il avait lui-même écrit. Ensuite, il a infatigablement écrit deux versions du code, selon que id était présent ou non, et a même créé des chemins de remplacement maladroits pour le cas où il serait absent. Ces chemins de secours étaient évidemment complexes et fragiles. Presque tous les usages de cette structure, ainsi que ce qui en dépendait, se sont retrouvés contaminés, alors même que le constructeur sans id n’était jamais utilisé. On aurait facilement pu supprimer la moitié de la base de code
    Je ne sais vraiment pas si on peut corriger cela en injectant suffisamment d’instructions du style « si tu fais quelque chose de stupide, arrête de creuser » et s’il ne reste que quelques bricolages avant de « résoudre » le codage, ou si c’est un problème de fond de perroquet stochastique qui exigera des coûts croissant exponentiellement pour obtenir des améliorations linéaires. Tant que les erreurs s’accumulent avec intérêts composés, la croissance composée finit par vous rattraper

    • J’ai vu des choses très similaires chez des développeurs humains. L’un des traits qui distinguent les meilleurs développeurs est, à mon avis, cette capacité à s’arrêter, à prendre du recul, et à regarder la situation depuis un niveau au-dessus et à l’extérieur
      Parfois, cela inclut même les processus métier. Un développeur qui connaît bien le domaine peut, au lieu de passer des mois à implémenter une solution technique, demander : « plutôt que de continuer à creuser, est-ce qu’on ne pourrait pas simplement changer le processus ? » Et parfois la réponse est : « bien sûr, c’est facile »
      Je pense que les LLM finiront par devenir meilleurs sur ce point aussi. Déjà aujourd’hui, si on leur demande explicitement : « cette approche ne semble pas bonne ; peut-on envisager une alternative ? », ils en trouvent assez souvent une. Mais pour l’instant, les réussites et les échecs sont irréguliers, et une fois qu’ils se sont engagés dans ce genre de bêtise, il est peu probable qu’ils s’en rendent compte d’eux-mêmes pendant qu’ils travaillent sur autre chose
      Il y a aussi un compromis ici. Les gens se plaignent déjà que les modèles sur-réfléchissent aux problèmes et brûlent des tokens. Quand un développeur a de l’expérience et une intuition sur « l’allure » que doit avoir le code pour résoudre un problème donné, il sait naturellement quand il faut prendre du recul. Les agents acquerront peut-être eux aussi cette intuition avec un meilleur entraînement

  • J’aimerais voir une mise à jour fondée sur les données après le point d’inflexion de novembre 2025