- Claude Code a lancé un test A/B sans le consentement des utilisateurs, modifiant sans préavis le comportement du plan mode et réduisant l’efficacité du travail
- Dans un outil professionnel à 200 $/mois, le fait de modifier des fonctions clés sans annonce préalable pose problème en matière de transparence et de contrôle utilisateur
- L’un des tests était une variante agressive qui limitait le plan à 40 lignes, interdisait les sections de contexte et demandait de supprimer le texte rédigé pour ne laisser que les chemins de fichiers
- L’ingénieur d’Anthropic ayant mené ce test a expliqué que l’objectif était de réduire la charge liée aux rate limits, mais que l’expérience a été arrêtée faute d’impact significatif dans les premiers résultats
- Le texte souligne que, pour garantir la fiabilité des outils d’IA et un déploiement responsable, le contrôle utilisateur et une gestion transparente des expérimentations sont indispensables
Dégradation de l’expérience utilisateur à cause des tests A/B de Claude Code
- En tant qu’utilisateur passionné dont la manière de travailler a été complètement transformée par Claude Code, l’auteur raconte avoir subi, au cours de la semaine écoulée, une dégradation de son workflow
- Anthropic mène des tests A/B dans Claude Code, ce qui dégrade activement le workflow de certains utilisateurs
- Le principe même des tests A/B n’est pas en cause, pas plus qu’une volonté d’Anthropic de détériorer délibérément l’expérience, mais la conception du test est essentielle : modifier sans explication le comportement perçu d’une fonction centrale comme le plan mode pose problème
Exigence de transparence pour un outil payant
- Comme il s’agit d’un outil professionnel facturé 200 $ par mois, il faut de la transparence sur son fonctionnement et la possibilité de le configurer
- Voir des fonctions essentielles modifiées sans avertissement, ou être enrôlé dans des tests perturbateurs sans consentement, est difficilement acceptable
- Pour piloter de manière responsable des outils d’IA, la transparence et la configurabilité sont essentielles, et les utilisateurs doivent être en mesure d’en bénéficier
- Chaque jour, des ingénieurs se plaignent de régressions dans Claude Code, parfois sans même savoir qu’ils font partie d’un test A/B
Contenu du test et éléments de preuve
- Les plans générés ont commencé à revenir sous forme de listes à puces concises sans contexte
- Lorsque l’auteur a demandé à Claude pourquoi il rédigeait des plans aussi médiocres, celui-ci a répondu qu’il suivait des instructions système spécifiques : limiter le plan à 40 lignes, interdire les sections de contexte et « supprimer le texte rédigé pour ne garder que les chemins de fichiers »
- Concernant la méthode de preuve concrète, l’auteur précise l’avoir retirée des détails après que le sujet a attiré l’attention sur Hacker News, afin d’éviter que d’autres ne reproduisent la même tentative
- L’auteur affirme qu’une telle approche va à l’encontre de la transparence et d’un déploiement/usage responsable de l’IA
Réactions sur Hacker News et angle du coût
- Un commentaire sur Hacker News souligne qu’Anthropic doit faire des arbitrages de capacité à chaque étape de Claude Code : tout pousser au maximum entraînerait plus de pertes ou moins de bénéfices par utilisateur
- Selon ce point de vue, 200 $/mois pourraient en réalité représenter 400 $/mois de coût, et utiliser des tests A/B pour trouver une base de référence à chaque étape pourrait être préférable à l’imposition arbitraire de limites
Réponse de l’ingénieur d’Anthropic
- L’ingénieur de Claude Code qui a mené le test a répondu directement dans le fil Hacker News
- Le prompt du plan mode n’a pas beaucoup changé depuis la série 3.x, et les modèles 4.x peuvent fonctionner correctement avec bien moins d’instructions
- L’hypothèse était qu’en raccourcissant les plans, il serait possible d’obtenir des résultats similaires tout en réduisant le nombre d’atteintes aux rate limits
- Plusieurs variantes ont été testées, et l’auteur (comme des milliers d’autres utilisateurs) s’est vu attribuer la variante la plus agressive, celle qui limitait le plan à 40 lignes
- Les premiers résultats n’ayant montré aucun effet important sur les rate limits, l’expérience a été arrêtée
- La planification a deux objectifs : aider le modèle à garder la bonne direction et aider l’utilisateur à avoir confiance dans les prochaines actions du modèle — deux dimensions floues, complexes et non triviales
Conclusion : responsabilité des expérimentations sur les outils d’IA et confiance des utilisateurs
- À travers le cas de Claude Code, l’auteur montre que les expérimentations sur les outils d’IA peuvent avoir un impact direct sur l’expérience utilisateur
- Il insiste sur le fait qu’une gestion transparente des expérimentations et la garantie du choix utilisateur sont essentielles pour préserver la confiance dans les outils professionnels
- Même si les systèmes d’IA continuent d’évoluer, il faut réaffirmer la nécessité de maintenir une structure sous contrôle humain
1 commentaires
Avis sur Hacker News
Je trouve exagéré de parler d’A/B testing comme d’une « expérience discrète sur les utilisateurs » en citant Meta
L’A/B testing n’est pas mauvais en soi, c’est surtout la conception du test qui compte
En revanche, je pense qu’on ne peut pas accepter des expériences qui dégradent gravement les performances d’un LLM
Les problèmes de reproductibilité et de fiabilité sont déjà graves, et les entreprises en reportent la charge sur les utilisateurs
Si une entreprise mène en plus des expériences en douce dans ce contexte, la confiance dans la recherche s’effondre complètement
Dans le cas de Claude Code, même des résultats négatifs dus à l’A/B testing peuvent être écartés sous prétexte que « c’était peut-être le groupe test »
Si ce type d’expérimentation a lieu dans des domaines sensibles comme le recrutement, les problèmes éthiques et juridiques deviendront particulièrement graves
L’interface ou les fonctionnalités changent soudainement, et quand on demande à ses collègues, personne ne comprend ce qui se passe
En général, ces changements empirent les choses, mais on les impose quand même au nom de « données objectives »
Même un détail mineur comme la couleur d’un bouton reste une expérience, et dans la plupart des cas, les utilisateurs ne sont même pas informés qu’ils participent à une expérience
C’était un test que j’ai mené moi-même
J’ai essayé de voir si on pouvait simplifier sur les modèles 4.x le prompt plan-mode conservé depuis la série 3.x tout en obtenant des résultats comparables
J’étais parti de l’hypothèse qu’un plan plus court déclencherait moins souvent le rate-limit, mais comme la différence était minime, j’ai arrêté l’expérience
Le mode plan a deux objectifs : aider le modèle à se donner une direction, et permettre à l’utilisateur de faire confiance au résultat
Le coût ne vient pas du texte du plan, mais de l’étape d’exploration (subagent)
Le mode plan lance toujours 3 agents d’exploration et ne tient pas compte de l’état de la session
Même quand des fichiers sont déjà chargés, ils sont relus, ce qui gaspille des tokens
Quand la session est déjà chaude, une logique conditionnelle pour sauter l’exploration serait plus efficace
Un seul comportement inattendu peut me rendre inefficace pendant plusieurs jours
Ne pas prendre cet impact en compte est irresponsable et agressif
Des comportements étranges récents pourraient venir de là, et c’est très inconfortable
Au lieu d’un canal bêta, il faudrait un opt-in explicite
Personnellement, je pense que la clarté narrative du plan est plus importante que le nombre de lignes
Il faut un plan qui permette de comprendre ce qui est fait et pourquoi
Les LLM sont grammaticalement parfaits, mais ils mélangent aussi des hallucinations qui déconcertent les utilisateurs
Ils restent utiles pour les tâches boilerplate ou pour relier rapidement des idées
Mais pour bien les utiliser, des connaissances de base sont indispensables
Si le texte s’arrête brutalement, c’est parce que l’auteur a supprimé la partie sur la décompilation du binaire Claude Code en raison d’un risque de violation des ToS
On peut voir la discussion associée dans ce commentaire
J’ai deux réflexions
Parce que les améliorations pilotées par les données via de vastes A/B tests y sont impossibles
Par exemple, des changements imprévisibles peuvent apparaître, comme le easter egg « after midnight » de man-db
Il y a aussi tellement de dépendances que presque personne ne fait réellement d’audit du code
Cela peut aussi être une expérience de monétisation (enshittification) — YouTube en est un exemple typique
L’A/B testing en soi ne pose pas de problème, mais le plan mode n’est pas terrible
Dans la plupart des cas, les résultats sont mauvais
En revanche, la capacité à conserver l’information lors de la compaction est bonne
En consignant la conversation dans un fichier Markdown et en s’y référant à chaque compaction, on peut obtenir de bien meilleurs résultats
Le plan mode est bien plus efficace, donc je l’utilise avant presque toutes les tâches
Son avantage est de permettre d’examiner et de discuter le plan avant que le modèle n’exécute quoi que ce soit
Actuellement, le plan mode réinitialise le contexte à la fin, ce qui est pratique pour préparer proprement le plan suivant
C’est dommage que le blog ait supprimé les détails de la décompilation à cause d’un problème de ToS
Claude aurait suivi une instruction système disant de « limiter le plan à 40 lignes, interdire les sections de contexte et supprimer la prose »
Ce serait bien de pouvoir voir et modifier directement ce type de réglages
Un outil professionnel doit offrir fiabilité et reproductibilité, mais ce n’est pas le cas des LLM
L’A/B testing n’en est qu’une preuve de plus
Des expériences du même type, où Photoshop modifierait légèrement la teinte ou Word le style des titres, poseraient exactement le même problème
C’est l’A/B testing sans avertissement qui pose problème
Les quotas et la qualité des modèles sont instables, et avant la sortie d’un nouveau modèle, il arrive que l’ancien se dégrade
Cette expérience aussi ressemble davantage à un test de réduction des coûts qu’à une amélioration de l’expérience utilisateur
Pour un outil professionnel, il faut de la cohérence et de la fiabilité
Un professionnel doit comprendre les forces et les faiblesses de son outil et l’utiliser à bon escient
Accepter aveuglément les sorties d’un LLM n’est pas professionnel, mais cela ne signifie pas pour autant qu’un professionnel ne peut pas utiliser un LLM
Avec un cadre d’évaluation suffisant et un bon contrôle des prompts, on peut rendre le système assez déterministe
Quand on voit que des modèles instables dans la finance continuent malgré tout à être exploités, l’imprévisibilité n’est pas une barrière absolue
Moi, je vérifie la sortie du modèle comme je ferais une revue de code par un pair
Ce genre de situation est depuis longtemps appelé vendor lock
Quand on dépend d’un outil particulier, on ne peut plus travailler si cet outil change ou disparaît
Je suis passé de CC à opencode
CC était trop fermé et ses prompts trop opinionated, ce qui me gênait
Il était aussi impossible de contrôler le chemin de recherche web
Aujourd’hui, comme je ne l’utilise qu’en loisir, j’ai choisi l’open source, mais pour un usage professionnel j’aurais peut-être décidé autrement
Je n’ai pu l’utiliser que sur de petits projets
Si tu as une configuration correcte, j’aimerais bien que tu la partages