> Titre original : Agentic coding and persistent returns to expertise
> Auteur original : Anthropoic
> Traduction : Peggy
>

Note de l’éditeur : Ce rapport est basé sur environ 400 000 sessions avec Claude Code, et discute de la manière dont les outils de programmation IA changent la relation entre l’homme et le code.

La découverte la plus centrale est : dans la programmation par agent intelligent, l’humain décide principalement « quoi faire », tandis que Claude est responsable de « comment faire ». L’utilisateur assume la majorité des décisions de planification, tandis que Claude prend en charge la majeure partie 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 ou non. Le rapport montre que, pour 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 le seuil d’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, seront peut-être plus aptes à utiliser efficacement 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 existantes, nous proposons un cadre pour étudier la programmation interactive par agent intelligent. Ce cadre repose sur une analyse de la protection de la vie privée lors d’environ 400 000 sessions Claude Code entre octobre 2025 et avril 2026, évaluant 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 la quantité de travail que Claude doit effectuer suite à chaque instruction est grande. Dans les tâches de codage, le taux de réussite moyen — c’est-à-dire la proportion de tâches où l’utilisateur obtient ce qu’il voulait, avec des preuves vérifiables comme des tests ou des soumissions de code — est presque équivalent à celui des ingénieurs logiciels.

Plus la compétence de l’utilisateur dans le domaine est élevée, plus la session tend à réussir. Cependant, la différence entre un utilisateur intermédiaire et un expert n’est pas très grande. Au cours des sept mois observés, la proportion de sessions utilisées pour le débogage a presque été divisée par deux, et la méthode d’utilisation s’est tournée vers des usages 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 presque augmenté dans tous les types de travail. En la comparant aux annonces de postes en freelance, nous estimons 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 d’activités d’agents de codage dans les projets GitHub a doublé, et les utilisateurs de Claude Code l’utilisent en moyenne 20 heures par semaine. Peut-on réussir à diriger un agent complexe sans expérience formelle en programmation ? Comment cette adoption rapide et cette montée en capacité influenceront-elles le travail intellectuel 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, basé sur une analyse de la vie privée de 235 000 utilisateurs et 400 000 sessions interactives entre octobre 2025 et avril 2026, fournit des preuves concrètes de l’usage réel de Claude Code. Il poursuit nos recherches antérieures 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 fait quoi, et si le travail est 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 par agent é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 intellectuel : les agents s’intègrent progressivement dans des tâches non codantes. Nous constatons que Claude traite des tâches plus complexes et plus précieuses. Par ailleurs, la division claire du travail dans la programmation par agent persiste : l’humain décide ce qu’il faut construire, l’agent décide comment le construire.

Nous voyons aussi des preuves que la véritable amplification de l’efficacité des outils provient de la connaissance du domaine, et non de la maîtrise de la programmation. En particulier, les experts de domaine réussissent plus facilement, et récupèrent plus vite d’erreurs ou de malentendus. Cependant, la différence entre un utilisateur intermédiaire et un expert n’est pas très 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 les transformations possibles du marché du travail. Dans nos données, la réussite dépend de la compréhension du problème par l’individu, et non de sa formation en programmation. Si ces modèles se généralisent, cela signifie que, bien que la programmation par agent puisse absorber certains travaux orientés réalisation, elle récompense aussi ceux qui comprennent réellement 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 ces outils.

Division du travail

Ce que font les gens avec Claude Code

Pour comprendre comment les gens utilisent Claude Code, nous classons chaque session dans l’un des neuf modes de travail, celui qui décrit 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, orchestrer d’autres agents ou pipelines automatisés. Une autre catégorie concerne l’opération de logiciels : déploiement, configuration, exécution de pipelines, surveillance. Deux autres modes visent à clarifier « ce qu’il faut faire » : comprendre le fonctionnement d’un système existant, ou planifier des changements avant de commencer à agir. Enfin, deux modes ne concernent pas le code ou ne l’utilisent qu’en support : analyser des données, 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 %). La manipulation de logiciels représente 17 %, la planification ou exploration 14 %, l’analyse ou la rédaction de textes 13 % (voir figure 1).

> Figure 1 : 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, à l’aide de notre outil d’analyse de la vie privée, nous croisons ces classifications avec les données télémétriques enregistrées automatiquement, notamment si du code a été ajouté ou supprimé. La cohérence entre ces deux sources est très élevée. Par exemple, dans les sessions classées par notre classificateur comme créant ou modifiant du code, plus de 90 % montrent aussi des changements de code dans les données télémétriques. Voir l’annexe pour plus de détails.

Qui décide quoi ?

Quelle est la autonomie de Claude Code ? Les évaluations de ses capacités montrent qu’elle est déjà très avancée, et continue de progresser. Par exemple, dans des benchmarks comme METR, les modèles de pointe peuvent désormais réaliser de manière autonome des tâches logicielles qui prenaient auparavant plusieurs heures à un humain, en surmontant eux-mêmes certains obstacles. Mais qu’en est-il dans la pratique ? Ici, nous étudions la part de guidage que prennent réellement l’humain et Claude dans une session.

Nous abordons cette question sous deux angles. D’abord, dans quelle mesure les utilisateurs confient-ils leurs décisions à Claude ? Ensuite, combien d’actions les utilisateurs délèguent-ils à Claude ? Pour comprendre cette division, nous avons construit un classificateur d’attribution décisionnelle, basé sur le contenu de la session. Il liste toutes les décisions importantes, et les classe en décisions de planification (quoi faire, comment faire, quand considérer la tâche comme terminée) ou 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 pour chaque session deux chiffres : la proportion de décisions de planification et d’exécution assumées par l’utilisateur.

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 programmation par agent montre une division claire du travail : l’humain décide ce qu’il faut construire, l’agent décide comment le faire.

Pour comprendre le degré de délégation des actions dans une session, nous ne regardons pas le contenu, mais la structure de la session. Une session Claude Code consiste en une série d’échanges entre Claude et l’utilisateur : l’utilisateur envoie une invite, Claude agit ; puis l’utilisateur envoie une nouvelle invite, etc. En session typique, il y a environ quatre tours. Dans 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 2 400 mots.

La quantité de travail que Claude accomplit entre deux vérifications par l’utilisateur dépend largement 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 par tour, environ 8. Quand Claude contrôle la planification — plus de 80 % des décisions de planification —, le nombre d’actions qu’il effectue est maximal, environ 16.

> Figure 2 : Proportion de décisions de planification et d’exécution attribuées à Claude. La figure montre la répartition dans différentes sessions, entre décisions de planification (quoi faire) et d’exécution (comment faire), 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 apparent de compétence de l’utilisateur sur la tâche, sur une échelle de cinq niveaux, du débutant à l’expert. Le classificateur de compétence se concentre 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 à chaque tâche. Par exemple, un ingénieur expérimenté qui pose une question sur Rust peut encore être un débutant dans cette tâche ; un comptable qui n’a jamais utilisé Python peut devenir un expert dans une tâche spécifique s’il peut expliquer précisément à Claude quelles règles de réconciliation doivent être appliquées dans un script Python, et repérer les erreurs lors de la clôture mensuelle.

Le tableau ci-dessous montre comment nous définissons chaque niveau dans le classificateur, avec des exemples issus du dataset public SWE-chat. Les conversations classées comme « débutant » contiennent 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. Exemples de conversations réelles, modifiées, anonymisées et compressées, annotées par notre classificateur. Plusieurs exemples proviennent du dataset public SWE-chat.

Nous avons quantifié la relation entre le niveau professionnel et le nombre d’actions et de mots générés par Claude par instruction. En session typique de débutant, chaque instruction déclenche environ 5 actions de Claude, avec une sortie d’environ 600 mots ; en session d’expert, la longueur de la chaîne d’actions dépasse le double, avec environ 12 actions, et une sortie d’environ 3 200 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 de travail.

Ces indicateurs complètent nos recherches précédentes sur l’autonomie de Claude Code. La précédente étude suivait la durée de fonctionnement de l’agent, et la fréquence à laquelle l’utilisateur approuvait ses actions automatiquement. En revanche, nos indicateurs d’attribution décisionnelle captent qui prend des décisions substantielles dans toute la session, tandis que le nombre d’actions et de mots déclenchés par instruction mesure la capacité de l’humain à provoquer une activité autonome de Claude.

> Figure 3 : Face à des utilisateurs plus professionnels, Claude accomplit plus de travail par instruction. Plus le niveau professionnel est élevé, plus le nombre d’actions (barres à gauche) et la quantité de texte générée (barres à droite) par instruction augmentent. La boîte indique l’intervalle interquartile, la ligne médiane la valeur médiane. Les moustaches s’étendent du 5e au 95e percentile. Le point blanc représente la moyenne géométrique. Les deux tendances sont statistiquement significatives (p < 0,001), et chaque étape de niveau professionnel montre une différence également significative. 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 utilisant une erreur standard regroupée par utilisateur, cette tendance reste significative : chaque niveau supérieur augmente le nombre d’actions de 9 %, et la quantité de texte de 13 %.

Qui utilise Claude Code, et pour quoi ?

Utilisateurs

Pour comprendre qui fait ces travaux, nous inférons la profession de chaque utilisateur à partir des sessions, puis la classons selon 23 catégories principales du système SOC (Standard Occupational Classification) des États-Unis. 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 ou documents cités par l’utilisateur (documents juridiques, 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 données. Par exemple, si un avocat construit un script pour vérifier automatiquement l’absence de clauses dans un contrat, même si la session concerne principalement la rédaction de code, elle sera classée dans la catégorie juridique. Si aucun signal ne permet d’identifier la profession, la session n’est pas classée.

Nous pouvons inférer la profession dans environ 70 % des sessions. Parmi celles-ci, la catégorie « professions liées à l’informatique et aux mathématiques » est la plus grande, ce qui n’est pas surprenant, car elle couvre la majorité des travaux liés au logiciel. Ensuite viennent les secteurs des affaires et de la finance, de l’art et des médias, de la gestion, ainsi que des sciences de la vie, de la physique et des sciences sociales. Parmi les groupes professionnels non liés au logiciel, ceux en croissance la plus rapide sont la gestion, la vente et le droit.

Travail

De octobre 2025 à avril 2026, la composition des travaux réalisés avec Claude Code a changé de façon significative. La baisse la plus notable concerne les sessions de réparation de code endommagé, qui passent de 33 % à 19 % (voir figure 4). À l’inverse, les travaux liés à la manipulation de code 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 également augmenté. En estimant le coût de travaux similaires sur le marché freelance, calibré avec des données réelles d’offres d’emploi, nous trouvons que la valeur moyenne par session a augmenté d’environ 27 % entre octobre 2025 et avril 2026. Cette hausse concerne plusieurs types de travaux : la construction, la manipulation et la réparation de code ont respectivement augmenté d’environ 43 %, 34 % et 32 %. Ces estimations de prix sont approximatives, et servent surtout à comparer l’évolution relative des tâches dans le temps, plutôt qu’à donner une valeur en dollars directement utilisable. Plus de détails sur la méthode de calcul sont dans l’annexe.

> Figure 4 : Évolution de la composition et de la valeur des travaux avec Claude Code entre octobre 2025 et avril 2026. La figure montre la répartition des modes de travail sur sept mois. La part des sessions de réparation de code endommagé est passée de 33 % à 19 %, tandis que celles de manipulation de logiciels, d’analyse de données et de rédaction de documents ont augmenté.

Ce que l’humain apporte pour réussir

Estimer la valeur d’une tâche est une façon d’appréhender comment Claude Code aide à réaliser le travail. Un autre aspect est d’observer combien de sessions réussissent, et quels traits de ces sessions sont liés à la réussite. Parmi 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 situe 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 la réussite. Nous ne pouvons pas observer directement les résultats dans le monde réel, ni demander aux utilisateurs s’ils ont accompli ce qu’ils voulaient. Nous utilisons donc deux méthodes complémentaires, basées sur l’analyse des sessions. La première, « succès vérifié », consiste à faire lire la session par un classificateur, qui juge si l’objectif initial a été atteint, partiellement ou non, ou si la session a échoué ou n’a pas d’objectif clair. Deux autres classificateurs évaluent la force de la preuve : un pour les preuves vérifiables de succès, notamment les activités git (commit, pull request, tests passés, validation explicite par l’utilisateur), et un pour les preuves d’échec (erreurs, échecs de tests, tentatives répétées, opposition de l’utilisateur). La réussite vérifiée exige que la session soit jugée réussie, et qu’au moins une preuve forte de succès soit présente. La preuve d’échec est aussi évaluée, notamment par la présence d’erreurs ou de tentatives infructueuses. La combinaison de ces deux évaluations permet de définir si la session est effectivement réussie ou non. Nous excluons de l’analyse les sessions jugées « sans objectif clair », qui représentent environ 7,7 % de l’échantillon.

Les bénéfices du niveau professionnel

Quels types de sessions ont le plus de chances de réussir ? Les résultats montrent que le score de compétence professionnel, tel que défini, a une forte influence.

Certains pourraient craindre que ce score ne soit qu’un reflet de la tâche ou d’autres facteurs. Dans cette section, nous comparons des sessions du même type de travail, avec la même valeur estimée, le même mois, le même sujet, et provenant de la même catégorie professionnelle, pour voir comment la compétence influence la réussite.

> Tableau 2 : Définition de la réussite et de l’échec par le classificateur. Exemples issus du dataset public SWE-chat, modifiés, anonymisés et compressé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 comme « débutant » ont un taux de réussite vérifiée de 15 %, et 77 % au moins partiellement réussies. Les sessions intermédiaires ou supérieures ont un taux de réussite vérifiée entre 28 % et 33 %, et un taux de réussite partielle 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 la session. La figure montre, selon le score de compétence, la répartition des résultats de session en cinq niveaux, du débutant à l’expert. La gauche montre toutes les sessions, la centrale et la droite ne montrent que celles où un problème a été rencontré, c’est-à-dire avec un score de signal d’échec supérieur à 3, et la proportion de sessions réussies ou échouées selon différentes définitions. Chaque point est une proportion ajustée. La comparaison est faite 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 type d’utilisateur (professionnel du logiciel ou non). Les détails de la régression sont dans l’annexe. Les barres d’erreur représentent un intervalle de confiance à 95 %, souvent trop petit pour être visible. Ces figures excluent les sessions classées comme « sans objectif clair ».

Même dans les sessions où des difficultés apparaissent, on observe une tendance similaire. Quand un signal d’échec vérifiable est présent, la proportion de sessions « rencontrant un problème » passe de 4 % chez les débutants à 15 % chez les experts (voir figure 5). Si l’on utilise une définition plus large de la réussite, la proportion de sessions partiellement réussies est de 60 % chez les débutants, et de 80-81 % chez les autres.

Nous avons aussi suivi une relation inverse : celle entre compétence et divers indicateurs d’échec. Il faut noter que, dans cette analyse, une session échouée est une session où aucune réussite partielle n’a été atteinte. Si une session problématique est jugée échouée, et qu’aucune ligne de code n’a été écrite, on parle de session abandonnée. Chez les débutants, 19 % de ces sessions sont abandonnées, contre 5 à 7 % pour les autres groupes. Autrement dit, les utilisateurs avec peu d’expérience abandonnent plus souvent lorsqu’ils rencontrent des difficultés. La capacité à ramener l’agent dans la bonne direction semble donc faire partie de la valeur du niveau professionnel.

Le métier est peut-être moins important que la compétence

Les utilisateurs issus de professions liées au logiciel ont un taux de réussite vérifiée 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 modifiée ou ajoutée, ces chiffres sont respectivement de 34 % et 29 % (voir figure 6). Avec une définition plus large de la réussite, la différence entre ces deux groupes se réduit encore. Dans ces sessions, la majorité des utilisateurs atteignent au moins une réussite partielle, à 89 % pour les professionnels du logiciel, et 88 % pour les autres. La différence de cinq points de pourcentage n’a pas varié en sept mois, ni en termes d’augmentation, ni de diminution. Dans notre échantillon, parmi les dix groupes professionnels les plus nombreux, la différence avec les ingénieurs logiciels ne dépasse pas sept points de pourcentage. La gestion affiche le taux de réussite vérifiée le plus élevé, légèrement supérieur à celui des professionnels du logiciel. La meilleure réussite vérifiée chez les gestionnaires pourrait refléter le transfert de compétences de gestion vers la direction d’agent, mais cela pourrait aussi venir de notre méthode de mesure : la validation dépend en partie de la confirmation explicite de l’utilisateur, qui est peut-être plus à l’aise pour exprimer ses attentes.

> Figure 6 : Taux de réussite 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 réussite selon la définition stricte, par profession principale. Les dix groupes professionnels les plus nombreux sont représentés. La différence avec les utilisateurs en informatique/mathématiques (SOC) est inférieure à sept points de pourcentage. Les barres d’erreur indiquent un intervalle de confiance à 95 %, calculé à partir de différentes estimations.

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 du logiciel. Il semble que la programmation d’agents rende moins crucial le fait d’avoir une formation en programmation pour réussir.

Par ailleurs, les sessions réussies montrent une plus grande présence de connaissances spécifiques au domaine. Les sessions d’expert ont un taux de réussite vérifiée deux fois supérieur à celui des débutants. Lorsqu’une session rencontre un problème, la proportion de débutants qui abandonnent est plusieurs fois plus élevée que celle des autres. La façon dont la collaboration fonctionne elle-même rend cette tendance plus claire : les experts de domaine peuvent guider Claude avec chaque instruction pour réaliser davantage de travail. La capacité à amener Claude vers la réussite dépend donc davantage de la maîtrise du domaine que de la capacité à coder. Toute personne maîtrisant un domaine peut désormais réaliser des travaux techniques auparavant impossibles. Ceux qui manquent de cette compréhension spécifique en tireront beaucoup moins de bénéfices, même avec les mêmes outils. Et la majorité des gains provient de la compétence, pas de la maîtrise totale. Avoir une compréhension opérationnelle d’un domaine suffit à obtenir la majorité des bénéfices ; la spécialisation approfondie n’apporte qu’un avantage marginal supplémentaire.

Ces découvertes restent encore préliminaires. Comme dans la plupart de nos recherches, il est difficile de mesurer les résultats dans le monde réel, par exemple 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’utilisation non interactive, qui constitue une part importante de l’activité totale. Développer un cadre pour mesurer ce type d’usage sera une priorité future. Toutes nos classifications reposent aussi sur la lecture des sessions par le modèle. Dans l’annexe, nous montrons que le classificateur est cohérent avec des données télémétriques indépendantes, et qu’il correspond dans la majorité des cas à une évaluation de référence. Mais, à grande échelle, la validation du classificateur reste difficile ; les sessions Claude Code étant souvent longues et complexes, il est difficile de faire une annotation manuelle comme référence.

À mesure que modèles, utilisateurs, et division du travail évoluent, le tableau présenté dans ce rapport continuera de se modifier. Nous espérons que ces indicateurs nous aideront à suivre ces transformations majeures. Par exemple, si à l’avenir la récompense liée au niveau professionnel commence à diminuer, cela indiquerait que le modèle fournit déjà des jugements clés que l’utilisateur aurait autrement apportés, et que ces outils profitent désormais à un public plus large que les experts. Si la proportion d’utilisateurs hors du secteur logiciel qui réussissent à compléter des sessions de codage continue d’augmenter, cela pourrait signifier que la production logicielle devient une activité courante dans tous les domaines, et ne reste plus l’apanage d’une seule profession. Ces changements modifieront qui peut bénéficier de la programmation par agent, et dans quelle mesure, influençant ainsi les compétences les plus valorisées sur le marché du travail.

[URL de l’article original]

Cliquez pour découvrir les offres d’emploi de BlockBeats

Rejoignez le groupe officiel de BlockBeats :
Telegram : https://t.me/theblockbeats
Groupe Telegram : https://t.me/BlockBeats_App
Compte officiel Twitter : https://twitter.com/BlockBeatsAsia