Qui maîtrise le mieux Claude Code ? La réponse n'est peut-être pas un programmeur

Auteur : Anthropoic ; Traduction : Peggy, Blockchain Motion

Ce rapport est basé sur environ 400 000 sessions avec Claude Code, discutant de la façon dont les outils de programmation IA changent la relation entre l’homme et le code.

La découverte centrale de l’article est : dans la programmation par agent intelligent, l’humain décide principalement « quoi faire », tandis que Claude est responsable du « comment faire ». L’utilisateur assume la majorité des décisions de planification, tandis que Claude prend en charge la majorité de l’exécution. En d’autres termes, l’IA prend en charge la rédaction de code, la modification de fichiers, l’exécution de commandes, le débogage, etc., mais la définition des objectifs et l’évaluation des résultats restent dépendantes de l’humain.

Plus important encore, l’efficacité de l’utilisation de Claude Code ne dépend pas uniquement du fait que l’utilisateur soit programmeur. Le rapport montre que, dans les tâches de génération de code, la réussite des utilisateurs issus de professions non techniques telles que le droit, la finance, la gestion ou la recherche scientifique est désormais proche de celle des ingénieurs logiciels. Ce qui influence réellement le résultat, c’est la compréhension par l’utilisateur du problème à résoudre.

Cela signifie que la programmation IA réduit la barrière à l’entrée pour la réalisation, mais pas pour le jugement. À l’avenir, ceux qui comprennent le métier, le contexte, et peuvent clairement formuler leurs besoins et juger des résultats, pourraient être plus aptes à exploiter l’IA que ceux qui savent simplement coder. L’IA ne remplacera pas automatiquement la connaissance du domaine, mais amplifie plutôt la valeur de cette connaissance.

Voici le texte original :

Découvertes clés

Sur la base de recherches antérieures, nous proposons un cadre pour étudier la programmation d’agents intelligents interactifs. Ce cadre repose sur une analyse de la protection de la vie privée lors d’environ 400 000 sessions avec Claude Code, entre octobre 2025 et avril 2026, pour évaluer la composition des tâches, la collaboration entre humains et IA, ainsi que le taux de réussite des tâches.

Dans une session typique, l’humain est responsable de la majorité des décisions de planification, c’est-à-dire décider « quoi faire » ; Claude est responsable de la majorité des décisions d’exécution, c’est-à-dire comment faire. Plus la connaissance de l’utilisateur dans un domaine est forte, plus chaque instruction déclenche de travaux réalisés par Claude. Dans les tâches de codage, le taux de réussite moyen — c’est-à-dire la proportion de cas où l’utilisateur a obtenu ce qu’il voulait, avec des preuves vérifiables comme des tests ou des soumissions de code — est presque aussi élevé que celui des ingénieurs logiciels.

Plus la compétence dans le domaine est forte, plus la session tend à réussir. Cependant, la différence entre utilisateurs intermédiaires et experts n’est pas grande. Sur sept mois d’observation, la proportion de sessions utilisées pour le débogage a presque été divisée par deux, tandis que l’usage s’est orienté vers des méthodes plus bout en bout : déploiement et exécution de code, analyse de données, rédaction de documents non code.

Au cours de ces sept mois, la valeur des tâches typiques a augmenté dans presque tous les types de travail. En la comparant aux offres d’emploi en freelance, on estime que la valeur moyenne a augmenté d’environ 25 %.

Introduction

La programmation par agent intelligent connaît une croissance rapide. Depuis la fin 2025, la proportion de projets sur GitHub impliquant des agents de codage a plus que doublé, et les utilisateurs de Claude Code l’utilisent en moyenne 20 heures par semaine. Peut-on, sans expérience formelle en programmation, diriger avec succès un agent pour réaliser des tâches techniques complexes ? Comment cette adoption rapide et cette montée en capacité influenceront-elles le travail de connaissance plus large ? Nous n’avons pas encore de réponse complète, mais quelques signaux précoces apparaissent dans les données d’utilisation de Claude Code.

Ce rapport s’appuie sur une analyse de la protection de la vie privée lors d’environ 235 000 utilisateurs et 400 000 sessions interactives, entre octobre 2025 et avril 2026, pour fournir des preuves sur la façon dont Claude Code est réellement utilisé. Il poursuit nos travaux précédents sur l’autonomie dans les sessions Claude Code, ainsi que sur la manière dont Claude Code modifie le fonctionnement interne d’Anthropic. Nous proposons un cadre pour décrire l’utilisation d’assistants IA interactifs : ce que les gens font, qui le fait, et si cela aboutit à un résultat réussi. Nous nous concentrons sur l’utilisation de Claude Code via l’interface en ligne de commande (CLI), Claude.ai ou l’application de bureau Claude Code. En suivant comment l’usage de la programmation d’agents évolue avec l’amélioration des capacités du modèle, nous pouvons mieux comprendre l’impact de ces outils sur les professionnels de la programmation et le marché du travail du savoir.

Ce qui se passe avec Claude Code pourrait annoncer l’avenir du travail de connaissance : les agents seront progressivement intégrés dans des tâches non codantes. Nous constatons que Claude traite des tâches plus complexes et plus précieuses. En même temps, la division claire du travail dans la programmation d’agents persiste : l’humain décide de ce qui doit être construit, l’agent décide comment le construire.

Nous voyons aussi que la véritable amplification de l’efficacité des outils repose sur la connaissance du domaine, et non sur la maîtrise de la programmation. En particulier, les experts de domaine ont plus de succès, et récupèrent plus facilement d’erreurs ou de malentendus. Cependant, la différence entre utilisateurs intermédiaires et experts n’est pas grande. Cela indique qu’avec une compétence suffisante dans un domaine, on peut utiliser ces outils aussi efficacement qu’un spécialiste.

Ces découvertes nous permettent d’esquisser une transformation potentielle du marché du travail. Nos données montrent que la réussite dépend de la compréhension du problème par l’utilisateur, et non de sa formation en programmation. Si ce modèle se généralise, cela signifie que, bien que la programmation d’agents absorbe une partie du travail orienté réalisation, elle récompense aussi ceux qui comprennent vraiment leur problème. La programmation d’agents ne remplace pas la connaissance du domaine. Au contraire, plus un travailleur comprend son domaine, plus il pourra produire un travail de haute qualité avec l’agent.

Division du travail

Ce que font les gens avec Claude Code

Pour comprendre qui fait quoi, nous classons chaque session dans l’un des neuf modes de travail qui décrivent le mieux l’objectif de la session. Quatre de ces modes concernent directement la rédaction ou la maintenance de code : construire quelque chose de nouveau, réparer quelque chose de cassé, tester du code, ou orchestrer d’autres agents ou pipelines automatisés. Une autre catégorie concerne l’opération logicielle : déploiement, configuration, exécution de pipelines, surveillance. Deux autres modes concernent plutôt la compréhension du « quoi faire » : comprendre le fonctionnement d’un système existant, ou planifier des changements avant de commencer. Enfin, deux modes sont hors code ou utilisent le code comme support : analyser des données, ou communiquer via des présentations ou autres documents textuels.

Environ 56 % des sessions consistent en écriture de code (25 %), réparation de code (26 %), ou test et orchestration de code (5 %). L’opération logicielle représente 17 %, la planification ou exploration 14 %, l’analyse ou la rédaction de texte 13 % (voir figure 1).

> Figure 1 : Les neuf modes de travail. Chaque session interactive est classée selon le mode qui décrit le mieux son objectif.

Nous faisons d’abord lire la session par le modèle, puis la classons. Ensuite, nous utilisons notre outil d’analyse de confidentialité pour croiser ces classifications avec les données télémétriques enregistrées automatiquement lors de chaque session, notamment si du code a été ajouté ou supprimé. La cohérence entre ces deux sources est élevée. Par exemple, dans les sessions où notre classificateur indique la création ou la modification de code, plus de 90 % montrent aussi dans la télémétrie des changements de code. Voir l’annexe pour plus de détails.

Qui décide ?

Quelle est la autonomie de Claude Code ? Les évaluations de capacité montrent que son potentiel est déjà élevé et continue de croître. Par exemple, dans des benchmarks comme METR, les modèles de pointe peuvent désormais réaliser de façon autonome des tâches logicielles qui nécessitaient auparavant plusieurs heures d’un humain, en surmontant eux-mêmes certains obstacles. Mais qu’en est-il dans la pratique ? Ici, nous analysons la part de guidage que l’humain et Claude prennent dans de véritables sessions.

Nous abordons cette question sous deux angles. D’abord, dans quelle mesure les utilisateurs délèguent-ils la décision à Claude ? Ensuite, combien d’actions les utilisateurs confient-ils à Claude ? Pour comprendre cette division, nous avons construit un classificateur d’attribution décisionnelle, respectant la vie privée, qui identifie toutes les décisions significatives dans une session. Ces décisions sont réparties en décisions de planification (quoi faire, comment faire, quand considérer la tâche terminée) et décisions d’exécution (quels fichiers modifier, quel code écrire, dans quelle langue, quelles commandes exécuter). Le classificateur attribue chaque décision à Claude ou à l’utilisateur, et génère deux chiffres par session : la proportion de décisions de planification assumées par l’utilisateur, et celle de décisions d’exécution.

En moyenne, l’humain prend environ 70 % des décisions de planification, mais seulement 20 % des décisions d’exécution (voir figure 2). Dans la pratique, la division claire du travail se confirme : l’humain décide « quoi faire », l’agent décide « comment faire ».

Pour comprendre le degré de délégation des actions dans une session, nous ne regardons pas le contenu, mais la structure. Une session Claude Code consiste en une série d’échanges : l’utilisateur envoie une invite, Claude agit ; puis l’utilisateur envoie une nouvelle invite, etc. En session typique, il y a environ quatre tours. Sur nos données d’octobre à avril, chaque invite de l’utilisateur déclenche en moyenne une dizaine d’actions de Claude, pouvant parfois dépasser 100. À chaque tour, Claude lit des fichiers, modifie du code, exécute des commandes, et produit en moyenne 2400 mots.

La quantité de travail accomplie par Claude entre deux vérifications par l’utilisateur dépend beaucoup de qui décide. Quand l’utilisateur garde le contrôle de l’exécution — c’est-à-dire qu’il prend plus de 80 % des décisions d’exécution —, Claude effectue moins d’actions, environ 8 par tour. Quand Claude contrôle la planification — plus de 80 % des décisions de planification —, il effectue jusqu’à 16 actions par tour.

> Figure 2 : Part de Claude dans la planification et l’exécution. La figure montre la répartition des sessions où la planification (quoi faire) et l’exécution (comment faire) sont attribuées à Claude ou à l’utilisateur. En session typique, l’utilisateur prend environ 70 % des décisions de planification, tandis que Claude assume environ 80 % des décisions d’exécution.

Niveau professionnel

Selon chaque session, Claude évalue le niveau d’expertise apparent de l’utilisateur sur une échelle de cinq niveaux, du débutant à l’expert. Le classificateur de compétence se base sur trois signaux : la précision des instructions de l’utilisateur, ce que l’utilisateur demande à Claude de vérifier, et si l’utilisateur corrige souvent Claude ou si c’est l’inverse. Il est important de noter que ce niveau professionnel est totalement distinct du poste ou de la capacité générale, et qu’il est spécifique à la tâche. Un ingénieur expérimenté posant une question sur Rust, par exemple, peut rester débutant sur cette tâche, tandis qu’un comptable n’ayant jamais utilisé Python peut devenir un expert dans une tâche précise, s’il peut expliquer à Claude les règles de réconciliation à appliquer dans un script.

Le tableau ci-dessous montre comment nous définissons ces niveaux dans le classificateur, avec un exemple de requête tiré du dataset public SWE-chat. Les conversations classées comme « débutant » donnent des instructions vagues, sans connaissance spécifique du domaine ; celles classées comme « expert » montrent une compréhension approfondie du code et de l’environnement technique.

> Tableau 1 : Classificateur de niveau professionnel. Des exemples de conversations réelles, anonymisées et condensées, annotées par notre classificateur. Beaucoup proviennent du dataset public SWE-chat.

Nous avons quantifié la relation entre le niveau professionnel et la quantité d’actions et de texte générés par Claude par prompt. En session typique de débutant, chaque prompt déclenche environ 5 actions et produit environ 600 mots ; en session d’expert, la chaîne d’actions est plus longue, environ 12 actions, et la sortie atteint environ 3200 mots, soit cinq fois plus (voir figure 3). La différence entre débutant et expert apparaît dans tous les types de tâches et toutes les plages de valeur.

Ces indicateurs complètent nos travaux antérieurs sur l’autonomie de Claude Code. La recherche précédente suivait la durée d’utilisation de l’agent et la fréquence à laquelle l’utilisateur approuvait ses actions automatiquement. Ici, nos mesures d’attribution décisionnelle captent qui prend les décisions substantielles dans la session, tandis que le nombre d’actions et la quantité de sortie par prompt mesurent dans quelle mesure chaque instruction humaine peut entraîner une activité autonome de Claude.

> Figure 3 : Plus l’utilisateur est professionnel, plus Claude accomplit de travail par prompt. Plus le niveau professionnel est élevé, plus le nombre d’actions (barres à gauche) et la quantité de texte (barres à droite) par prompt augmentent. La boîte indique l’intervalle interquartile, la ligne médiane la valeur centrale. Les moustaches s’étendent du 5e au 95e percentile. Le point blanc est la moyenne géométrique. Les deux tendances sont statistiquement significatives (p < 0,001), et chaque étape de progression entre niveaux professionnels l’est aussi. En contrôlant pour le mode de travail, la valeur de la tâche, le mois, la profession et la série de modèles, et en clusterisant par utilisateur, cette tendance reste significative : chaque niveau supérieur augmente de 9 % le nombre d’actions, et de 13 % la quantité de texte.

Qui utilise Claude Code, et pour quoi faire

Utilisateurs

Pour comprendre qui fait quoi, nous inférons la profession de chaque utilisateur à partir des sessions, puis la classons dans l’un des 23 grands groupes de la classification SOC de l’US Bureau of Labor Statistics. Le classificateur ne se base que sur certains signaux : le contexte chargé au début de la session, le nom et la structure des fichiers, les références à des documents ou produits (contrats, données cliniques, rapports financiers, supports de cours, etc.), et le vocabulaire utilisé. Il est explicitement demandé de ne pas considérer « écrire du code » comme une preuve de profession en programmation. La seule condition pour classer une session dans une catégorie liée à la programmation est la présence claire d’un travail logiciel ou de traitement de données. Par exemple, si un avocat construit un script pour vérifier automatiquement l’absence de clauses dans un contrat, cette session sera classée dans la catégorie juridique, même si elle consiste principalement à écrire du logiciel. Si aucun signal ne permet de déterminer la profession, la session n’est pas classée.

Nous pouvons inférer la profession dans environ 70 % des sessions. Parmi celles-ci, la plus grande catégorie est « Professionnels de l’informatique et des mathématiques », ce qui n’est pas surprenant, car cette catégorie couvre la majorité des travaux liés au logiciel. Viennent ensuite les opérations commerciales et financières, la conception artistique et les médias, la gestion, ainsi que les sciences de la vie, la physique et les sciences sociales. Parmi les groupes professionnels non liés au logiciel, ceux qui croissent le plus rapidement sont la gestion, la vente et le droit.

Travail

De octobre 2025 à avril 2026, la composition des tâches réalisées avec Claude Code a changé de façon notable. La baisse la plus marquante concerne les sessions de réparation de code cassé, qui passent de 33 % à 19 % (voir figure 4). À l’inverse, les tâches liées à l’opération logicielle ont augmenté, passant de 14 % à 21 %. La rédaction et l’analyse de données ont presque doublé, passant d’environ 10 % à 20 %.

La valeur économique des tâches a aussi augmenté. En estimant le coût de travaux similaires sur le marché freelance, calibré avec des données réelles d’offres d’emploi, on voit que la valeur moyenne par session a augmenté de 27 % entre octobre et avril. Cette hausse concerne plusieurs types de tâches : construction, opération et réparation, avec des augmentations respectives d’environ 43 %, 34 % et 32 %. Ces estimations sont grossières, et servent surtout à comparer l’évolution relative des tâches dans le temps, plutôt qu’à donner une valeur en dollars directement exploitable. Pour plus de détails sur la méthode de construction de ces estimations, voir l’annexe.

> Figure 4 : Évolution de la composition et de la valeur des tâches avec Claude Code d’octobre 2025 à avril 2026. La figure montre la part de chaque mode de travail dans les sessions sur sept mois. La part de réparation de code cassé diminue de 33 % à 19 %, tandis que l’opération logicielle, l’analyse de données et la rédaction de documents augmentent.

La réussite dépend de ce que l’utilisateur apporte

Estimer la valeur des tâches est une façon de comprendre comment Claude Code aide à réaliser du travail. Un autre angle est d’observer combien de sessions réussissent, et quels traits de session sont liés à la réussite. Dans tous les indicateurs de succès, un schéma clair apparaît : plus le niveau professionnel de l’utilisateur est élevé, plus la session a de chances de réussir. La majorité de cette différence se concentre entre débutant et intermédiaire, la différence entre intermédiaire et expert étant plus faible.

Avant d’analyser les caractéristiques des sessions réussies, il faut définir précisément ce qu’est une réussite. Nous ne pouvons pas voir les résultats dans le monde réel, ni demander directement aux utilisateurs s’ils ont accompli leur objectif. Nous utilisons donc deux méthodes complémentaires, basées sur l’analyse des sessions. La première, « succès déterminé », consiste à faire lire la session par un classificateur, qui juge si l’utilisateur a atteint son objectif initial : succès, succès partiel, échec, ou objectif non clair. Deux autres classificateurs évaluent la force de cette conclusion, en cherchant des preuves vérifiables de succès, comme des commits, des pull requests, la réussite de tests, ou une approbation explicite de l’utilisateur. Ces preuves sont notées de 1 (aucun signal) à 5 (plusieurs signaux forts). Un succès vérifié nécessite que la session soit jugée réussie, et qu’au moins un signal fort soit présent. La seconde méthode évalue les signaux d’échec, comme erreurs, échecs de tests, tentatives répétées, ou opposition de l’utilisateur. La réussite vérifiée exige que la session soit jugée réussie, et qu’au moins un signal fort d’échec soit absent. Nous analysons ici le degré de succès ou d’échec, en excluant les sessions sans objectif clair, qui représentent environ 7,7 % de l’échantillon.

Retour sur le niveau professionnel

Quels sont les sessions les plus susceptibles de réussir ? Les résultats montrent que le score de niveau professionnel a une forte influence sur la réussite.

Certains pourraient craindre que ce ne soit pas le vrai moteur, mais simplement une corrélation avec d’autres facteurs. Pour répondre, nous comparons des sessions du même type de tâche, avec la même valeur estimée, le même mois, le même sujet, et provenant du même groupe professionnel. Cela permet d’isoler l’effet du niveau professionnel.

> Tableau 2 : Définition de la réussite et de l’échec par le classificateur. Exemples issus du dataset public SWE-chat, anonymisés et condensés, annotés par notre classificateur.

Dans tous les indicateurs, plus le niveau professionnel est élevé, plus la session a de chances de réussir. Les sessions classées « débutant » ont un taux de succès vérifié de 15 % selon notre critère le plus strict, et 77 % au moins partiellement. Les sessions intermédiaires ou supérieures ont un taux de succès vérifié entre 28 % et 33 %, et un taux de succès partiel entre 91 % et 92 % (voir figure 5).

Dans chaque indicateur, la majorité des gains provient de la progression du débutant à l’intermédiaire ; la différence entre intermédiaire et expert est plus faible. Les détails de la régression derrière la figure 5 sont dans l’annexe.

> Figure 5 : Niveau professionnel et résultats de session. La figure montre, selon le score de professionnalisme, la proportion de sessions réussies ou échouées, en classant par niveau de débutant à expert. La gauche inclut toutes les sessions. La centrale et la droite ne concernent que celles où un problème a été rencontré (signal d’échec > 3), et montrent la proportion de ces sessions qui ont finalement réussi ou échoué selon différentes définitions. Chaque point est une proportion ajustée. La comparaison se fait en ne tenant compte que des sessions du même mode de travail, de la même valeur de tâche, du même mois, du même sujet, et du même groupe professionnel (par exemple, métier lié au logiciel). Les détails de la régression sont dans l’annexe. Les barres d’erreur indiquent l’intervalle de confiance à 95 %, souvent trop petit pour être visible.

Même dans les sessions où un défi est rencontré, on observe une tendance similaire. Quand un échec vérifié est enregistré — erreurs, échecs de tests, tentatives multiples, ou frustration exprimée —, la proportion de succès vérifié passe de 4 % chez les débutants à 15 % chez les experts (voir figure 5). Avec des critères plus souples, la part de succès partiel est de 60 % chez les débutants, et de 80-81 % chez les intermédiaires et experts.

Nous avons aussi examiné la relation inverse : le niveau professionnel et certains indicateurs d’échec. Notons que, dans cette analyse, une session échouée est une session où aucun succès même partiel n’a été atteint. Si une session problématique est aussi abandonnée — c’est-à-dire sans aucune ligne de code écrite —, elle est considérée comme abandonnée. Chez les débutants, 19 % de ces sessions sont abandonnées, contre 5 à 7 % pour d’autres groupes. En résumé, les utilisateurs avec moins d’expérience abandonnent plus souvent lorsqu’ils rencontrent des difficultés. La maîtrise du domaine semble donc aussi valorisée par la capacité à ramener l’agent dans la bonne direction.

La profession pourrait être moins importante que le niveau professionnel

Les utilisateurs issus de professions liées au logiciel ont un taux de succès vérifié d’environ 30 %, contre 26 % pour les autres. Dans les sessions où du code est généré, c’est-à-dire au moins une ligne ajoutée ou modifiée, ces chiffres sont respectivement de 34 % et 29 % (voir figure 6). Avec des critères plus souples, la différence entre ces groupes diminue encore. La proportion de succès partiel dans ces sessions est de 89 % pour les professionnels du logiciel, et 88 % pour les autres. La différence de cinq points de pourcentage est stable sur sept mois, sans s’accroître ni diminuer, même si les taux de succès augmentent pour tous. Dans les dix plus grands groupes professionnels de notre dataset, la différence avec les ingénieurs logiciels ne dépasse pas sept points de pourcentage. La gestion a le taux de succès vérifié le plus élevé, légèrement supérieur à celui des professionnels du logiciel. Cela pourrait refléter le transfert de compétences en gestion vers la direction d’agents, ou simplement la façon dont la vérification est effectuée, souvent par confirmation explicite de l’utilisateur, qui pourrait être plus à l’aise pour exprimer ses attentes.

> Figure 6 : Taux de succès et d’échec dans les sessions de codage, selon la profession inférée. La figure montre, pour les sessions avec au moins une ligne de code modifiée ou ajoutée, la proportion de succès selon la définition stricte, par groupe professionnel. Les dix plus grands groupes sont représentés. La différence avec la catégorie « Professionnels en informatique et mathématiques » (SOC) est inférieure à sept points de pourcentage. Les barres d’erreur indiquent l’intervalle de confiance à 95 % basé sur différents comptes.

Perspectives

Les résultats de ce rapport esquissent un tableau en train de se former : la programmation par agent amplifie certains savoirs et compétences, tout en en remplaçant d’autres. Dans les sessions de génération de code, la réussite des principales professions est proche de celle des professionnels en informatique. Il semble que la capacité à coder ne soit plus une condition essentielle pour réussir.

Par ailleurs, la réussite est plus souvent associée à la connaissance du domaine. Les sessions d’experts ont un taux de succès vérifié deux fois supérieur à celui des débutants. Lorsqu’un problème survient, la proportion de débutants qui abandonnent est plusieurs fois plus élevée. La collaboration elle-même clarifie cette image : les experts de domaine peuvent guider Claude avec chaque instruction pour réaliser davantage de travaux. La capacité à amener Claude vers la réussite dépend donc davantage de la maîtrise du domaine que de la maîtrise du code. Toute personne ayant une bonne compréhension opérationnelle d’un domaine peut désormais réaliser des tâches techniques autrefois hors de portée. Ceux qui manquent de cette compréhension, même avec le même outil, en tireront beaucoup moins. La majorité des bénéfices provient de la compétence, pas de la maîtrise approfondie. Avoir une compréhension opérationnelle d’un domaine suffit pour en tirer la majorité des gains ; la spécialisation approfondie n’apporte qu’un avantage marginal supplémentaire.

Ces découvertes restent préliminaires. Comme dans la plupart de nos études, nous ne pouvons mesurer les résultats concrets dans le monde réel, comme si le code généré a été utilisé ou abandonné, ou s’il a produit une valeur économique. De plus, ce rapport exclut l’usage non interactif, qui constitue une part importante de l’activité. Développer un cadre pour mesurer ce type d’usage sera une étape clé pour l’avenir. Toutes nos classifications reposent aussi sur la lecture des sessions par le modèle. Dans l’annexe, nous montrons que le classificateur reste cohérent avec des données télémétriques indépendantes, et qu’il est généralement en accord avec une évaluation humaine de référence. Cependant, dans des scénarios à grande échelle, la validation du classificateur reste difficile ; les sessions de Claude Code étant souvent longues et complexes, il est difficile de faire une annotation humaine de référence.

À mesure que modèles, utilisateurs, et division du travail évoluent, le tableau présenté ici continuera de se modifier. Nous espérons que ces indicateurs nous aideront à suivre ces transformations majeures. Par exemple, si à l’avenir le retour sur investissement du niveau professionnel diminue, cela indiquerait que le modèle commence à fournir aux utilisateurs des jugements clés, et que ses bénéfices s’étendent au-delà des experts pour toucher un public plus large. Si la proportion d’utilisateurs hors du secteur logiciel réussissant leurs sessions de codage continue d’augmenter, cela pourrait signifier que la production logicielle devient une activité courante dans tous les secteurs, et plus seulement une spécialité. Ces changements influenceront qui pourra bénéficier de la programmation par agent, et dans quelle mesure, impactant ainsi les compétences les plus valorisées sur le marché du travail.