Claude et Codex deviennent de plus en plus stupides ? Parce que votre contexte est trop encombré

Auteur : sysls

Traduction : Deep潮 TechFlow

Deep潮 Introduction : Le développeur et blogueur @sysls, avec 2,6 millions de followers, a écrit un long article pratique qui a été partagé par 827 personnes et liké par 7000. Son message central : vos plugins, systèmes de mémoire et divers harness vous font probablement plus de mal que de bien. Cet article ne prêche pas la théorie, mais synthétise des principes opérationnels issus de projets réels — comment contrôler le contexte, gérer l’attrait de l’IA, définir les conditions de fin de tâche — c’est de loin la meilleure explication pratique de l’ingénierie Claude/Codex que j’aie vue.

Voici le texte intégral :

Introduction

Vous êtes développeur, vous utilisez quotidiennement Claude et Codex CLI, et vous vous demandez si vous avez vraiment exploité tout leur potentiel. Parfois, ils font des choses incroyablement stupides, et vous ne comprenez pas pourquoi certains semblent construire des fusées avec l’IA, alors que vous ne pouvez même pas empiler deux pierres.

Vous pensez que c’est votre harness, vos plugins, votre terminal… Vous avez utilisé beads, opencode, zep, écrit 26 000 lignes dans CLAUDE.md. Mais malgré tous vos efforts, vous ne comprenez pas pourquoi vous restez si loin du paradis, alors que d’autres jouent avec des anges.

C’est exactement cet article que vous attendiez.

Je n’ai aucun intérêt personnel. Je dis que CLAUDE.md inclut aussi AGENT.md, que Claude inclut Codex — je les utilise tous les deux intensément.

Ces derniers mois, j’ai remarqué une chose intéressante : presque personne ne sait vraiment comment maximiser la puissance d’un agent.

On dirait qu’un petit groupe peut faire construire un monde entier par l’agent, alors que la majorité tourne en rond dans une mer d’outils, souffrant du syndrome de la recherche de la bonne combinaison — croyant qu’en trouvant le bon package, la bonne compétence ou le bon harness, ils débloqueront une AGI.

Aujourd’hui, je veux tout casser, vous laisser avec une phrase simple et honnête, puis partir de là. Vous n’avez pas besoin du dernier harness, ni d’installer un million de packages, ni de lire un million d’articles pour rester compétitif. En fait, votre enthousiasme pourrait vous faire plus de mal que de bien.

Je ne suis pas là pour faire du tourisme — j’ai commencé à utiliser l’agent quand il pouvait à peine coder. J’ai testé tous les packages, tous les harness, toutes les paradigmes. J’ai écrit des usines d’agents pour générer des signaux, des infrastructures, des pipelines — pas des « projets jouets », mais des cas concrets en production. Après tout ça…

Aujourd’hui, je travaille avec une configuration presque simplissime, utilisant uniquement le CLI de base (Claude Code et Codex), avec une compréhension fondamentale des principes d’ingénierie des agents, et j’ai réalisé mon travail le plus innovant à ce jour.

Comprendre que le monde évolue à toute vitesse

D’abord, il faut savoir que les entreprises de modèles fondamentaux sont en pleine course effrénée, et il est évident que ça ne ralentira pas de sitôt. Chaque avancée dans « l’intelligence agentique » change votre façon de collaborer avec eux, car ils sont conçus pour suivre de plus en plus facilement vos instructions.

Il y a quelques générations, si vous écriviez dans CLAUDE.md « Avant de faire quoi que ce soit, lire READTHISBEFOREDOINGANYTHING.md », il y avait 50 % de chances qu’il vous réponde « Va te faire voir », puis fasse ce qu’il voulait. Aujourd’hui, il suit la plupart des instructions, même les instructions imbriquées — par exemple, « lis A d’abord, puis B, si C alors D » — et il est généralement heureux de suivre.

Que cela signifie-t-il ? La règle d’or : chaque nouvelle génération d’agent vous oblige à repenser ce qui est optimal. C’est pour ça que moins, c’est souvent plus.

Utiliser trop de bibliothèques et de harness vous enferme dans une « solution » qui pourrait ne plus exister avec la prochaine génération d’agents. Savez-vous qui sont les utilisateurs les plus enthousiastes et les plus nombreux des agents ? Exactement — les employés des entreprises à la pointe, avec un budget illimité de tokens, utilisant les modèles les plus récents. Vous comprenez ce que cela implique ?

Cela veut dire que si un problème réel existe et qu’une bonne solution est trouvée, ce sont ces entreprises qui en seront les plus grands utilisateurs. Et que feront-elles ensuite ? Elles intégreront cette solution dans leurs produits. Imaginez : pourquoi une entreprise laisserait un autre produit résoudre un vrai problème et créer une dépendance externe ? Comment je peux en être sûr ? En regardant les compétences, les harness de mémoire, les sous-agents… Tout commence par une « solution » à un vrai problème, testée en pratique, prouvée utile.

Donc, si quelque chose est vraiment révolutionnaire et peut étendre de manière significative l’usage des agents, cela finira tôt ou tard dans le cœur des produits des entreprises leaders. Faites-moi confiance, ces entreprises avancent à toute vitesse. Détendez-vous : vous pouvez faire du bon travail sans installer ou dépendre de quoi que ce soit d’extérieur.

Je prévois que dans les commentaires, quelqu’un dira : « SysLS, j’ai utilisé tel harness, c’est génial ! En une journée, j’ai reconstruit Google ! » — À cela je réponds : félicitations ! Mais vous n’êtes pas la cible. Vous représentez une minorité extrême, celle qui maîtrise vraiment l’ingénierie des agents.

Le contexte, c’est tout

Vraiment. Le contexte, c’est tout. Un autre problème avec l’utilisation de nombreux plugins et dépendances externes, c’est la « croissance du contexte » — votre agent est noyé sous trop d’informations.

Je vais faire un jeu de devinette en Python ? Facile. Mais, qu’est-ce que cette note « gestion de la mémoire » il y a 26 sessions ? Ah, l’utilisateur a un écran bloqué depuis 71 sessions à cause de processus enfants générés en excès. Toujours écrire des notes ? D’accord… mais ça, ça n’a rien à voir avec le jeu de devinette.

Vous voyez. Vous voulez juste fournir à l’agent l’information précise nécessaire pour accomplir la tâche, ni plus ni moins. Plus vous maîtrisez cela, meilleur sera l’agent. Dès que vous introduisez des systèmes de mémoire étranges, des plugins, ou des compétences avec des noms et des appels confus, vous donnez à l’agent une recette pour faire exploser une bombe ou pour faire un gâteau — alors que vous voulez juste qu’il écrive un petit poème sur la forêt de séquoias.

Je vais encore prêcher : éliminez toutes les dépendances, puis…

Faites quelque chose de vraiment utile

Décrivez précisément les détails de la mise en œuvre

Vous vous souvenez que le contexte, c’est tout ?

Que vous voulez fournir à l’agent l’information exacte pour finir la tâche, ni plus ni moins ?

La première étape consiste à séparer recherche et exécution. Soyez extrêmement précis sur ce que vous demandez à l’agent.

Quelles sont les conséquences d’être imprécis ? « Crée un système d’authentification. » L’agent doit alors rechercher : qu’est-ce qu’un système d’authentification ? Quelles options existent ? Quels sont leurs avantages et inconvénients ? Il doit fouiller en ligne, remplir le contexte d’informations peu pertinentes ou inexactes. Lorsqu’il s’agit de réaliser, il risque de se mélanger ou d’avoir des illusions inutiles ou hors sujet.

Inversement, si vous dites : « Utilise bcrypt-12 pour le hashage de mot de passe, implémente JWT avec rotation de jetons, expiration en 7 jours… » — il n’a pas besoin d’étudier d’autres options, il sait ce que vous voulez, et peut remplir le contexte avec des détails précis.

Bien sûr, vous ne saurez pas toujours tout. Parfois, vous ne savez pas ce qui est correct, et vous souhaitez même confier la décision à l’agent. Que faire ? Très simple : créez une tâche de recherche pour explorer différentes options, choisissez vous-même ou laissez l’agent décider, puis faites réaliser par un autre agent avec un contexte totalement nouveau.

En pensant ainsi, vous repérerez où le contexte de l’agent est inutilement pollué, et vous pourrez mettre en place des barrières dans votre workflow pour isoler ces informations, ne laissant que ce qui permet à l’agent d’exceller dans sa tâche. Rappelez-vous : vous avez une équipe très talentueuse, qui connaît toutes sortes de sphères — sauf si vous lui indiquez que vous voulez un espace où les gens dansent et s’amusent, il parlera toujours des avantages des sphères.

Les limites de la conception pour plaire

Personne ne veut d’un produit qui vous critique, vous dit que vous avez tort ou ignore complètement vos instructions. Donc, ces agents essaient de vous approuver, de faire ce que vous souhaitez.

Si vous leur demandez d’ajouter « heureux » après chaque 3 mots, ils feront de leur mieux — c’est compréhensible. Leur obéissance est ce qui en fait un produit si pratique. Mais il y a une caractéristique intéressante : cela signifie que si vous dites « trouve-moi un bug dans la base de code », ils finiront par en trouver un — même si cela implique d’en « fabriquer » un. Pourquoi ? Parce qu’ils veulent vraiment vous satisfaire !

Beaucoup se plaignent rapidement des hallucinations et de la fabrication d’informations inexistantes, sans réaliser que le problème vient d’eux. Ce qu’ils demandent, ils l’obtiennent — même si cela nécessite de déformer légèrement la réalité !

Que faire ? J’ai trouvé que les « prompts neutres » sont très efficaces : ne pas orienter l’agent vers un résultat précis. Par exemple, au lieu de dire « trouve-moi un bug dans la base de données », dites « scanne toute la base, en suivant la logique de chaque composant, et rapporte tout ce que tu trouves ».

Ce type de prompt neutre peut parfois découvrir des bugs, parfois simplement décrire objectivement le fonctionnement du code. Mais il n’oriente pas l’agent vers une présomption de « bug ».

Une autre façon de gérer cette tendance à plaire est de la transformer en avantage. Je sais que l’agent essaie de me satisfaire, de suivre mes instructions, je peux orienter cette tendance.

Par exemple, je demande à un agent de bug hunter d’évaluer chaque bug trouvé : un bug mineur vaut +1, un bug moyen +5, un bug critique +10. Je sais que cet agent sera très enthousiaste à identifier tous les bugs (y compris ceux qui ne sont pas vraiment des bugs), et me rapportera un score total, disons 104. Je considère cela comme un super-ensemble de tous les bugs possibles.

Ensuite, je demande à un autre agent de contrecarrer, en lui disant que chaque bug contrecarré avec succès vaut le score du bug, mais si l’erreur est fausse, il perdra le double de ce score (par exemple -2×). Cet agent s’efforcera de contrecarrer autant de bugs que possible, tout en restant prudent grâce à la pénalité. Il continuera à « contrecarrer » des bugs (y compris de vrais bugs). Je considère cela comme un sous-ensemble de bugs réels.

Enfin, je demande à un troisième agent de faire la synthèse et de donner une note. Je lui dis que j’ai la réponse correcte, et qu’il gagne +1 s’il a raison, -1 s’il se trompe. Il va donc noter chaque bug trouvé par le premier et le second agent. La vérité, c’est ce que je vais vérifier. La plupart du temps, cette méthode est étonnamment précise, parfois elle échoue, mais c’est presque sans erreur.

Vous pourriez penser qu’un seul agent de recherche de bugs suffit, mais cette méthode me convient bien, car elle exploite la tendance naturelle de chaque agent à vouloir plaire.

Comment juger ce qui est utile, ce qui vaut la peine d’être utilisé ?

Cela peut sembler difficile, nécessitant de suivre l’état de l’art en IA en permanence. En réalité, c’est simple… si OpenAI et Claude l’ont implémenté ou racheté la société qui l’a fait… c’est probablement utile.

Avez-vous remarqué que « skills » est partout, et fait partie de la documentation officielle de Claude et Codex ? Avez-vous vu qu’OpenAI a racheté OpenClaw ? Que Claude a rapidement ajouté la mémoire, la voix, le travail à distance ?

Et la planification ? Vous souvenez-vous que beaucoup ont découvert que planifier avant d’agir est très efficace, et que cela est devenu une fonctionnalité clé ?

Ce sont des choses utiles !

Et le stop-hook infini, qui est super utile parce que l’agent est très réticent à faire des tâches longues… puis, avec Codex 5.2, cette nécessité a disparu du jour au lendemain ?

C’est tout ce que vous devez savoir… si quelque chose est vraiment important et utile, Claude et Codex l’implémenteront eux-mêmes ! Donc, pas besoin de vous inquiéter de « l’utiliser ou pas », ni de « rester à jour ».

Aidez-moi : mettez à jour occasionnellement votre CLI préféré, regardez ce qui a été ajouté. C’est suffisant.

Compression, contexte et hypothèses

Certains rencontrent un gros piège en utilisant des agents : parfois, ils semblent incroyablement intelligents, parfois, vous avez l’impression qu’on vous manipule.

« Ce truc est intelligent ? C’est un idiot ! »

La différence principale, c’est si l’agent est forcé de faire des hypothèses ou de « combler des lacunes ». Aujourd’hui, il est encore très mauvais pour faire des liens ou combler des lacunes. Dès qu’il le fait, la qualité chute immédiatement.

Une règle essentielle dans CLAUDE.md concerne la façon d’obtenir le contexte, et indique que chaque fois que l’agent lit CLAUDE.md (après compression), il doit d’abord lire cette règle. En tant que partie de la gestion du contexte, quelques instructions simples peuvent avoir un impact énorme : relire le plan de tâche, relire les fichiers liés avant de continuer.

Dites à l’agent comment finir la tâche

Notre perception de « finir » une tâche est claire. Pour l’agent, le plus gros problème est qu’il sait comment commencer, mais pas comment finir.

Cela conduit souvent à des résultats frustrants : l’agent finit par faire des stub et s’arrête.

Les tests sont une étape clé, car ils sont déterministes : vous pouvez définir des attentes très précises. Si ces tests ne passent pas, la tâche n’est pas finie ; vous ne modifiez pas les tests.

Vous pouvez automatiser cela, mais l’essentiel est — rappelez-vous que « finir une tâche » est naturel pour un humain, mais pas pour un agent.

Vous savez ce qui est devenu une fin de tâche pratique récemment ? La capture d’écran + la validation. Vous pouvez demander à l’agent de réaliser quelque chose jusqu’à ce que tous les tests soient passés, puis de faire une capture d’écran et de vérifier le design ou le comportement.

Cela vous permet d’itérer avec l’agent vers le résultat souhaité, sans craindre qu’il s’arrête après sa première tentative !

Une extension naturelle est de faire créer à l’agent un « contrat », intégré dans des règles. Par exemple, ce {TASK}CONTRACT.md définit ce qu’il faut faire avant de pouvoir terminer la session. Dans {TASK}CONTRACT.md, vous spécifiez les tests, captures d’écran, et autres vérifications nécessaires pour valider la fin de la tâche.

Un agent qui tourne en permanence

On me demande souvent comment faire fonctionner un agent 24h/24 tout en évitant qu’il dévie.

Voici une méthode simple : créez un stop-hook qui empêche l’agent de terminer la session tant que toutes les parties du {TASK}_CONTRACT.md ne sont pas accomplies.

Si vous avez 100 contrats précis, contenant tout ce que vous souhaitez construire, le stop-hook empêchera l’agent de s’arrêter jusqu’à ce que tout soit terminé, y compris tous les tests et validations.

Conseil pro : je trouve que faire tourner un agent 24h sur 24 n’est pas optimal. Cela introduit structurellement une croissance du contexte, car tous les contrats non liés entrent dans la même session.

Je ne recommande pas cette approche.

Une meilleure méthode d’automatisation consiste à ouvrir une nouvelle session pour chaque contrat. Lorsqu’une tâche doit être effectuée, créez un nouveau contrat.

Mettez en place une couche d’orchestration pour créer un nouveau contrat et une nouvelle session à chaque besoin.

Cela transformera radicalement votre expérience avec l’agent.

Itérer, encore et encore

Vous embauchez un assistant administratif. Attendez-vous à ce qu’il connaisse votre emploi du temps dès le premier jour ? Ou à ce qu’il sache comment vous boire un café ? Que vous dîniez à 18h au lieu de 20h ? Non. Vous construisez vos préférences avec le temps.

L’agent aussi. Commencez avec une configuration simple, oubliez la complexité, donnez une chance au CLI de base.

Puis, ajoutez progressivement vos préférences. Comment faire ?

Règles

Si vous ne voulez pas que l’agent fasse quelque chose, écrivez une règle. Ensuite, indiquez-lui dans CLAUDE.md. Par exemple : « Avant d’écrire du code, lire coding-rules.md. » Les règles peuvent être imbriquées, conditionnelles ! Si vous codez, lire coding-rules.md ; si vous testez, lire coding-test-rules.md ; si un test échoue, lire coding-test-failing-rules.md. Vous pouvez créer des branches logiques pour l’agent, et Claude (et Codex) suivra volontiers, à condition que ce soit clair dans CLAUDE.md.

C’est ma première recommandation concrète : considérez votre CLAUDE.md comme un répertoire logique, avec des instructions conditionnelles pour aller chercher le contexte selon la situation. Il doit être aussi simple que possible, ne contenant que des IF-ELSE pour indiquer où chercher le contexte dans des scénarios précis.

Si vous voyez l’agent faire quelque chose que vous n’approuvez pas, ajoutez une règle pour lui indiquer de relire cette règle avant de recommencer. Il ne le refera pas.

Compétences (Skills)

Les compétences ressemblent aux règles, mais plutôt qu’un style de codage, elles décrivent une « étape opérationnelle ». Si vous souhaitez qu’une tâche soit effectuée d’une certaine façon, mettez-la dans une compétence.

Beaucoup se plaignent de ne pas savoir comment l’agent résoudra un problème, ce qui crée de l’incertitude. Si vous voulez de la certitude, faites que l’agent étudie comment il pourrait le faire, puis écrivez cette solution dans un fichier de compétence. Vous verrez ainsi comment l’agent envisage la résolution, et pourrez corriger ou améliorer avant qu’il ne rencontre le problème.

Comment faire connaître cette compétence à l’agent ? Facile : dans CLAUDE.md, indiquez que lorsqu’un scénario nécessite cette compétence, il doit lire le fichier SKILL.md.

Gérer règles et compétences

Vous voudrez sans cesse ajouter des règles et compétences. C’est la façon d’insuffler de la personnalité et de la mémoire de préférences à votre agent. Tout le reste est superflu.

Une fois que vous faites cela, votre agent semblera magique. Il « agira comme vous le souhaitez ». Et vous aurez enfin le sentiment d’avoir « compris » l’ingénierie des agents.

Mais…

Vous verrez la performance baisser à nouveau.

Pourquoi ?!

C’est simple. En ajoutant de plus en plus de règles et compétences, elles commencent à se contredire, ou à provoquer une croissance excessive du contexte. Si vous demandez à l’agent de lire 14 fichiers markdown avant de commencer à coder, vous avez le même problème : beaucoup d’informations inutiles.

Que faire ?

Nettoyez. Faites que votre agent « fasse un spa », intégrez règles et compétences, et éliminez les contradictions en précisant vos préférences mises à jour.

Et là, il redeviendra magique.

C’est tout. C’est la clé : restez simple, utilisez règles et compétences, considérez CLAUDE.md comme un répertoire, et faites attention à ses limites de contexte et de conception.

Responsabilité sur le résultat

Il n’existe pas d’agent parfait aujourd’hui. Vous pouvez déléguer beaucoup de conception et d’implémentation à l’agent, mais vous restez responsable du résultat.

Soyez donc prudent… et profitez-en !

Jouer avec des jouets du futur (tout en utilisant déjà sérieusement) est une vraie joie !