Mise à jour sur les récents signalements concernant la qualité de Claude Code

• La baisse de qualité perçue de Claude au cours du dernier mois provenait de trois changements distincts touchant Claude Code, Claude Agent SDK et Claude Cowork, et l’API n’a pas été affectée
• Après avoir abaissé l’intensité de raisonnement par défaut à medium, la latence et les limites d’usage ont diminué, mais Claude Code a donné l’impression d’être moins intelligent, ce qui a conduit à rétablir la valeur par défaut le 7 avril
• Un bug d’optimisation du cache déployé le 26 mars a créé, pour les sessions ayant dépassé le seuil d’inactivité, un état où l’historique de raisonnement était effacé à chaque tour, entraînant oublis, répétitions, choix d’outils étranges et consommation plus rapide des usage limits
• Une ligne ajoutée au system prompt avec Opus 4.7 le 16 avril visait à réduire la verbosité des sorties, mais des évaluations plus larges ont montré une baisse de 3 % des performances sur certains modèles, et le changement a été annulé le 20 avril
• Les trois problèmes ont tous été corrigés et intégrés dans v2.1.116, publiée le 20 avril ; la réduction de l’écart entre les builds internes et publics, un contrôle renforcé des system prompts, des évaluations plus larges et des déploiements progressifs sont au cœur de la prévention des récidives

---

Étendue de la récente baisse de qualité et état de la récupération

• La baisse de qualité de Claude ressentie par certains utilisateurs au cours du dernier mois provenait de trois changements distincts touchant Claude Code, Claude Agent SDK et Claude Cowork, et l’API n’a pas été affectée
• Les trois problèmes ont tous été résolus et intégrés dans v2.1.116, publiée le 20 avril
• Chaque changement a affecté des calendriers et des segments de trafic différents, donnant globalement l’impression d’une dégradation des performances à la fois large et incohérente
• Les signalements associés ont été examinés depuis début mars, mais il était au départ difficile de les distinguer des variations habituelles dans les retours utilisateurs, et le même problème n’a pas été reproduit immédiatement en usage interne ni dans les évaluations
• Au 23 avril, les usage limits de tous les abonnés ont été réinitialisées

Changement de l’intensité de raisonnement par défaut de Claude Code

• Lors du lancement de Opus 4.6 dans Claude Code en février, l’intensité de raisonnement par défaut était réglée sur high
• Peu après, des temps de réflexion excessivement longs sont apparus de façon intermittente en mode high, donnant l’impression que l’interface était bloquée, et pour certains utilisateurs, la latence comme la consommation de tokens sont devenues excessives
• Le niveau d’effort de Claude Code sert à arbitrer entre faire réfléchir le modèle plus longtemps ou privilégier une latence plus faible et une moindre consommation des limites d’usage
  • Au niveau produit, une valeur par défaut est choisie sur une courbe calculée au moment des tests et transmise à la Messages API comme paramètre d’effort
  • D’autres options sont proposées via /effort
• Dans les évaluations et tests internes, medium donnait sur la majorité des tâches une intelligence légèrement inférieure mais une latence nettement réduite
  • medium présentait aussi moins de problèmes de latence extrême en longue traîne
  • Et favorisait également la maximisation des usage limits des utilisateurs
• Sur la base de ces résultats, l’effort par défaut a été changé en medium, avec une boîte de dialogue dans le produit expliquant aussi la raison
• Juste après le déploiement, les utilisateurs ont commencé à avoir l’impression que Claude Code était moins intelligent
  • Plusieurs changements de design ont été apportés pour mieux rendre visible le réglage d’effort, comme une notification au démarrage, un sélecteur d’effort en ligne et le rétablissement de ultrathink
  • Mais la plupart des utilisateurs sont malgré tout restés sur la valeur par défaut medium
• En tenant compte des retours clients supplémentaires, cette décision a été annulée le 7 avril
  • Désormais, pour tous les utilisateurs, Opus 4.7 a xhigh par défaut
  • Et tous les autres modèles utilisent high par défaut
• Ce changement a affecté Sonnet 4.6 et Opus 4.6

Une optimisation du cache qui supprimait l’historique de raisonnement précédent

• Lorsque Claude raisonne sur une tâche, son historique de raisonnement reste dans l’historique de la conversation, ce qui lui permet de continuer à se référer aux modifications précédentes et aux raisons des appels d’outils à chaque tour suivant
• Le 26 mars, un changement destiné à améliorer l’efficacité de cette fonction a été déployé
  • Anthropic utilise le prompt caching pour rendre les appels API successifs moins coûteux et plus rapides
  • Lors d’une requête API, Claude écrit les tokens d’entrée dans le cache et, après une certaine période d’inactivité, le prompt concerné est retiré du cache pour libérer de la place pour d’autres prompts
  • L’utilisation du cache est gérée avec soin, et l’approche associée est résumée dans approach
• Dans la conception, si une session était restée inactive plus d’une heure, l’objectif était de vider une seule fois les segments de thinking précédents afin de réduire le coût de reprise de session
  • Cette requête serait de toute façon un échec de cache, donc l’idée était de réduire le nombre de tokens non mis en cache envoyés à l’API en supprimant de la requête les messages inutiles
  • Ensuite, l’envoi de l’historique complet de raisonnement devait reprendre
  • Pour cela, l’en-tête API clear_thinking_20251015 et keep:1 étaient utilisés
• L’implémentation réelle comportait un bug : au lieu d’effacer l’historique de thinking une seule fois, il continuait à être effacé à chaque tour jusqu’à la fin de la session
• Une fois qu’une session avait dépassé le seuil d’inactivité, toutes les requêtes suivantes de ce processus étaient envoyées à l’API en supprimant les blocs de raisonnement antérieurs, à l’exception du plus récent
• Le problème s’aggravait de façon cumulative
  • Si Claude envoyait un message de suivi pendant qu’il utilisait des outils, cela devenait lui-même un nouveau tour sous ce drapeau défectueux
  • En conséquence, même le raisonnement du tour en cours pouvait être perdu
• Claude continuait à fonctionner, mais de plus en plus sans mémoire des raisons pour lesquelles il avait choisi tel comportement
  • Pour l’utilisateur, cela se manifestait par de l’oubli, des répétitions et des choix d’outils étranges
• Comme les blocs de thinking continuaient aussi à disparaître dans les requêtes suivantes, celles-ci aboutissaient à des échecs de cache
  • Les signalements séparés indiquant que les usage limits se consommaient plus vite que prévu semblent provenir de ce phénomène
• Deux expérimentations sans lien direct ont contribué à la difficulté de reproduction initiale
  • Une expérimentation interne côté serveur liée à la mise en file des messages
  • Et une modification distincte de l’affichage du thinking a masqué ce bug dans la plupart des sessions CLI
• Ce bug se situait à l’intersection entre la gestion du contexte de Claude Code, l’API Anthropic et l’extended thinking
  • Il a passé plusieurs revues de code humaines ainsi qu’une revue de code automatisée
  • Des tests unitaires et des tests de bout en bout
  • Et même la validation automatisée et le dogfooding
• Comme ce problème ne survenait que dans le cas limite des anciennes sessions et restait difficile à reproduire, il a fallu plus d’une semaine pour découvrir et confirmer la cause profonde
• Pendant l’enquête, les pull requests à l’origine du problème ont fait l’objet d’un backtest avec Code Review sur Opus 4.7
  • Lorsqu’on lui fournissait aussi les dépôts de code nécessaires pour rassembler tout le contexte, Opus 4.7 a détecté le bug
  • Opus 4.6 ne l’a pas détecté
• Pour éviter qu’une situation similaire se reproduise, une prise en charge permettant d’ajouter des dépôts supplémentaires comme contexte dans la revue de code est en cours de déploiement
• Ce bug a été corrigé dans v2.1.101 le 10 avril
• Ce changement a affecté Sonnet 4.6 et Opus 4.6

Changement du system prompt destiné à réduire la verbosité

• Le modèle le plus récent, Claude Opus 4.7, a tendance à produire des sorties très verbeuses par rapport aux modèles précédents
  • Cette caractéristique avait été abordée lors de son annonce, avec plus de détails dans wrote about
• Cette verbosité le rend plus intelligent sur les problèmes difficiles, mais augmente aussi le nombre de tokens en sortie
• Pendant les semaines précédant le lancement d’Opus 4.7, Claude Code a été ajusté pour le nouveau modèle
  • Chaque modèle se comporte un peu différemment, donc avant une release, le harness et le produit sont optimisés par modèle
• Pour réduire la verbosité, l’apprentissage du modèle, le prompting et les améliorations de l’UX du thinking dans le produit ont été utilisés conjointement
• Parmi eux, une ligne ajoutée au system prompt a eu un impact excessif sur l’intelligence de Claude Code
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• Dans plusieurs semaines de tests internes et dans les jeux d’évaluation exécutés, aucune régression n’a été observée, ce qui a conduit à déployer ce changement en confiance avec Opus 4.7 le 16 avril
• Lors de l’enquête qui a suivi, une ablation a été effectuée à l’aide d’un jeu d’évaluations plus large afin d’isoler et de vérifier l’impact de chaque ligne du system prompt
• Dans l’une de ces évaluations, une baisse de 3 % a été observée à la fois sur Opus 4.6 et 4.7
• Ce prompt a été annulé immédiatement dans le cadre de la release du 20 avril
• Ce changement a affecté Sonnet 4.6, Opus 4.6 et Opus 4.7

Changements à venir

• Pour éviter des problèmes similaires, davantage de personnel interne utilisera exactement le même Claude Code que le build public
  • L’objectif est de réduire l’écart entre la version interne utilisée pour tester les nouvelles fonctionnalités et le build réellement public
• L’outil Code Review utilisé en interne sera amélioré, et cette version améliorée sera également déployée chez les clients
• Des procédures de contrôle plus strictes sont ajoutées pour les changements de system prompt
  • Des évaluations larges seront menées par modèle pour toutes les modifications du system prompt de Claude Code
  • Les ablations continueront afin de comprendre l’impact de chaque ligne
  • De nouveaux outils sont aussi en cours de développement pour faciliter la revue et l’audit des modifications de prompt
• Des consignes ont été ajoutées dans CLAUDE.md pour que les modifications spécifiques à un modèle ne s’appliquent qu’à ce modèle
• Tous les changements susceptibles d’entrer en conflit avec l’intelligence seront accompagnés d’une soak period, de jeux d’évaluation plus larges et d’un déploiement progressif pour détecter les problèmes plus rapidement
• Un compte X, @ClaudeDevs, a été créé pour expliquer plus en détail les décisions produit et leur contexte, et les mêmes mises à jour seront aussi partagées dans un fil centralisé sur GitHub
• Les informations transmises via la commande /feedback ou par des exemples précis et reproductibles en ligne ont contribué à identifier et corriger les problèmes
• La réinitialisation des usage limits de tous les abonnés a été appliquée de nouveau ce jour-là

[GN⁺]

Avis sur Hacker News

• L’explication selon laquelle, dans les sessions inactives pendant plus d’une heure, ils ont supprimé l’ancien thinking pour réduire la latence ne me convainc pas vraiment
  De mon côté, je laisse souvent une session de côté pendant plusieurs heures, voire plusieurs jours, puis je reprends avec tout le contexte intact, donc cette fonctionnalité était essentielle
  Je peux comprendre dans une certaine mesure la baisse du niveau de thinking par défaut, mais comme le prompt système continue de changer, j’ai l’impression qu’il va falloir que je comprenne comment choisir moi-même volontairement le cycle de rafraîchissement

  • Dans Claude Code, lorsqu’une conversation contient N messages, en général N-1 messages, à l’exception du plus récent, passent par le prompt cache
    Le problème, c’est que si une session reste inactive plus d’une heure, alors au moment de renvoyer le prompt, les N messages ratent tous le cache
    Ce corner case faisait exploser le coût en tokens pour l’utilisateur, et dans un cas extrême avec un contexte de 900k tokens, il fallait réécrire plus de 900k tokens dans le cache à chaque retour, ce qui grignotait fortement la rate limit des utilisateurs Pro
    Ils ont donc essayé d’éduquer les utilisateurs sur X, ajouté à plusieurs reprises dans le produit des conseils recommandant /clear au retour sur une ancienne conversation, et testé des méthodes consistant à omettre, après une période d’inactivité, les anciens résultats d’outils, les anciens messages ou une partie du thinking ; parmi tout cela, c’est la suppression du thinking qui a donné les meilleures performances
    Pendant le déploiement, le bug mentionné dans le billet de blog s’est introduit involontairement, et ils disent qu’ils répondront à d’autres questions s’il y en a
  • C’est surprenant qu’une entreprise valorisée à plusieurs dizaines de milliards de dollars ait pris une telle décision
    Soit ils croyaient vraiment qu’il valait mieux sacrifier la qualité de sortie pour réduire la latence des sessions inactives, soit l’objectif réel était surtout la réduction des coûts, et le billet de blog utilise la latence comme justification présentable
    Il aurait semblé bien plus naturel d’afficher plus clairement un indicateur de chargement pendant le rechargement du contexte
  • C’est assez choquant
    Avant, j’utilisais CC un peu comme un collègue : je réfléchissais un moment à un problème, je mettais à jour le plan, j’y repensais sous la douche, puis je revenais avec de nouveaux conseils, et je considérais au moins une journée comme une conversation statique
    Mais si la limite est d’une heure, c’est beaucoup trop court, au point de me faire reconsidérer le maintien de mon abonnement anthropic
  • L’explication de la suppression des tokens après une heure paraît encore plus suspecte, parce que cette durée correspond justement à leur limite de cache
    Cela ressemble moins à une coïncidence qu’à un changement probablement destiné à faire baisser fortement les coûts
  • Cela risque aussi d’interagir de la pire manière possible avec la réinitialisation de l’usage basée sur le temps
    Si beaucoup d’utilisateurs laissent reposer leur session après avoir atteint leur quota puis reviennent ensuite, ce n’est pas une exception mais presque un mode d’usage par défaut

• Je suis un peu surpris que ça se fasse autant démolir
  Le texte lui-même était relativement clair et honnête, et semblait assez plausible
  La dégradation des performances était réelle et pénible, mais elle révélait aussi l’opacité de ce qui se passe réellement en arrière-plan ainsi qu’un mode de facturation des tokens arbitraire
  Pour quelqu’un qui a déjà manipulé directement des API de LLM, il allait de soi qu’une ancienne conversation reprise après un long moment entraîne un surcoût et de la latence, mais dans le TUI il faudrait visiblement rendre ce point plus visible

  • Si les gens sont en colère, c’est parce que pendant des mois ils ont publiquement nié qu’il y avait un problème
    Donc même maintenant que l’explication existe, le ressentiment reste fort

• Une partie de la baisse de qualité n’est peut-être pas due à une réelle dégradation du modèle, mais à une différence perçue liée à la non-déterminisme
  Il y a quelques semaines, j’ai demandé à Claude de créer une application personnelle de productivité, j’ai décrit en détail le comportement attendu, puis je lui ai demandé d’écrire un plan d’implémentation ; à part un point ambigu, le premier résultat était vraiment excellent
  Après avoir clarifié cette ambiguïté, j’ai relancé la demande depuis zéro dans un nouveau chat sans lui faire réviser le plan existant ; les réglages du modèle étaient pourtant identiques, mais le résultat était bien pire, les deux essais suivants ont aussi échoué, et ce n’est qu’à la quatrième tentative que j’ai retrouvé le niveau du premier résultat
  J’en ai conclu que relancer exactement la même tâche pouvait souvent être la meilleure façon d’obtenir une meilleure sortie, même si, lorsqu’on paie avec ses propres tokens, cela peut vite devenir coûteux

  • Je le vois un peu pareil
    Il y a bien un schéma où l’on a l’impression que le modèle se dégrade périodiquement, mais il se peut qu’en réalité le moment où l’on heurte profondément ses limites arrive simplement plus tard
    Et une fois qu’on a subi une mauvaise sortie par malchance, on ne voit plus que ça ensuite
  • Du coup, faut-il aller vers quelque chose de plus proche de la génération d’images, avec 50 versions produites à partir d’un seul prompt puis sélectionnées manuellement par un humain ?
    Pour Anthropic, ce serait aussi un scénario favorable puisque ce type d’usage augmente la consommation de tokens
  • Pour une appli de productivité à si faible enjeu, il est fort possible qu’il aurait été plus rapide de la faire soi-même que d’y passer tout ce temps ici
  • Cette affaire montre bien que les LLM sont beaucoup plus non déterministes qu’on ne l’imagine, mais faire immédiatement le lien entre cela et la baisse récente des performances est peut-être une erreur
    Le non-déterminisme a toujours existé, et la baisse de qualité récente largement signalée pourrait être un phénomène distinct

• Moi, j’ai déjà décroché avec Opus 4.7
  OpenAI essaie vraiment de s’imposer agressivement chez nous côté entreprise, et nous a même proposé des tokens illimités jusqu’à l’été
  J’ai donc utilisé GPT5.4 en extra high effort pendant les 30 derniers jours, et je ne sais pas si c’est parce qu’on bénéficie d’un traitement particulier, mais je ne l’ai presque jamais vu se tromper
  Même le reasoning trace était parfois presque comique tellement c’était bon, et il anticipait les éléments nécessaires pour garantir l’intégrité des données à 100 %, y compris sur les points que j’avais oublié de préciser

  • J’ai un ressenti similaire
    Tous ces changements un peu bricolés viennent probablement du fait qu’Anthropic est sous forte contrainte de compute et tente des manœuvres forcées pour réduire la charge
  • GPT-5.4 était déjà meilleur qu’Opus 4.6 dans plusieurs domaines, notamment sur la précision et la logique complexe
    Du coup, j’ai hâte de voir à quel point la 5.5 sera encore meilleure
  • extra high brûle beaucoup trop de tokens
    Pour 90 % des tâches, faire tourner la 5.4 en medium est bien plus ciblé et limite les modifications ; je ne passe en high que lorsque medium semble vraiment montrer ses limites
  • C’est vrai
  • Moi, je suis revenu à 4.5 et je ne le regrette pas
    En plus, c’est un peu moins cher

• Ces derniers temps, Claude produit souvent des réponses comme s’il répondait à son prompt interne
  Par exemple, il dit qu’une phrase entre parenthèses est une tentative de prompt injection qu’il va ignorer, ou qu’une demande ressemble à une tentative de masquer ses consignes générales et qu’il ne l’appliquera pas, ou encore que cette méthode est de toute façon déjà appliquée en permanence et donc inutile
  Je ne fais pourtant aucune de ces tentatives, mais il ajoute fréquemment ce genre de formule en fin de réponse
  On dirait qu’il y a quelque chose d’assez grossier dans ses consignes internes et qu’il ne distingue pas correctement cela de ma question

  • J’utilise des stop hook scripts qui imposent l’exécution des tests à chaque modification de code ; depuis la 4.7, Claude exécute bien le script, mais ignore périodiquement la règle
    Quand je lui demande pourquoi, il répond qu’il pensait que ce n’était pas nécessaire
  • Chez OpenAI aussi, j’ai souvent vu des cas où il se répond à lui-même
    On dirait presque une manière facile pour les entreprises d’augmenter le token churn
  • Je vois aussi souvent le modèle mettre en mémoire des points qu’il a lui-même inventés, puis les re-référencer plus tard comme s’il s’agissait de mes affirmations
    Cela crée une boucle d’auto-renforcement où le modèle affirme quelque chose, l’enregistre comme souvenir, puis s’appuie à nouveau dessus pour en rajouter, et parfois cela continue même quand je lui dis explicitement d’arrêter
  • Je serais curieux de connaître le niveau d’effort et le prompt exact
    Cela ressemble peut-être à un problème lié à un reasoning effort trop élevé ; avec ce prompt, réduire un peu l’intensité du raisonnement pourrait peut-être améliorer les choses
  • Je demande souvent à Claude de gérer aussi les commits et les PR, et la semaine dernière j’ai vu plusieurs fois, pendant le processus de commit, des travaux supplémentaires inutiles qu’il avait entrepris de sa propre initiative
    Ça a échoué à l’étape git add, mais en mode auto, une fois, ça a bien failli passer

• Le fait que la raison de la baisse du reasoning effort par défaut de high à medium soit une latence suffisamment longue pour donner l’impression que l’UI s’était figée paraît encore plus suspect
  Cela signifie qu’au lieu de corriger l’interface, ils ont d’abord abaissé l’intensité de raisonnement par défaut, et dans ce contexte il est difficile de croire qu’ils aient sérieusement suivi les signalements de baisse de performances

  • L’équipe dit avoir fait les deux
    Ils ont amélioré l’état de chargement du thinking, retouché plusieurs fois l’UI pour rendre plus clair le nombre de tokens téléchargés, entre autres
    Mais après eval et dogfooding, ils ont quand même abaissé l’effort par défaut ; c’était une mauvaise décision et ils disent l’avoir annulée
    Ils reconnaissent qu’ils auraient dû anticiper que beaucoup de gens resteraient sur la valeur par défaut sans bien comprendre qu’on pouvait augmenter l’intelligence via /effort

• Dire qu’une session inactive de plus d’une heure est un corner case ne correspond pas du tout à ma manière de travailler
  Sur mes projets personnels, j’utilise souvent Claude Code pour des tâches de 10 à 15 minutes, et avant l’exécution je passe pas mal de temps à échanger avec le modèle sur le plan
  Une fois l’exécution lancée, je vais boire un café ou travailler sur un autre projet avec Codex, donc il est très probable qu’il se passe plus d’une heure avant que je revienne sur Claude

  • C’est probablement un corner case uniquement du point de vue des développeurs
    Confondre ses propres habitudes avec le comportement global des utilisateurs est un piège classique du développement produit
  • Dit comme ça, on a surtout l’impression que, malgré l’ampleur du changement, ils n’ont pas suffisamment testé précisément ce cas limite, ce qui fait aussi douter de la rigueur des tests

• L’approche boîte noire adoptée par les grands frontier labs finira par faire fuir les gens
  Quand on change ainsi le fonctionnement fondamental sans prévenir, puis qu’on ne s’explique qu’après coup, les utilisateurs finissent forcément par se tourner vers les modèles auto-hébergés
  On ne peut pas construire durablement des pipelines, des workflows ou des produits sur une fondation qui bouge sans cesse sous les pieds

• On dirait que les responsables de Claude Code chez Anthropic lisent les commentaires ; il y a quelques jours, j’ai vu une vidéo de theo t3.gg sur le fait que Claude serait devenu plus bête
  Le ton était brutal, parfois excessif, mais j’ai trouvé ses remarques sur le harness bloat assez justes
  À ce stade, il faudrait à mon avis mettre temporairement en pause l’ajout de nouvelles fonctionnalités et pousser fort sur le polissage et l’optimisation
  Sinon, de plus en plus de gens iront chercher des alternatives plus légères et mieux optimisées ; l’essentiel est d’améliorer le harness et de réduire la consommation de tokens
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Même sans parler du reste, la seule expérimentation visant à retirer le support de CC du plan Pro m’a déjà poussé à envisager sérieusement des alternatives
    Je me méfiais déjà du vendor lock-in, mais cet épisode a servi de bon avertissement, et je regarderai sans doute d’abord du côté de opencode+openrouter
  • Il ne faut jamais oublier la vidéo exagérée de theo sur GPT 5 ni le fait qu’il soit ensuite revenu dessus
    Il semble évident que certains créateurs de contenu et OpenAI ont des échanges en coulisses, qu’il s’agisse d’argent ou d’influence
  • Honnêtement, on dirait juste un problème qui se réglerait avec git reset --hard

• On dirait le résultat d’une obsession pour l’ajout de fonctionnalités au détriment de la maturité du produit principal
  J’ai souvent l’impression qu’Anthropic gagnerait à avoir quelques responsables produit senior de plus, avec une vision du type “Escaping the Build Trap”
  Aujourd’hui, ce n’est pas parce qu’on peut ajouter rapidement une fonctionnalité qu’il faut forcément le faire
  Je ne cite pas ce livre pour ressortir les poncifs des organisations produit ; c’est simplement que le sens du produit est un talent différent de l’excellence en ingénierie, et Anthropic semble récemment en manquer sur ce point

  • Ils doivent suivre la demande, mais il semble évident qu’ils manquent de ressources de compute
    Du coup, sans ce genre de fonctionnalités, soit le système s’effondre, soit ils ne peuvent plus accepter de nouveaux clients ; comme aucune de ces options n’est acceptable, ils n’avaient peut-être pas beaucoup de marge de manœuvre
  • À une époque, ils avaient bien une centaine de développeurs payés 600 000 dollars par an chacun, donc le manque de talents n’est probablement pas le problème
    Le vrai problème est peut-être plutôt qu’ils poussent trop fort le récit du vibe coding, au point que certains candidats refusent même des entretiens à cause de ça
  • On dirait qu’ils sont déjà profondément tombés dans le piège de la complexité
    La nature probabiliste du modèle pose déjà problème, mais on a désormais l’impression qu’ils ne parviennent même plus eux-mêmes à raisonner correctement sur leur propre logiciel
    Il y a trop de leviers et de réglages, et il est probable que plus personne ne comprenne l’ensemble du code dans sa globalité
    Plus inquiétant encore, quand on lit les propos de Dario et d’autres, la direction semble assez peu sensible à ces préoccupations sur la qualité
    Dans une vision où les SWEs sont perçus comme remplaçables, les demandes pour mettre des garde-fous sur l’outil paraissent ignorées, voire activement découragées, et au final Claude Code a depuis le départ davantage ressemblé à une expérience scientifique qu’à un produit mûr appuyé sur de véritables best practices