Context engineering : compaction, passations, resets et thinking effort

Vue d'ensemble

Le context engineering est la gestion active de ce que l'agent tient à l'instant. Quatre leviers font l'essentiel du travail. La compaction résume une longue conversation pour libérer la fenêtre, mais la version automatique laisse silencieusement tomber des choses qui vous importaient, alors vous la pilotez. Une passation transmet un résumé propre à une session fraîche. Un reset jette un contexte confus et repart d'un prompt net. Et le thinking effort échange coûts contre profondeur sur les problèmes vraiment durs. Maîtrisez ces quatre, et les longues tâches restent tranchantes, au lieu de dériver dans la confusion.

Ce que vous allez apprendre

Vous allez apprendre pourquoi l'auto-compaction est un piège et comment compresser à vos propres conditions, comment réinjecter votre objectif pour que l'agent ne dérive pas après un résumé, comment écrire un document de passation qui laisse une session fraîche continuer sans perdre le fil, comment reconnaître quand un reset bat une nouvelle ronde de rustines, et comment régler le thinking effort pour ne payer un reasoning profond que quand la tâche le mérite.

Prérequis

La leçon sur les tokens, le contexte et le performance cliff du Cours 1 et une vraie expérience des tâches multi-étapes, assez longue pour avoir senti une session devenir floue. Ces techniques ne comptent qu'une fois les sessions longues, donc la leçon sur les sub-agents juste avant est une introduction naturelle - les sub-agents gèrent le contexte entre agents, cette leçon le gère à l'intérieur d'un.

Le problème

Vous êtes profondément dans une longue tâche. Le context window se remplit, et à un moment le harness compresse automatiquement - il résume la conversation jusque-là pour faire de la place. Soudain, l'agent semble différent. Il a oublié une décision que vous avez prise tôt, ou il optimise désormais le mauvais objectif, ou il contredit avec assurance quelque chose qu'il approuvait il y a une heure. L'auto-compaction a fait son travail mécaniquement : elle a fait de la place. Mais elle a résumé selon ses propres priorités, pas les vôtres, et a silencieusement laissé tomber la contrainte qui vous importait le plus. Vous n'avez pas choisi ce qui reste, donc vous avez perdu le fil sans vous en rendre compte.

Pourquoi l'auto-compaction nuit, et la piloter

L'auto-compaction n'est pas malveillante, elle est juste avec perte et mal chronométrée. Elle se déclenche quand la fenêtre est presque pleine, ce qui est le plus souvent le pire moment, en plein raisonnement, et elle comprime tout selon une heuristique générique qui ne connaît pas votre vrai objectif. Le résultat est une perte de qualité subtile que vous ne remarquez souvent qu'après que l'agent a dérivé. La solution est de prendre le contrôle du moment et du contenu. Compressez délibérément, à un point de rupture propre entre sous-tâches plutôt qu'en plein milieu d'une étape. Et juste après chaque compaction, réinjectez votre objectif : reformulez l'objectif, les contraintes centrales et l'état actuel en quelques lignes. Ce seul paragraphe réancre l'agent et défait l'essentiel de ce que la compaction a brouillé.

• Compressez à un point de rupture propre que vous choisissez, pas quand la fenêtre le force en plein milieu de la tâche.
• Après la compaction, réinjectez l'objectif : reformulez le but, les contraintes non négociables et où vous en êtes.
• Après un résumé, guettez la dérive - quand les réponses de l'agent semblent fausses, une contrainte perdue est la cause habituelle.
• Une CLAUDE.md aide aussi ici : les règles du fichier survivent parce qu'elles sont rechargées, contrairement aux points enfouis dans le chat.

Documents de passation

Parfois le coup le plus propre n'est pas de compresser mais de passer la main à une session fraîche à la fenêtre propre. L'outil pour cela est un document de passation : un court fichier markdown que vous faites écrire par l'agent et qui consigne tout ce dont la prochaine session a besoin. Bien fait, un nouvel agent lit la passation et est aussitôt aussi informé que l'ancien, mais avec un contexte vide et tranchant. C'est de loin le moyen le plus fiable de mener un travail bien trop long pour une fenêtre, sans la dégradation de qualité, et c'est aussi un protocole que vous pouvez donner à un coéquipier.

# Handover: Checkout flow refactor

## Goal
Move checkout from the old form to Stripe embedded checkout. Must keep the
existing success page and not change the cart.

## Done so far
- Added the Stripe SDK and the new checkout component.
- Wired the create-session endpoint (see src/api/checkout.ts).

## Current state / next step
- The embedded form renders but the redirect after payment 404s.
- Next: fix the return_url in checkout.ts to point at /order/success.

## Constraints (do not forget)
- TypeScript only, run the quality gate before pushing.
- Never log the Stripe secret key.

Demandez à l'agent de l'écrire avant de terminer une longue session, puis collez-le dans un chat frais pour continuer. La nouvelle session démarre avec une fenêtre propre et un brief précis, ce qui est presque toujours plus tranchant que de pousser une session boursouflée pour une ronde de plus.

Quand réinitialiser

Un reset consiste à repartir d'un prompt frais et focalisé en abandonnant le contexte actuel. Cela sonne comme jeter du travail, mais c'est souvent le chemin le plus rapide vers l'avant. Quand un agent boucle sur le même fix raté, se contredit ou porte un contexte si boursouflé que chaque réponse est médiocre, plus de rustines aide rarement - vous vous disputez avec une fenêtre confuse. Réinitialisez plutôt. Prenez ce que vous avez appris, écrivez un prompt net ou une passation et repartez propre. Le signal est simple : si vous avez expliqué deux fois la même chose et que ça ne passe toujours pas, le contexte est le problème, pas l'instruction. Un reset le nettoie.

Thinking effort

Le thinking effort est la quantité de raisonnement délibéré que le modèle fait avant de répondre. Plus d'effort signifie qu'il travaille le problème plus soigneusement, ce qui coûte plus de tokens et de temps, mais élève la qualité sur les tâches vraiment dures - debugging délicat, décisions d'architecture, logique subtile. Moins d'effort convient au travail de routine où un reasoning profond est de l'argent gaspillé. La règle pratique reflète le choix de modèle du Cours 1 : montez l'effort pour les 20 pour cent durs qui en ont vraiment besoin, et gardez-le bas pour les 80 pour cent faciles. Vous pouvez fixer un défaut et le relever par tâche. Payer un reasoning maximal pour un renommage ou une passe de formatage est la même erreur que faire coller un pansement par une chirurgienne.

• Effort élevé : debugging dur, architecture, logique subtile - les cas où un raisonnement soigné change la réponse.
• Effort bas : modifications de routine, formatage, refactors simples - la profondeur est ici de l'argent gaspillé.
• Adaptez l'effort à la difficulté, exactement comme vous adaptez le palier de modèle à la difficulté.
• L'effort et un modèle puissant s'additionnent : réservez les deux aux problèmes vraiment durs.

Erreurs fréquentes

Les récurrentes : laisser l'auto-compaction se déclencher et ne jamais réinjecter l'objectif, si bien que l'agent dérive silencieusement ; pousser une session confuse et boursouflée ronde après ronde quand un reset aurait été plus rapide ; ne jamais écrire de passation, si bien que chaque longue tâche pourrit au lieu de continuer proprement ; et brûler un thinking effort maximal sur du travail trivial en vous demandant pourquoi la facture est haute. La méta-erreur est de traiter le contexte comme quelque chose qui vous arrive, au lieu de quelque chose que vous engineerez activement.

ROI business

Le context engineering est ce qui rend le gros travail agentique de plusieurs heures vraiment fiable au lieu d'un lent glissement dans la confusion. Compresser à vos conditions, passer la main proprement et réinitialiser au bon moment gardent la qualité de l'output haute sur des tâches bien plus grandes qu'une fenêtre - ce qui signifie moins de reprise et moins de bugs subtils d'un agent qui dérive. Adapter le thinking effort à la difficulté pilote les coûts directement. Pour une fondatrice qui mène de vrais workflows, ces habitudes sont la différence entre un travail agentique qui passe à l'échelle et un travail agentique qui pourrit silencieusement à mesure qu'il tourne.

Checklist

Vous êtes prêt à avancer quand chacun de ces points est vrai. La dernière leçon assemble le setup pro qui rend tout cela fluide au quotidien.

• Vous savez expliquer pourquoi l'auto-compaction nuit et ce que fait la réinjection de l'objectif.
• Vous savez faire écrire un document de passation par l'agent et continuer dans une session fraîche.
• Vous connaissez les signaux qui veulent dire reset plutôt que rustine.
• Vous adaptez le thinking effort à la difficulté de la tâche, au lieu de toujours le maximiser.

Ressources

Gardez en favoris la documentation de Claude Code sur la gestion du contexte et les commandes compact et clear pour le comportement et les flags à jour. Gardez un template de passation dans votre bibliothèque de ressources, pour qu'en écrire une soit une habitude de deux minutes. Votre CLAUDE.md est votre assurance contre la perte de compaction, car les règles du fichier sont rechargées, tandis que les points enfouis dans le chat ne le sont pas.

Votre mission

À votre prochaine longue tâche, faites deux choses délibérément. Quand la fenêtre se remplit, compressez vous-même à un point de rupture propre puis réinjectez votre objectif en un court paragraphe. Plus tard, faites écrire un document de passation par l'agent, ouvrez une session fraîche, collez-le et continuez. Remarquez à quel point la session fraîche semble plus tranchante. Vous venez d'engineerer votre contexte, au lieu de le laisser vous engineerer.

Prochaine leçon

Vous savez gérer règles, skills, hooks, MCP, travail multi-agent et contexte. La dernière leçon de ce cours assemble le setup pro qui relie tout : une Status Line personnalisée, la poignée de flags CLI que vous utilisez chaque jour, et lancer des sessions depuis votre téléphone ou le cloud, pour que construire ne soit pas attaché à un bureau.