Dual-Brain — une compétence qui ajoute un workflow de débat « cerveau gauche / cerveau droit » à Codex/Claude Code

Bonjour. En utilisant récemment Codex ou Claude Code en conditions réelles, je voulais présenter Dual-Brain, un protocole de compétence d’extension en cours de développement en open source pour réduire les problèmes où les LLM se retrouvent facilement surchargés lorsqu’ils écrivent du code complexe, ou reviennent sur des décisions passées.

Dual-Brain se rapproche moins d’une méthode qui attribue à l’IA des rôles comme « PM / développeur / QA » que d’une séparation des fonctions cognitives utilisées pour examiner un problème.

Au lieu qu’un seul agent donne immédiatement une réponse, on l’oblige à faire passer la demande, dans l’ordre, par un interrogatoire contextuel joué par le cerveau droit puis par une validation logique jouée par le cerveau gauche, avant qu’un orchestrator ne synthétise le résultat final.

1. Les 3 modes d’échec classiques d’une exécution mono-agent

Quand on confie d’un seul coup à un LLM, dans le terminal, une conception d’architecture complexe ou un refactoring, on rencontre souvent les problèmes suivants.

• Le piège de la lecture littérale
  Il accepte tel quel un besoin ambigu, puis construit avec assurance un code à côté de la plaque.
• L’enfer des détails
  Il se noie dans la syntaxe micro du code et les edge cases, et passe à côté d’une voie architecturale plus simple et meilleure.
• La boucle d’amnésie
  Une fois la session terminée, le contexte précédent disparaît, et une direction architecturale déjà décidée la semaine passée est de nouveau remise en cause à la session suivante.

2. La solution : deux fonctions de pensée

Quand on charge Dual-Brain, l’agent principal prend le rôle d’orchestrator et ne répond pas immédiatement. À la place, il exécute deux étapes internes de revue, dans un ordre prédéfini.

• Cerveau droit, Right Brain : contexte / motifs / interrogation
  Il ne met pas en œuvre immédiatement la demande de l’utilisateur, mais commence par la remettre en question. Il examine des points comme : « Quel est l’angle mort de cette exigence ? », « Est-ce en conflit avec des décisions passées ? », « La terminologie est-elle ambiguë ? ».
• Cerveau gauche, Left Brain : logique / validation / code
  Il confronte la définition du problème produite par le cerveau droit au codebase réel, à la documentation officielle et à la mémoire du projet. Il filtre les API hallucinées, les hypothèses obsolètes et les conceptions impossibles à implémenter, puis affine le tout sous une forme exécutable.

Au final, l’orchestrator fusionne les deux résultats pour enchaîner sur les modifications de code, la documentation et même la mise à jour de la mémoire.

3. Le système de niveaux de mémoire

La compétence stocke la mémoire de long terme dans .dual-brain/MEMORY.md à la racine du projet.

Mais plus le projet grossit, plus on risque de voir se mélanger avec le même poids des décisions anciennes et des contraintes actives de la semaine passée. Pour résoudre ce problème, la mémoire n’est pas traitée comme un document plat mais comme une mémoire à niveaux.

• Hot Memory
• Warm Memory
• Cold Memory
• Archived Decisions

La Hot Memory contient les décisions actives et contraintes qui influencent fortement le travail en cours.

La Warm Memory contient un contexte utile qui n’est lu que pour des tâches liées.

La Cold Memory et les Archived Decisions ne sont pas toutes lues par défaut, et ne sont consultées qu’en cas de recherche par mot-clé ou lorsqu’une vérification de conflit est nécessaire.

refs n’augmente pas simplement parce qu’un élément a été lu, mais uniquement lorsqu’il a réellement influencé une question, une validation, une synthèse ou une implémentation.

Les souvenirs anciens ou redondants sont compressés automatiquement, et les décisions contradictoires ou abandonnées sont envoyées dans Archived.

Les informations sensibles, tokens, clés et données personnelles ne sont ni stockés ni résumés, mais traités comme des éléments à supprimer ou à ne pas conserver.

Le point important est que la mémoire n’est pas la source de vérité. Dans Dual-Brain, la mémoire est un contexte consultatif, et le code actuel ainsi que la documentation officielle priment sur une mémoire obsolète.

4. Benchmark

Le repo inclut, pour Codex, un petit benchmark harness qui compare l’approche single-agent et l’approche Dual-Brain.

Dual-Brain n’est pas une approche rapide. Au contraire, son objectif est de faire davantage réfléchir en amont, afin de réduire ensuite les boucles où l’humain doit revenir corriger et réexpliquer.

5. Installation

Si vous utilisez SkillsGate, vous pouvez installer et gérer la compétence dans les environnements Codex CLI et Claude Code.

npx skillsgate add sleeplesshan/dual-brain -g  
Installation manuelle également possible.  
 - Codex  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.codex/skills/dual-brain  
 - Claude Code  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.claude/skills/dual-brain  
Après l’installation, il suffit de l’appeler en langage naturel comme d’habitude.  
  
6. Quand l’utiliser  
Dual-Brain est excessif pour des modifications simples. Il n’est pas nécessaire de l’utiliser pour un renommage de variable, une correction de bug sur une ligne ou du boilerplate clair.  
À la place, il convient bien dans les situations suivantes.  
- refactoring avec des exigences ambiguës  
- décision d’architecture  
- intégration d’une API ou d’un SDK inconnu  
- changement susceptible d’entrer en conflit avec des décisions passées  
- travail où une API hallucinée pourrait mener à une panne réelle  
- travail du type « je ne suis même pas sûr de poser la bonne question en ce moment »  
  
L’ensemble du `SKILL.md` et le benchmark harness sont publiés en open source (licence MIT).  
Je serais ravi d’avoir les retours de celles et ceux qui s’intéressent à l’orchestration de LLM, au prompt engineering et à la conception de la mémoire d’agent.