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

Note de l’éditeur : Ce rapport, basé sur environ 400 000 sessions avec Claude Code, 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 le faire ». L’utilisateur assume la majorité des décisions de planification, tandis que Claude prend en charge la majorité des tâches d’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, 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 abaisse le seuil de réalisation, mais pas celui de jugement. À l’avenir, ceux qui comprennent le métier, le contexte, et peuvent formuler clairement leurs besoins et juger des résultats, seront peut-être mieux à même d’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 antérieures, nous proposons un cadre pour étudier la programmation par agents interactifs. Ce cadre, basé 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, évalue 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 de « quoi faire » ; Claude est responsable de la majorité des décisions d’exécution, c’est-à-dire de « comment faire ». Plus la compétence de l’utilisateur dans un domaine est grande, plus la quantité de travail que Claude doit effectuer suite à chaque instruction est importante. Dans les tâches de codage, le taux de réussite moyen — c’est-à-dire la proportion de tâches où l’utilisateur a réussi à faire 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 de l’utilisateur dans le domaine est grande, plus la session a de chances de réussir. Cependant, la différence entre utilisateurs intermédiaires et experts 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 façon d’utiliser l’outil s’est orienté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 devient rapidement une tendance. Depuis la fin 2025, la proportion d’activités de programmation IA dans les projets GitHub a plus que 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é vont-elles influencer 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, basé 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, fournit des preuves concrètes sur l’utilisation réelle de Claude Code. Il poursuit nos recherches antérieures sur l’autonomie dans les sessions Claude Code, ainsi que sur la manière dont cette IA 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’utilisation de la programmation 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 de connaissance : les agents s’intègrent progressivement dans des tâches non codées. Nous constatons que Claude traite des tâches plus complexes et plus précieuses. Parallèlement, la division claire du travail dans la programmation par agent persiste : l’humain décide de ce qui doit être construit, 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 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 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 changements possibles sur le marché du travail. Dans nos données, la réussite dépend de la compréhension du problème à résoudre, et non de la formation en programmation. Si ces modèles se généralisent à l’économie, cela signifie que, bien qu’ils absorbent une partie du travail orienté réalisation, ils récompensent aussi ceux qui comprennent vraiment leur problème. La programmation IA ne remplace pas la connaissance du domaine. Au contraire, plus un travailleur comprend son domaine, plus il pourra produire un travail de qualité avec l’agent.

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, ou 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 concernent plutôt la compréhension du « quoi faire » : comprendre le fonctionnement d’un système existant, ou planifier des changements avant de commencer à modifier. Enfin, deux modes sont hors code ou utilisent le code comme support : analyser des données, ou communiquer via des présentations et autres documents textuels.

Environ 56 % des sessions concernent la rédaction de code (25 %), la réparation de code (26 %), ou le test et l’orchestration de code (5 %). La manipulation de logiciels représente 17 %, la planification ou exploration 14 %, et l’analyse ou la rédaction de textes 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 le transcript de la session par le modèle, puis le 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 lors de chaque session, notamment si des lignes de code ont été ajoutées ou supprimées. La cohérence entre ces deux sources est très élevée. Par exemple, dans les sessions classées comme création ou modification de 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 force de l’autonomie de Claude Code ? Les évaluations de ses capacités 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 prenaient auparavant des heures à un humain, en surmontant eux-mêmes certains obstacles. Mais qu’en est-il dans la pratique ? Ici, nous nous concentrons sur la répartition réelle des rôles entre humain et Claude lors des sessions.

Nous abordons cette question sous deux angles. D’abord, dans quelle mesure les utilisateurs confient-ils la décision à Claude ? Ensuite, combien d’actions donnent-ils à Claude d’exécuter ? Pour comprendre cette division, nous avons construit un classificateur d’attribution décisionnelle, basé sur le contenu de la session, qui identifie toutes les décisions importantes. Ces décisions sont classées en décisions de planification (quoi faire, comment faire, quand considérer qu’une tâche est 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 pour chaque session deux chiffres : 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 programmation par agent montre une division claire du travail : 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 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 beaucoup de qui décide. Quand l’utilisateur garde le contrôle de l’exécution — c’est-à-dire qu’il assume plus de 80 % des décisions d’exécution —, Claude effectue en moyenne 8 actions par tour. Quand Claude contrôle la planification — plus de 80 % des décisions de planification —, il effectue jusqu’à 16 actions.

> Figure 2 : Part des décisions de planification et d’exécution attribuées à Claude. La figure montre la répartition entre Claude et l’utilisateur dans différentes sessions, selon qu’il s’agisse de décisions de « quoi faire » ou « comment faire ». Dans une session typique, l’utilisateur assume environ 70 % des décisions de planification, tandis que Claude assume environ 80 % des décisions d’exécution.

Niveau de compétence

Selon chaque transcript, 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 plus souvent Claude ou vice versa. Il est important de noter que ce niveau de compétence est totalement distinct du poste ou de la capacité générale, et qu’il est spécifique à la tâche. Par exemple, un ingénieur expérimenté qui pose une question sur Rust peut encore être débutant dans cette tâche. Un comptable qui n’a jamais utilisé Python, mais peut indiquer précisément quelles règles de réconciliation doivent être appliquées dans un script Python, et repérer des erreurs lors de la clôture mensuelle, sera considéré comme expert pour cette tâche.

Le tableau ci-dessous montre comment nous définissons chaque niveau de compétence dans le classificateur, avec des exemples issus du dataset public SWE-chat, où les conversations ont été modifiées, anonymisées et compressées. Beaucoup d’exemples proviennent de SWE-chat, un dataset public de sessions de programmation IA.

> Tableau 1 : Classification du niveau de compétence. Des exemples de conversations réelles, modifiées, anonymisées et compressées, sont annotés par notre classificateur.

Nous quantifions la relation entre le niveau de compétence et le nombre d’actions ou de mots générés par Claude par prompt. Dans une session typique de débutant, chaque prompt déclenche environ 5 actions de Claude, avec une sortie d’environ 600 mots ; dans une 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.

Ces indicateurs complètent nos recherches précédentes sur l’autonomie de Claude Code. Auparavant, nous avions suivi la durée de fonctionnement de l’agent, ainsi que la fréquence à laquelle l’utilisateur approuvait automatiquement ses actions. En revanche, nos indicateurs d’attribution décisionnelle captent qui prend les décisions substantielles dans toute la session, tandis que le nombre d’actions ou de mots déclenchés par chaque prompt mesure dans quelle mesure chaque instruction humaine peut entraîner une activité autonome de Claude.

> Figure 3 : Plus le niveau de compétence est élevé, plus Claude accomplit de travail par prompt. Plus le niveau est élevé, plus le nombre d’actions (barres à gauche) et la quantité de texte généré (barres à droite) par prompt 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 est la moyenne géométrique. Les deux tendances à la hausse sont statistiquement significatives (p < 0,001), et chaque étape de niveau professionnel présente 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 agrégé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 ?

Les utilisateurs

Pour comprendre qui fait ces travaux, nous inférons la profession de chaque utilisateur à partir des transcripts, puis la classons selon l’un des 23 grands groupes de la classification 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 à 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 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 profession juridique, même si elle consiste principalement à écrire du logiciel. Si aucun signal ne permet d’identifier la profession, la session ne sera pas classée.

Nous pouvons inférer la profession dans environ 70 % des sessions. Parmi celles-ci, la majorité appartient à la catégorie « professions informatiques et mathématiques », ce qui n’est pas surprenant, car cette catégorie 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 qui croissent le plus rapidement sont la gestion, la vente et le droit.

Les types de 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 cassé, qui passent de 33 % à 19 % (voir figure 4). À l’inverse, les travaux liés à la manipulation de logiciels 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 de postes ouverts, nous estimons 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 étant approximatives, elles 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, voir l’annexe.

> Figure 4 : Évolution de la composition et de la valeur des travaux 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 proportion de sessions de réparation de code a diminué 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 au succès

Estimer la valeur des tâches est une façon de comprendre 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 nos indicateurs de succès, un schéma clair apparaît : plus le niveau de compétence apparent 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, ce qui indique que la différence entre ces deux niveaux est plus grande que celle entre intermédiaire et expert.

Avant d’analyser les caractéristiques des sessions réussies, il faut définir précisément ce qu’on entend par succès. 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 avec Claude. Nous utilisons donc deux méthodes complémentaires, basées sur l’analyse des transcripts. La première est une « évaluation de réussite » : après lecture complète de la session par un classificateur, celui-ci juge si l’utilisateur a atteint son objectif initial, avec des options : succès, succès partiel, échec, ou objectif non clair. Deux autres classificateurs évaluent la force de la preuve de cette réussite, pour déterminer si elle est « vérifiée ». Le classificateur de preuve de succès recherche des éléments vérifiables, comme des activités git (commit, pull request), la réussite de tests, ou une approbation explicite de l’utilisateur. Il attribue une note de 1 (aucun signal) à 5 (plusieurs signaux forts). Un classificateur parallèle pour les échecs évalue la présence d’erreurs, d’échecs de tests, de tentatives répétées, ou de désaccords de l’utilisateur. La réussite vérifiée nécessite que la session soit jugée réussie, et qu’au moins un signal fort de succès soit présent. 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 de compétence

Quels types de sessions ont le plus de chances de réussir ? Les résultats montrent que le score de compétence apparent a une influence majeure.

Certains pourraient craindre que le niveau de compétence ne soit qu’un effet de bord, par exemple parce que les experts choisissent des tâches différentes ou ont d’autres caractéristiques. Dans cette section, nous répondons en partie à cette crainte en comparant des sessions du même type de travail, avec la même valeur estimée, au même mois, sur le même sujet, et provenant du même groupe professionnel.

> Tableau 2 : Définition de la réussite et de l’échec par le classificateur. Exemples issus de conversations réelles dans le dataset SWE-chat, modifiés, anonymisés et résumés par notre classificateur.

Dans tous nos indicateurs de succès, plus le niveau de compétence apparent 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 compris 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 de compétence et résultats de la session. La figure montre, selon le score de compétence apparent, la proportion de sessions réussies ou échouées, pour cinq niveaux allant de débutant à expert. La gauche inclut toutes les sessions. La centrale et la droite ne concernent que les sessions en difficulté, c’est-à-dire celles où le signal d’échec est supérieur à 3, et montre la proportion de ces sessions atteignant différents niveaux de succès ou d’échec. 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 groupe professionnel (par exemple, métier lié au logiciel). 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 jugées « sans objectif clair ».

Même dans les sessions en difficulté, on observe une tendance similaire. Lorsqu’un signal d’échec est enregistré avec des preuves vérifiables, on considère que la session « rencontre un problème ». Cela peut inclure des erreurs, des échecs de tests, des tentatives répétées, ou des expressions de frustration ou de mécontentement de l’utilisateur. Parmi ces sessions problématiques, la proportion de réussite vérifiée 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, on trouve que la proportion 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é une relation inverse : celle entre le niveau de 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 d’abandon. Chez les débutants, 19 % de ces sessions finissent ainsi, contre 5 à 7 % pour les autres groupes. Autrement dit, les utilisateurs avec peu d’expérience abandonnent plus facilement lorsqu’ils rencontrent des difficultés. La capacité à ramener l’agent dans la bonne direction semble donc faire partie de la valeur du niveau de compétence.

Le métier est peut-être moins important que le niveau de 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 ajoutée ou modifié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, avec 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. Cela pourrait refléter le fait que les compétences en gestion se transfèrent à la direction d’un agent, ou que cette mesure dépend en partie de la façon dont l’utilisateur exprime sa satisfaction, ce qui est plus fréquent chez les gestionnaires.

> 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 succès selon la définition stricte, par groupe professionnel. Les dix groupes les plus nombreux sont représentés. Chaque groupe a un écart-type basé sur 95 % d’intervalle de confiance, calculé à partir de différents comptes. La différence avec la catégorie « professions informatiques et mathématiques » (SOC) est inférieure à sept points de pourcentage.

Perspectives

Les résultats de ce rapport esquissent un tableau en train de se former : la programmation par agent amplifie certaines compétences et connaissances, tout en en remplaçant d’autres. Dans les sessions de génération de code, la réussite est comparable entre les principales professions et celles liées à l’informatique. Il semble que la capacité à faire coder un agent IA diminue l’importance de la formation en programmation pour réussir.

Par ailleurs, les sessions réussies montrent une plus grande présence de connaissances spécialisées. Les sessions d’experts 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. La façon dont la collaboration fonctionne elle-même rend cette tendance plus claire : les experts peuvent guider Claude avec chaque instruction pour réaliser davantage de travail. La capacité à amener Claude au succès dépend donc davantage de la maîtrise du domaine que de la capacité à écrire du code. Toute personne maîtrisant un domaine peut désormais réaliser des tâches techniques auparavant impossibles. Ceux qui manquent de cette compréhension spécialisée, 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. 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 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 représente une part importante de l’activité totale. Développer un cadre pour mesurer ce type d’utilisation sera une priorité future. Toutes nos classifications de session dépendent aussi de la lecture par le modèle des transcripts. 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 référence forte. Cependant, dans des scénarios à grande échelle, la validation du classificateur reste difficile ; les sessions 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, la vision présentée dans ce rapport continuera de se modifier. Nous espérons que ces indicateurs pourront suivre ces changements majeurs. Par exemple, si à l’avenir le retour sur compétence diminue, cela indiquerait que le modèle fournit déjà des jugements clés, et que ces outils profitent désormais à un public plus large que les experts. Si la proportion d’utilisateurs hors métier du logiciel qui réussissent à compléter des sessions de codage continue d’augmenter, cela pourrait signifier que la production logicielle devient une partie intégrante du travail général 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 la communauté officielle de BlockBeats :
Telegram : https://t.me/theblockbeats
Groupe Telegram : https://t.me/BlockBeats_App
Compte officiel Twitter : https://twitter.com/BlockBeatsAsia