Humanize : une boucle Ralph-Loop où Claude code et Codex relit

Le problème : un agent seul juge mal son propre travail

Un agent qui écrit du code et qui valide ce même code partage ses propres angles morts. Humanize attaque ce point précis en séparant les rôles : Claude implémente, Codex relit. Le README résume la boucle par la formule "One Build + One Review", et le nom RLCR signifie Ralph-Loop with Codex Review, avec une seconde lecture possible du sigle, Reinforcement Learning with Code Review. Le public visé n'est pas le développeur qui tape une requête ponctuelle dans un chat : c'est celui qui mène une fonctionnalité de bout en bout et veut un cycle court entre proposition, critique et correction. Le projet se présente comme dérivé de GAAC (GitHub-as-a-Context), et son dépôt indique le Shell comme langage principal, ce qui situe l'outillage du côté de l'orchestration de commandes plutôt que d'une bibliothèque embarquée. Rien dans le matériel fourni ne permet de dire combien de personnes l'utilisent, ni sur quels types de bases de code il a été éprouvé.

Deux phases, et une relecture qui note la sévérité

Le README décrit deux phases qui alternent. Pendant l'implémentation, Claude travaille et Codex relit des résumés. Pendant la revue de code, Codex examine la qualité du code et marque les problèmes par niveau de sévérité. Les problèmes identifiés sont renvoyés vers la phase d'implémentation jusqu'à résolution. Le schéma docs/images/rlcr-workflow.svg illustre ce flux, mais son contenu n'est pas reproduit dans le texte fourni, donc la mécanique exacte de remontée (fichier de suivi, file d'attente, format des marqueurs) reste à vérifier dans docs/usage.md. Ce que le matériel permet d'affirmer, c'est que la boucle ne s'arrête pas sur un nombre fixe de tours mais sur l'atteinte des critères d'acceptation, ce qui déplace le problème : la qualité du résultat dépend d'abord de la qualité de ces critères. Un mode Swarm est mentionné, présenté comme une parallélisation optionnelle via Agent Teams, sans détail sur la façon dont les agents se répartissent le travail ni sur la gestion des conflits d'écriture.

Begin with the End in Mind : le plan comme contrat

Le projet insiste sur un point qui n'est pas technique : avant de lancer la boucle, Humanize vérifie que vous comprenez le plan que vous allez exécuter. Le README formule cela par "The human must remain the architect", et renvoie à la section correspondante de docs/usage.md. C'est un choix de conception assumé, et il a un coût. Vous ne pouvez pas traiter cet outil comme une commande unique qui produit une fonctionnalité : il faut d'abord écrire ou générer un plan contenant des critères d'acceptation suffisamment explicites pour qu'un relecteur distinct puisse trancher. Si vos critères restent vagues, la revue Codex n'aura pas de base solide et la boucle enchaînera les tours sans convergence claire. C'est la limite structurelle du modèle, pas un défaut d'implémentation.

Installation et enchaînement des commandes

L'installation passe par le marketplace de plugins Claude Code, en trois commandes données dans le README. Pour la version stable : /plugin marketplace add PolyArch/humanize puis /plugin install humanize@PolyArch. Une variante existe pour la branche de développement, /plugin marketplace add PolyArch/humanize#dev, présentée comme contenant des fonctionnalités expérimentales. Le prérequis explicite est codex CLI, nécessaire pour la relecture, avec un renvoi vers docs/install-for-claude.md pour les prérequis complets et les options d'installation alternatives. L'enchaînement type commence par /humanize:gen-idea "add undo/redo to the editor", qui écrit par défaut dans .humanize/ideas/<slug>-<timestamp>.md ; l'option --n contrôle le nombre de directions explorées en parallèle, avec 6 comme valeur par défaut d'après le README. Vous pouvez aussi passer un chemin .md pour étendre des notes existantes. Vient ensuite /humanize:gen-plan --input draft.md --output docs/plan.md, puis éventuellement /humanize:refine-plan --input docs/plan.md si des relecteurs ont annoté le plan avec les marqueurs CMT: ... ENDCMT, <cmt> ... </cmt> ou <comment> ... </comment>. La boucle démarre avec /humanize:start-rlcr-loop docs/plan.md. Un point d'attention : la commande gen-idea est marquée optionnelle, à sauter si vous avez déjà un brouillon.

Le moniteur, et pourquoi il vit hors de Claude Code

Le suivi se fait dans un autre terminal, et le README précise explicitement : not inside Claude Code. On charge le script avec source <path/to/humanize>/scripts/humanize.sh, ou on l'ajoute à son .bashrc ou .zshrc, puis on appelle humanize monitor rlcr pour la boucle, humanize monitor skill pour toutes les invocations de skills, humanize monitor codex ou humanize monitor gemini pour filtrer par outil. La séparation est logique : la boucle occupe la session Claude Code, donc l'observation doit venir d'ailleurs. Cela implique de gérer deux terminaux en parallèle, ce qui n'est pas anodin en usage quotidien. Le dépôt contient une capture docs/images/monitor.png, mais le matériel fourni ne décrit pas les colonnes ni les métriques affichées, donc je ne peux pas en dire davantage sur ce que le tableau de bord montre réellement. Un troisième outil apparaît ici : Gemini, via /humanize:ask-gemini, décrit comme une recherche web approfondie nécessitant Gemini CLI. Le README ne précise pas si cette commande est indispensable au fonctionnement de la boucle ou purement annexe.

Deux CLI à installer, et une licence à trancher

La dépendance à codex CLI est le point de friction principal. Humanize n'est pas un outil autonome : sans le CLI de relecture, la phase de revue n'a pas de relecteur, et c'est justement cette phase qui distingue le projet d'une simple boucle itérative. Il faut donc installer et maintenir au moins deux outils, Claude Code et codex CLI, avec leurs cycles de mise à jour respectifs, plus Gemini CLI si vous voulez ask-gemini. Le dépôt ne fournit aucune version publiée : le champ des releases récentes est vide, et l'installation se fait par le marketplace à partir de la branche main ou de la branche dev. La version courante annoncée dans le README est 1.16.0. Sur la licence, le README indique MIT, mais l'identifiant de licence n'a pas été récupéré au niveau du dépôt : cette divergence apparente mérite d'être vérifiée avant tout usage en contexte commercial. Le README signale par ailleurs que Humanize2 est en développement actif et que les retours sont recherchés, ce qui suggère une trajectoire de projet encore mouvante.

Ce qui existe à côté, et en quoi c'est différent

Le README cite deux points de comparaison, et il faut les prendre pour ce qu'ils sont. Le premier est le plugin officiel ralph-loop, dont RLCR s'inspire : la différence annoncée est l'ajout d'une relecture Codex indépendante, là où une boucle Ralph classique fait itérer le même agent sur son propre travail. Le second est GAAC, GitHub-as-a-Context, dont Humanize dérive. Sur GAAC, le matériel fourni ne dit rien de plus que la filiation, donc je ne peux pas décrire en quoi les approches divergent concrètement. Si vous cherchez un outil sans dépendance à un second agent, une boucle Ralph simple reste plus légère à opérer ; si vous cherchez une relecture par un modèle différent de celui qui a écrit le code, c'est précisément le créneau que Humanize revendique. La distinction tient donc à un seul mécanisme : qui relit. Le reste, boucle, critères d'acceptation, plan préalable, est commun à cette famille d'outils.

Ce qu'il faut vérifier avant de s'engager

La documentation est répartie sur plusieurs fichiers : docs/usage.md pour les commandes, options et variables d'environnement ainsi que la hiérarchie de configuration et les règles de surcharge, docs/install-for-claude.md, docs/install-for-codex.md pour le runtime des skills Codex, docs/install-for-kimi.md pour Kimi CLI, et docs/bitlesson.md pour la mémoire projet, le routage par sélecteur et la validation des deltas. Cette dispersion indique un outil qui couvre plusieurs runtimes d'agents, pas seulement Claude Code, même si le README principal ne détaille que le parcours Claude. Trois vérifications me paraissent prioritaires avant adoption. D'abord, la licence réellement déclarée dans le dépôt, puisque le README annonce MIT sans que l'identifiant ait été confirmé. Ensuite, le contenu de docs/usage.md, seul endroit où la mécanique de la boucle et les variables d'environnement sont documentées. Enfin, la stabilité de la branche main par rapport à dev, sachant qu'aucune release n'est publiée et que le projet annonce une version suivante en préparation. Ces trois points se lisent en quelques minutes et déterminent si l'outil est adapté à votre contexte.

Conclusion éditoriale

Humanize convient aux équipes qui utilisent déjà Claude Code et acceptent d'installer codex CLI comme second agent, parce que la valeur du projet tient entièrement à cette relecture externe. Passez votre chemin si vous voulez un outil autonome ou si vous refusez d'écrire un plan avec des critères d'acceptation vérifiables. Avant d'adopter, installez le plugin, lancez /humanize:gen-plan sur un petit sujet et ouvrez le plan produit : si les critères d'acceptation ne sont pas assez précis pour qu'un relecteur les tranche, la boucle tournera sans jamais converger.

Sources officielles

1. Issues
2. PolyArch/humanize on GitHub
3. README