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

Voici la traduction complète et précise en fr-FR :

Depuis la manière de contrôler le contexte, de gérer la tendance à l’auto-complaisance de l’IA, jusqu’à la définition des conditions d’arrêt des tâches, c’est actuellement l’article le plus clair que j’ai vu sur la pratique de l’ingénierie avec Claude/Codex.

Auteur : sysls

Traduit par : Deep潮 TechFlow

Introduction de Deep潮 : 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 rassemble des principes opérationnels issus de projets réels — depuis comment maîtriser le contexte, gérer la tendance à l’auto-complaisance de l’IA, jusqu’à comment définir les conditions d’arrêt d’une tâche. C’est actuellement la présentation la plus claire que j’ai vue sur la pratique de l’ingénierie avec Claude/Codex.

Introduction

Vous êtes développeur, et chaque jour vous utilisez Claude et Codex CLI, en vous demandant si vous avez vraiment exploité tout leur potentiel. Parfois, vous les voyez faire des choses incroyablement stupides, et vous ne comprenez pas pourquoi certains semblent construire des fusées avec l’IA, alors que vous n’arrivez même pas à empiler deux pierres.

Vous pensez que c’est un problème de votre harness, de vos plugins, de votre terminal, peu importe. Vous avez utilisé beads, opencode, zep, vous avez écrit 26 000 lignes dans CLAUDE.md. Mais malgré tous vos efforts, vous ne comprenez toujours pas pourquoi vous vous éloignez du paradis, alors que d’autres jouent avec des anges.

C’est exactement cet article que vous attendiez.

De plus, je n’ai aucun intérêt personnel. Quand je parle de CLAUDE.md, cela inclut aussi AGENT.md. Quand je parle de Claude, cela inclut aussi Codex. Je les utilise tous les deux énormément.

Ces derniers mois, j’ai observé une chose intéressante : presque personne ne sait vraiment comment exploiter au maximum la capacité d’un agent.

On dirait qu’un petit groupe peut faire construire un univers entier par l’agent, alors que la majorité tourne dans une mer d’outils, souffrant du syndrome de la sélection — croyant qu’en trouvant le bon package, la bonne compétence ou le bon harness, ils pourront débloquer 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 d’agent, ni d’installer un million de packages, ni de lire un million d’articles pour rester compétitif. En réalité, votre enthousiasme pourrait vous faire plus de mal que de bien.

Je ne suis pas là pour faire du tourisme — j’ai commencé à utiliser ces outils quand ils se sont à peine mis à écrire du code. J’ai testé tous les packages, tous les harness, toutes les paradigmes. J’ai utilisé des factories d’agents pour écrire des signaux, des infrastructures, des pipelines de données — pas des « projets jouets », mais des cas concrets en production. Après tout ça…

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

Comprendre que le monde évolue à grande vitesse

Tout d’abord, je tiens à dire que les entreprises de modèles fondamentaux sont en pleine course révolutionnaire, et il est évident que cela ne ralentira pas de sitôt. Chaque amélioration de « l’intelligence agentique » modifie votre façon de collaborer avec eux, car ils sont conçus pour suivre de plus en plus facilement vos instructions.

Il y a seulement 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 obéit à la majorité des instructions, y compris celles avec des instructions imbriquées complexes — par exemple, vous pouvez dire « Lis A d’abord, puis B, si C, alors D », et il suivra généralement.

Que cela signifie-t-il ? La règle la plus importante est de comprendre que chaque nouvelle génération d’agent vous oblige à repenser ce qui est la meilleure solution, ce qui explique pourquoi moins c’est souvent plus.

Lorsque vous utilisez de nombreux packages et harness différents, vous vous enfermez dans une « solution » unique, mais ce problème pourrait ne pas exister avec la prochaine génération d’agents. Savez-vous qui sont les utilisateurs les plus enthousiastes et les plus gros consommateurs d’agents ? Exactement — ce sont les employés des entreprises à la pointe, qui disposent d’un budget illimité de tokens et utilisent les modèles les plus récents. Comprenez-vous ce que cela implique ?

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

Donc, si quelque chose est vraiment révolutionnaire et peut étendre de manière significative les cas d’usage des agents, cela finira tôt ou tard dans le cœur des produits de base des grandes entreprises. Faites-moi confiance, ces entreprises avancent à toute vitesse. Alors détendez-vous : vous pouvez produire d’excellents résultats sans installer quoi que ce soit ni dépendre d’outils externes.

Je prévois que dans les commentaires, quelqu’un dira bientôt : « 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 un groupe extrêmement restreint, celui qui comprend vraiment l’ingénierie des agents.

Le contexte, c’est tout

Sérieusement. Le contexte, c’est tout. Un autre problème avec l’utilisation de milliers de plugins et dépendances externes, c’est que vous souffrez du « gonflement du contexte » — c’est-à-dire que votre agent est noyé sous une masse d’informations.

Je peux faire un jeu de devinettes en Python ? Facile. Attendez, qu’est-ce que cette note « gestion de la mémoire » avant 26 conversations ? Ah, l’utilisateur a bloqué un écran à 71 conversations parce qu’on a généré trop de sous-processus. Toujours écrire des notes ? D’accord… mais ça, ça n’a rien à voir avec le jeu de devinettes, si ?

Vous voyez. Vous voulez simplement 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 le comportement de 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 fabriquer une bombe ou une recette pour faire un gâteau — alors que vous voulez juste qu’il écrive un petit poème sur la forêt de séquoias.

Donc, je prêche encore une fois — éliminez toutes les dépendances, puis…

Faites quelque chose de vraiment utile

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

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

Vous vous souvenez que vous voulez injecter à l’agent l’information exacte pour accomplir la tâche, ni plus ni moins ?

La première méthode pour y parvenir, c’est de séparer recherche et exécution. Vous devez être extrêmement précis sur ce que vous demandez à l’agent.

Quelles sont les conséquences d’une demande imprécise ? « 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 aller chercher en ligne une multitude d’informations, souvent inutilisables, et remplir le contexte de détails sur différentes implémentations possibles. Lorsqu’il s’agit de réaliser réellement, il sera plus confus ou aura des illusions inutiles ou hors sujet sur la solution choisie.

Inversement, si vous dites « Utilise bcrypt-12 pour le hachage de mot de passe, implémente JWT, 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 connaîtrez pas toujours tous les détails techniques. Souvent, vous ne savez pas ce qui est correct, et parfois vous souhaitez même confier à l’agent la décision sur la solution à adopter. Que faire dans ce cas ? Très simple : créez une tâche de recherche pour explorer différentes options, soit en décidant vous-même, soit en demandant à l’agent de choisir la meilleure solution, puis faites réaliser cette décision par un autre agent avec un contexte totalement renouvelé.

Une fois que vous commencez à penser ainsi, vous repérerez où le flux de travail est pollué inutilement par le contexte de l’agent. Vous pourrez alors mettre en place des barrières dans votre flux, pour abstraire les informations inutiles, ne laissant que le contexte spécifique nécessaire pour que l’agent excelle dans sa tâche. Rappelez-vous : vous avez une équipe très talentueuse, intelligente, qui connaît toutes sortes de sphères — mais sauf si vous lui indiquez que vous souhaitez concevoir un espace où l’on peut danser et s’amuser, il continuera à vous parler 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. C’est pourquoi ces agents essaient de vous approuver, de faire ce que vous leur demandez.

Si vous leur demandez d’ajouter un « happy » toutes les trois mots, ils feront de leur mieux — c’est compréhensible. Leur obéissance est ce qui en fait des outils si efficaces. Mais cela a une caractéristique très intéressante : cela signifie que si vous dites « Trouve-moi un bug dans le code », ils en trouveront — même si cela implique d’en « fabriquer » un. Pourquoi ? Parce qu’ils veulent vraiment suivre vos instructions !

La plupart des gens se plaignent rapidement des hallucinations et de la fabrication de choses inexistantes par les LLM, sans réaliser que le problème vient d’eux-mêmes. Vous demandez ce qu’ils doivent faire, ils vous livrent — même si cela nécessite de déformer légèrement la réalité !

Que faire alors ? J’ai découvert 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 « Parcours 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 comment le code fonctionne. Mais il n’orientera pas l’agent vers l’hypothèse qu’il y a un bug.

Une autre façon de gérer cette tendance à plaire, c’est de la transformer en avantage. Je sais que l’agent essaie de me satisfaire, de suivre mes instructions, je peux donc orienter ses réponses dans un sens ou dans l’autre.

Par exemple, je demande à un agent de détection de bugs d’identifier tous les bugs dans une base de données, en lui attribuant un score : un bug mineur vaut +1, un bug moyen +5, un bug grave +10. Je sais que cet agent sera très enthousiaste à l’idée d’identifier tous types de bugs (y compris ceux qui ne sont pas vraiment des bugs), et me rapportera un score total de 104 ou plus. Je considère cela comme un ensemble superposé de tous les bugs possibles.

Ensuite, je fais intervenir un agent adversaire, qui doit contester, en lui disant que chaque bug qu’il réfute lui rapporte le score du bug, mais si il se trompe, il doit -2 fois ce score. Cet agent s’efforcera de réfuter autant de bugs que possible, mais avec une pénalité pour éviter de faire n’importe quoi. Il continuera à « réfuter » des bugs (y compris de vrais bugs). Je considère cela comme un sous-ensemble de tous les bugs réels.

Enfin, je fais intervenir un arbitre, qui combine leurs réponses et attribue 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 selon ces deux agents. En vérifiant ce que dit la vérité, cette méthode est étonnamment précise, parfois erronée, mais c’est presque une opération sans erreur.

Vous pourriez penser qu’un seul agent de détection de bugs suffit, mais cette méthode fonctionne très bien pour moi, 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, comme si vous deviez apprendre en profondeur, suivre en permanence l’état de l’art en IA. Mais en réalité, c’est très simple… si OpenAI et Claude l’ont implémenté ou ont racheté la société qui l’a fait, c’est probablement utile.

Avez-vous remarqué que « skills » (compétences) sont partout, et qu’elles font partie de la documentation officielle de Claude et Codex ? Avez-vous vu qu’OpenAI a racheté OpenClaw ? Avez-vous vu que Claude a rapidement ajouté la mémoire, la voix, le travail à distance ?

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

Oui, tout cela est utile !

Vous vous souvenez aussi des stop-hooks infinis, super utiles, parce que l’agent est très réticent à faire des tâches longues… puis, avec la sortie de 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 le réaliseront eux-mêmes ! Donc, pas besoin de vous inquiéter de « l’adopter » ou de « connaître la dernière version » — vous n’avez même pas besoin de « rester à jour ».

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

Compression, contexte et hypothèses

Certains rencontrent un piège énorme en utilisant des agents : parfois, ils semblent être les êtres les plus intelligents de la planète, et parfois, vous ne pouvez pas croire qu’on vous ait encore une fois dupé.

« 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, ils sont encore très mauvais pour faire des liens, combler des lacunes ou faire des hypothèses. Dès qu’ils le font, on le voit immédiatement, et la situation se dégrade nettement.

Une des règles les plus importantes dans CLAUDE.md concerne comment obtenir le contexte, et indique à l’agent, à chaque lecture de CLAUDE.md (c’est-à-dire après chaque compression), de commencer par 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 la tâche, et avant de continuer, relire les fichiers liés à la tâche.

Comment indiquer à l’agent comment terminer une tâche

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

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

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

Ensuite, vous vérifiez simplement que tous les tests sont passés, et vous pouvez être rassuré. Vous pouvez aussi automatiser cela, mais l’essentiel est — rappelez-vous que « finir une tâche » est naturel pour un humain, mais pas pour un agent.

Savez-vous ce qui est devenu une étape de fin de tâche réalisable 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 que le design ou le comportement est conforme.

Cela vous permet de faire itérer l’agent vers le design souhaité, sans craindre qu’il s’arrête après la première tentative !

Une extension naturelle consiste à faire créer à l’agent une « contrat » (contract), et à l’intégrer dans les 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, les 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 s’assurant qu’il ne dévie pas.

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

Si vous avez 100 contrats bien définis, contenant tout ce que vous souhaitez construire, alors le stop-hook empêchera l’agent de terminer tant que tous ces contrats ne sont pas remplis, y compris tous les tests et validations.

Conseil professionnel : je trouve que faire tourner un agent 24h/24 n’est pas optimal. En partie parce que cette approche introduit structurellement un gonflement du contexte, puisque tous les contrats non liés entrent dans la même session.

Je ne recommande pas cette méthode.

Une meilleure approche d’automatisation consiste à ouvrir une nouvelle session pour chaque contrat. Chaque fois que vous avez besoin de faire quelque chose, créez un contrat.

Mettez en place une couche d’orchestration qui crée un nouveau contrat quand il faut faire quelque chose, et ouvre une nouvelle session pour gérer ce contrat.

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

Itérer, encore et encore

Vous embauchez un assistant administratif, vous attendez qu’il connaisse votre emploi du temps dès le premier jour ? Ou que vous sachiez comment boire votre café ? Que vous dîniez à 18h au lieu de 20h ? Évidemment non. Vous construisez vos préférences au fil du temps.

L’agent fonctionne pareil. Commencez avec une configuration très simple, oubliez la complexité ou les architectures avancées, 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 de suivre cette règle. Par exemple : « Avant d’écrire du code, lire coding-rules.md. » Les règles peuvent être imbriquées, conditionnelles ! Si vous écrivez du code, lisez coding-rules.md ; si vous écrivez un test, lisez coding-test-rules.md. Si le test échoue, lisez coding-test-failing-rules.md. Vous pouvez créer des règles avec des branches logiques, et Claude (et Codex) suivront volontiers, à condition que ce soit clairement indiqué dans CLAUDE.md.

En fait, c’est ma première recommandation concrète : traitez votre CLAUDE.md comme un répertoire logique, imbriqué, indiquant où chercher le contexte dans des scénarios et résultats spécifiques. Il doit être aussi simple que possible, contenant uniquement une logique IF-ELSE sur « dans quelle situation aller chercher où ».

Si vous voyez l’agent faire quelque chose que vous désapprouvez, ajoutez une règle pour lui dire de relire cette règle avant de refaire cette action. Il ne le refera probablement plus.

Compétences (Skills)

Les compétences (Skills) ressemblent aux règles, mais plutôt qu’un style de codage, elles représentent une « étape opérationnelle » spécifique. Si vous souhaitez qu’une tâche soit réalisée d’une certaine façon, vous pouvez l’intégrer dans une compétence.

En réalité, beaucoup se plaignent de ne pas savoir comment l’agent résoudra un problème, ce qui peut être inquiétant. Si vous voulez que ce soit certain, faites d’abord étudier à l’agent comment il résoudrait ce problème, puis écrivez cette solution dans un fichier de compétence. Vous pourrez ainsi anticiper la façon dont l’agent traitera ce problème, et le corriger ou l’améliorer avant qu’il ne le rencontre réellement.

Comment faire connaître cette compétence à l’agent ? Facile : dans CLAUDE.md, indiquez que lorsque vous rencontrez ce scénario, vous lisez SKILL.md.

Gérer règles et compétences

Vous aurez sûrement envie d’ajouter constamment des règles et compétences. C’est ainsi que vous lui donnez de la personnalité et enregistrez vos préférences. 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.

Puis…

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 l’agent souffre d’un gonflement du contexte. Si vous demandez à l’agent de lire 14 fichiers markdown avant de commencer à coder, vous aurez le même problème d’informations inutiles.

Que faire ?

Nettoyez. Faites en sorte que votre agent « fasse un spa », en intégrant règles et compétences, en lui demandant de mettre à jour ses préférences pour éliminer les contradictions.

Et là, il semblera à nouveau magique.

C’est tout. C’est vraiment la clé : rester simple, utiliser règles et compétences, traiter CLAUDE.md comme un répertoire, et faire attention à ses limites de conception et de contexte.

Assumer la responsabilité des résultats

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 devez en assumer la responsabilité.

Soyez donc prudent… et profitez-en pleinement !

Jouer avec des jouets du futur (tout en utilisant clairement ces outils pour des tâches sérieuses) est une vraie joie !