La feedback loop qui rend ton agent Claude Code plus intelligent

Tu corriges le même bug trois fois. Claude Code continue de générer des styles inline alors que ton projet utilise Tailwind. Tu corriges, il ajuste, session suivante il a oublié. Construire une feedback loop Claude Code qui persiste les corrections entre les sessions, c'est ce qui sépare du prompting one-off frustrant d'un workflow qui compose vraiment.

La plupart des développeurs traitent les sessions Claude Code comme des événements isolés. Ils promptent, corrigent, livrent, ferment le terminal. Ce que l'agent a appris dans cette session s'évapore. Puis ils se demandent pourquoi leur assistant IA ne s'améliore jamais.

Les développeurs qui tirent le plus de l'agentic coding font autrement. Ils construisent des feedback loops qui persistent entre les sessions, pour que chaque correction compose vers un baseline plus intelligent pour la suivante.

À quoi ressemble vraiment une feedback loop Claude Code

Le terme est balancé à toutes les sauces, alors soyons précis. Une feedback loop, c'est n'importe quel mécanisme qui prend une correction d'une session et la rend disponible aux sessions futures. Il y a trois couches, et la plupart des gens n'en utilisent que la première.

Couche 1 : corrections de session. Tu dis à Claude Code « utilise les classes Tailwind, pas les styles inline ». Il ajuste immédiatement. C'est réactif et temporaire. La correction vit dans le contexte de conversation et meurt quand la session se termine.

Couche 2 : instructions persistantes. Tu écris cette même correction dans ton fichier CLAUDE.md. Maintenant chaque session future démarre avec cette connaissance. C'est là que la composition commence.

Couche 3 : guardrails systémiques. Ton linter signale les styles inline. Ta suite de tests rattrape les régressions. Ton système de types empêche les états impossibles. Ces outils agissent comme un feedback automatisé que l'agent lit et auquel il réagit sans que tu aies à dire un mot.

La plupart des développeurs vivent entièrement dans la Couche 1. Ils corrigent Claude Code des dizaines de fois par session et ne persistent jamais rien. C'est comme onboarding un nouveau collègue chaque matin de zéro.

Les corrections de session sont nécessaires mais pas suffisantes

Je ne dis pas que le feedback de session n'a pas d'importance. Si. Quand Claude Code fait un mauvais choix d'architecture en pleine session, une correction rapide le recadre. L'agent est bon pour ajuster dans une conversation.

Le problème, c'est le scope. Les corrections de session ne durent que le temps de la context window. Ferme le terminal, et l'ardoise est nette. J'ai passé des semaines à corriger les mêmes motifs avant de réaliser le vrai problème : j'enseignais les mêmes leçons en boucle parce que je ne les écrivais jamais.

CLAUDE.md : la mémoire long terme de ton agent

C'est le fichier au plus fort levier dans un workflow agentic. Quand Claude Code démarre une session, il lit ton CLAUDE.md avant de faire quoi que ce soit d'autre. Ce qui est dedans devient partie de sa connaissance de travail.

L'erreur que je vois le plus souvent : les gens traitent CLAUDE.md comme un README. Descriptions générales du projet, guidelines vagues, overviews d'architecture. Ce n'est pas du feedback utile. L'agent a besoin d'instructions spécifiques et actionnables qui préviennent des erreurs concrètes.

Voici à quoi ressemble un feedback CLAUDE.md inefficace :

- Use good coding practices
- Follow the project conventions
- Write clean code

Voici à quoi ressemble un feedback CLAUDE.md efficace :

- All styling uses Tailwind utility classes. Never generate inline styles or CSS modules.
- Form validation uses Zod schemas from @jd/shared. Never write inline validation logic.
- Database queries go through TRPC routers. Never create REST API routes for data.

Chaque ligne représente une correction que j'ai faite pendant une session et que j'ai ensuite promue en instruction permanente. Le pattern est simple : corriger une fois en session, puis se demander si cette correction devrait survivre à la session. Si oui, elle va dans CLAUDE.md.

Après trois mois de cette pratique, mon CLAUDE.md est devenu une carte détaillée de chaque décision architecturale, convention de nommage, et anti-pattern du codebase. Les nouvelles sessions démarrent d'un baseline bien plus haut qu'au début.

Garder CLAUDE.md fin, déléguer la profondeur

Une fois que CLAUDE.md dépasse une page ou deux, l'agent brûle du contexte sur des règles non pertinentes pour la tâche en cours. Le fix est un second pattern qui se couple au premier : traiter CLAUDE.md comme un point d'entrée fin et déléguer les instructions détaillées à des fichiers spécialisés sous .ai-rules/. Chaque fichier n'est ramené que quand l'agent touche à ce domaine, donc le point d'entrée reste focus et chaque sujet obtient la profondeur qu'il mérite.

Le point d'entrée finit par ressembler à ça :

## Detailed rules
 
- API routes: @.ai-rules/api-routes.md
- Database migrations: @.ai-rules/supabase-database.md
- Testing strategy: @.ai-rules/testing.md
- TRPC conventions: @.ai-rules/trpc-api.md

Le préfixe @ dit à Claude Code de récupérer le fichier référencé à la demande. Ton CLAUDE.md reste sous quelques centaines de lignes, mais l'agent peut plonger dans un ruleset spécialisé au moment où une tâche touche ce domaine. Les migrations ont leur propre page de conventions de schéma, TRPC a son propre fichier sur les patterns de router, et aucun des deux ne dispute le contexte sur un changement non lié.

Je creuse plus loin la construction de couches de feedback persistantes dans le cours d'agentic coding. Le chapitre sur le context engineering couvre comment structurer ton projet pour que l'agent s'améliore automatiquement.

Feedback systémique : laisse ton tooling faire le coaching

La troisième couche est celle que la plupart des gens ignorent complètement. Ton linter, ton type checker et ta suite de tests sont des feedback loops qui tournent automatiquement. Claude Code lit leur output et ajuste.

Quand ESLint signale un import non utilisé, Claude Code le retire. Quand TypeScript jette une erreur de type, Claude Code corrige le mismatch. Quand un test échoue, Claude Code lit le message d'échec et tente un fix. Ce ne sont pas que des outils développeur. Ce sont des signaux de coaching pour agent.

L'implication pratique : plus tu investis dans le tooling automatisé de ton projet, mieux ton agent performe. Une config ESLint stricte n'est pas que pour ton équipe. C'est un set d'instructions en temps réel pour ton agent IA. Une suite de tests complète n'est pas qu'un filet de sécurité. C'est un mécanisme de feedback qui rattrape les erreurs avant qu'elles n'atteignent ta review.

J'ai ajouté un pre-commit hook qui tourne le type checking et le linting. Claude Code le déclenche à chaque commit. Le hook rejette le mauvais code, Claude Code lit le rejet, et il corrige le souci avant même que je le voie. Ça, c'est une feedback loop qui tourne sans mon implication.

L'effet composé

Voici ce qui se passe après quelques semaines à maintenir les trois couches.

Semaine une : tu corriges Claude Code constamment. Chaque session ressemble à du babysitting. Tu construis des corrections Couche 1 et commences à en promouvoir certaines dans CLAUDE.md.

Semaine quatre : l'agent suit tes conventions la plupart du temps. CLAUDE.md a accumulé assez de corrections pour que les erreurs communes soient parties. Tu commences à focus les corrections sur les cas limites et les subtilités architecturales.

Semaine douze : les nouvelles sessions se sentent qualitativement différentes. L'agent comprend les patterns de ton projet, respecte tes frontières, et rattrape ses propres erreurs via la suite de tests. Ton rôle passe de corriger à reviewer.

C'est l'effet composé. Chaque correction, une fois persistée, empêche cette erreur de revenir. Sur des semaines et des mois, les corrections accumulées créent un agent qui semble « connaître » ton projet. Il ne connaît rien en réalité. Il lit un document qui contient tout ce que tu lui as appris.

Les développeurs qui abandonnent Claude Code après une semaine ratent ça complètement. Ils n'expérimentent que la Couche 1, se frustrent de la répétition, et concluent que l'outil n'est pas prêt. L'outil est prêt. Le système de feedback, non.

Commence petit

Tu n'as pas besoin de refondre ton workflow du jour au lendemain. Commence par une pratique : à la fin de chaque session Claude Code, passe deux minutes à revoir ce que tu as corrigé. Si une correction serait utile dans les sessions futures, ajoute-la à CLAUDE.md. C'est tout.

Après une semaine, tu auras un CLAUDE.md qui reflète tes vrais patterns de travail, pas des best practices théoriques. Après un mois, tu remarqueras que l'agent fait moins d'erreurs. Après trois mois, tu te demanderas comment tu as pu travailler sans.

La feedback loop est la fondation de chaque technique que je couvre dans le cours d'agentic coding. Si cette approche résonne, le cours va bien plus loin sur chaque couche. Démarrer le cours.