Les mods d’Anthropic pour Claude Code permettent aux développeurs de réécrire l’agent lui-même

Anthropic a introduit une fonctionnalité qu’elle appelle mods pour Claude Code. L’idée est compacte : de petites fonctions TypeScript qui modifient le comportement de l’agent de codage, chargées dans l’outil plutôt qu’intégrées en dur dans le modèle.

C’est une petite version aux implications majeures. Le comportement d’un agent de codage cesse d’être quelque chose que l’on configure pour devenir quelque chose que l’on écrit.

Pourquoi une fonction l’emporte sur un paramètre

La plupart de la personnalisation des agents passe aujourd’hui par des paramètres. Température, autorisations des outils, prompt système, liste de commandes autorisées. Ces réglages partagent une limite. Ils décrivent des préférences en langage naturel et espèrent que le modèle les respecte. Quand le modèle juge qu’une autre interprétation est plus utile, le paramètre perd.

Un mod est du code. Il s’exécute, renvoie un résultat et sa sortie est déterministe. Cela change la nature du contrôle. Si vous voulez que l’agent ne touche jamais à un répertoire précis, un mod bien placé peut l’imposer au lieu de demander gentiment. Si vous voulez qu’une transformation précise soit appliquée à chaque diff avant qu’il n’arrive en revue, un mod peut le faire à tous les coups plutôt que la plupart du temps.

Le compromis est le même que d’habitude. Le code est plus puissant et plus fragile qu’un paramètre. Il peut contenir des bugs. Il doit être maintenu. L’avantage, c’est que l’application de la règle vit dans votre dépôt, sous gestion de versions, à côté du code qu’elle régit.

La couche de personnalisation est là où la concurrence s’est déplacée

Observez le marché des agents de codage : le centre de gravité s’est déplacé. Les modèles sous-jacents convergent. Un développeur qui doit choisir entre eux aujourd’hui débat de quelques points de performance aux benchmarks, ce qui constitue une bien faible base pour une décision qui durera des années. Les différences qui comptent vraiment se situent dans la couche autour du modèle : la façon dont il gère votre dépôt, dont il respecte vos conventions et dont il peut absorber une partie de votre processus.

Anthropic n’est pas la seule entreprise à faire cela. Tous les agents de codage sérieux ajoutent des hooks, des règles et des surfaces de plugin. La raison est structurelle. Une fois que le modèle est assez bon pour que la capacité brute cesse d’être décisive, le fournisseur qui permet aux équipes d’inscrire leur propre jugement dans l’outil gagne les équipes aux opinions affirmées. Et les équipes aux opinions affirmées sont exactement celles qu’il vaut la peine de gagner.

Ce que les mods disent de la confiance

Il y a une lecture plus discrète de cette annonce. Donner aux développeurs un moyen de réécrire le comportement de l’agent revient à admettre que le fournisseur ne peut pas anticiper chaque flux de travail. Un agent de codage s’exécute dans des milliers de bases de code différentes, chacune avec son histoire, ses conventions et sa propre définition d’un changement dangereux. Aucune configuration par défaut ne survit au contact d’une telle diversité.

La démarche honnête consiste donc à exposer la jointure. Laissez l’équipe qui connaît sa propre base de code appliquer ses propres règles, dans le code, et assumer la responsabilité du résultat. C’est une posture plus mature que d’ajouter une case à cocher de plus à une page de paramètres et de prétendre qu’elle couvre tous les cas.

Cela déplace aussi la responsabilité de manière subtile. Un mod qui bloque une mauvaise action est le mod du client. S’il contient un bug et laisse passer l’action, c’est le client qui assume ce résultat. C’est la nature de toute soupape de sécurité, plutôt qu’une critique de la fonctionnalité, et c’est aussi ainsi que les entreprises préfèrent opérer. Elles préfèrent contrôler la frontière et en être responsables plutôt que de la déléguer à un fournisseur sans avoir leur mot à dire.

La frontière entre construire et acheter se déplace encore

Pendant des années, la question avec les outils de développement était de savoir s’il fallait construire le sien ou l’acheter. Les agents de codage ont fait bouger cette frontière. Les mods la déplacent une fois de plus, et dans une direction précise. Le modèle reste un produit que l’on achète. La politique qui l’entoure devient quelque chose que vous construisez en quelques dizaines de lignes de TypeScript.

C’est une séparation saine. Les équipes ne devraient pas avoir à entraîner leurs propres modèles pour obtenir le comportement dont elles ont besoin, et elles ne devraient pas être coincées avec un comportement qu’elles ne peuvent pas modifier. Une surface de personnalisation légère se situe entre ces deux extrêmes, et c’est là qu’une grande partie de la valeur pratique des agents de codage finira par se décider.

L’extensibilité est ce qui permet à un outil de survivre à son propre succès

Il existe un schéma dans les outils de développement qui mérite qu’on s’y arrête, car les mods s’y inscrivent précisément. Un outil est lancé avec des partis pris, conquiert un public, puis se heurte à un mur lorsque ce public dépasse ces partis pris. Les utilisateurs qui l’ont adopté en premier étaient satisfaits des valeurs par défaut. Ceux qui arrivent plus tard ont des exigences que les valeurs par défaut n’avaient jamais imaginées, et ils partent vers un outil qu’ils peuvent façonner.

Les outils qui survivent à ce moment exposent une jointure. Ils permettent à la communauté d’étendre le comportement dans le langage propre de l’outil, et les extensions deviennent une partie de la pression de l’écosystème. Un éditeur vous laisse écrire des plugins. Un système de build vous laisse écrire des tâches. Un agent de codage qui vous laisse écrire des mods fait le même geste, et il le fait avant le mur, signe que le fournisseur a déjà vu ce film.

La jointure crée aussi une boucle de rétroaction qu’une page de paramètres ne peut pas offrir. Quand les équipes commencent à publier des mods, le fournisseur peut voir quels comportements reviennent sans cesse dans les demandes et commencer à les livrer par défaut. La surface de personnalisation devient un canal de recherche, et la communauté fait le travail de découverte gratuitement. C’est le dividende discret de l’extensibilité, et il est généralement plus précieux que n’importe quel mod pris isolément.

Où cela mène ensuite

L’étape suivante évidente est le partage. Les mods qui vivent dans un dépôt sont déjà portables. Un registre public, un ensemble de règles communautaires pour les flux de travail courants, un moyen d’importer un mod bien testé comme on importe une bibliothèque. Tout cela est à courte distance de ce qui a été livré, et tout cela transforme l’outil d’une application avec un dossier de plugins en une plateforme avec une place de marché.

Cette direction comporte des risques désormais familiers. Un mod partagé est du code non fiable qui s’exécute dans un outil qui détient vos identifiants et votre code source. Le domaine de la sécurité des agents a passé l’année à documenter précisément comment un petit élément d’automatisation d’apparence fiable devient le chemin d’attaque. Tout registre de mods devra résoudre la question de la confiance avant celle de la découverte, et les fournisseurs qui traiteront ce problème comme prioritaire seront ceux sur lesquels les développeurs s’appuieront.

La version elle-même tient en quelques paragraphes dans un journal des modifications. La direction qu’elle indique est plus vaste. Les agents de codage deviennent des plateformes, et les équipes qui les traitent comme telles, en inscrivant leurs propres règles dans le code et en les gardant sous gestion de versions, tireront davantage des prochaines années que celles qui cherchent encore dans les paramètres la bonne case à cocher.

Il y a toutefois une limite qu’il faut nommer. Toutes les équipes n’ont pas quelqu’un qui souhaite écrire et maintenir un mod, et une surface de personnalisation que seuls quelques développeurs utilisent ne change pas grand-chose pour tous les autres. La valeur des mods dépendra de l’émergence d’un ensemble sain de mods partagés et bien maintenus, à la manière dont un écosystème de plugins rend un éditeur plus utile aux personnes qui n’ouvrent jamais son code source. Tant que cela n’arrive pas, les mods sont une fonctionnalité avancée pour les équipes aux opinions affirmées. Ce qui, en fin de compte, décrit la plupart des équipes qui font déjà tourner des agents de codage en production.