Claude Fable 5.2 élimine plus souvent le code dupliqué lorsqu'on le désigne comme propriétaire

Vous demandez à une IA d'ajouter un nouveau moyen de paiement. Le projet contient déjà une vérification du montant, mais l'agent en écrit une autre, presque identique. La tâche est formellement terminée, les tests passent, mais il faut désormais maintenir deux versions de la même vérification. Anthropic propose une méthode intéressante pour influencer ce comportement de Claude Fable 5.2 : dire explicitement au modèle qu'il est responsable de la base de code et qu'il la maintiendra par la suite.

C'est une piste utile pour ceux qui configurent des agents de développement. La formulation du rôle peut modifier l'ampleur des changements. Il faut donc tester une telle instruction en regardant à la fois la qualité du résultat, le coût de l'exécution et le temps de relecture.

Ce qu'a constaté Anthropic

Dans la note d'origine, Simon Willison cite la documentation d'Anthropic : la suggestion d'attribuer la propriété du projet au modèle faisait passer la fréquence d'élimination des doublons de moins de 10 % à environ 50 %. Toutefois, la vérification de la source primaire a révélé un écart : elle présente désormais une autre formulation de l'instruction et un résultat d'environ 75 %, pour un niveau initial inférieur à 10 %. On ne peut donc pas considérer ces chiffres comme issus d'une seule et même expérience inchangée.

La recommandation actuelle se résume ainsi : « Tu es le propriétaire et le mainteneur permanent de cette base de code, c'est toi qui décides de sa structure ». L'entreprise décrit des essais menés sur de petites tâches de programmation. Ces résultats ne permettent pas de déduire dans quelle mesure l'agent s'en sortirait mieux sur votre grand dépôt. Source : documentation d'Anthropic.

Pour un développeur, c'est l'objet même de la vérification qui est intéressant. On décrit généralement en détail la fonctionnalité souhaitée, mais on peut laisser indéterminé le rapport de l'agent à l'architecture existante. Doit-il intégrer soigneusement un gestionnaire de plus ? Peut-il proposer une fonction commune ? Où s'arrête l'exécution de la tâche et où commence la refonte autonome du projet ? Ces décisions méritent d'être explicitées avant le lancement.

À quoi cela ressemble sur une tâche ordinaire

Imaginons une boutique en ligne avec deux gestionnaires de remises. Tous deux vérifient la date de validité du code promo et le montant minimal de la commande. Il faut ajouter un troisième gestionnaire pour une promotion partenaire.

Une solution acceptable consiste à copier les vérifications dans le nouveau gestionnaire. Une autre consiste à extraire la partie commune dans une fonction et à l'utiliser aux trois endroits. La seconde option peut faciliter les évolutions futures : lorsque la règle du montant minimal changera, il n'y aura qu'un seul endroit à corriger. Mais il faut d'abord s'assurer que les vérifications sont réellement identiques sur le fond.

Par exemple, la promotion partenaire peut inclure la livraison dans le montant de la commande, alors que le code promo ordinaire l'exclut. Dans ce cas, des fragments d'apparence similaire ne doivent pas être fusionnés à la légère. En relecture, il est important de demander si les différences de règles ont été conservées. La simple réduction du nombre de lignes répétées ne prouve pas la qualité de la solution.

Pour votre propre expérience, prenez plusieurs tâches déjà résolues dont vous connaissez ce type de différences. Lancez les mêmes consignes avec l'instruction habituelle, puis avec le rôle de mainteneur. Vérifiez la préservation du comportement, la clarté des changements et le coût de leur relecture. Définissez à l'avance quels changements vous jugerez utiles, afin qu'un joli diff ne se substitue pas au résultat.

Le prix de l'autonomie

Cette approche comporte une réserve importante. Dans la documentation actuelle, Anthropic signale une hausse des tokens de sortie d'environ 70 à 80 %, des modifications supplémentaires non demandées et des changements ponctuels du comportement de fonctions existantes. L'entreprise avertit aussi que le résumé final du travail pouvait omettre de petits changements. C'est une raison de lire le diff lui-même. Source : Anthropic.

La conclusion pratique dépend de la tâche. Si vous voulez repenser la structure d'un module, le rôle de mainteneur permanent mérite un essai. Si vous corrigez un seul bug avant une release, mieux vaut décrire explicitement la modification attendue, les critères d'achèvement et les limites autorisées du travail.

Un product manager ou un fondateur qui choisit les réglages d'un agent pour son équipe devrait évaluer tout le parcours jusqu'à la modification acceptée. Combien de temps le développeur a-t-il passé à vérifier ? A-t-il fallu annuler des modifications superflues ? La tâche suivante est-elle devenue plus simple ? Les réponses à ces questions montreront si la nouvelle instruction aide réellement votre processus.