Humanize: a Claude Code plugin that puts Codex in the reviewer's chair

The gap Humanize is aimed at: an AI that grades its own homework

The common failure mode of agentic coding is not that the model writes bad code. It is that the same model decides the code is finished. Humanize's answer is structural: Claude implements, Codex reviews. The README states this as "One Build + One Review" and adds "No blind spots." That claim is worth taking with some skepticism, since Codex is another language model and shares the failure modes of language models. The design bet is narrower and more defensible than the marketing line. A second model, reading a summary and then the code, is less likely to accept the same rationalisation that produced the bug in the first place. Humanize is for engineers who already work inside Claude Code with a written plan and want a second opinion wired into the loop rather than requested manually. It is not for someone looking for a general-purpose agent framework. The plugin is Shell, the entry points are slash commands, and the whole thing assumes Claude Code is the host.

RLCR: two phases, one loop, and a plan file as the exit condition

RLCR stands for Ralph-Loop with Codex Review, and the README notes the acronym also reads as Reinforcement Learning with Code Review. The loop has two phases. In Implementation, Claude works and Codex reviews summaries. In Code Review, Codex checks code quality and attaches severity markers. Issues from the review feed back into implementation until they are resolved. The termination condition is the acceptance criteria in the plan, not a step count, which is why the quality of the plan file matters more than the quality of the prompt. Humanize also ships a Swarm Mode that the README describes as optionally parallelising with Agent Teams. There is a separate concept listed as "Begin with the End in Mind": before the loop starts, Humanize verifies that you understand the plan you are about to execute, with the README stating that "the human must remain the architect." That is a gate on comprehension, and it is the least conventional part of the design. Most agent tools assume you want to delegate. This one assumes you want to stay in the loop and is explicit that you should.

Install and the first four commands

Installation goes through the plugin marketplace rather than a package manager. The README gives these commands: /plugin marketplace add PolyArch/humanize, then /plugin install humanize@PolyArch. A development branch is available via /plugin marketplace add PolyArch/humanize#dev. The README states that the codex CLI is required for review and points to docs/install-for-claude.md for prerequisites and alternative setup options. The quick start is a four-step pipeline. /humanize:gen-idea "add undo/redo to the editor" produces a draft at .humanize/ideas/<slug>-<timestamp>.md by default, and the --n flag controls how many parallel directions explore the idea, with a default of 6. /humanize:gen-plan --input draft.md --output docs/plan.md turns the draft into a plan. /humanize:refine-plan --input docs/plan.md handles reviewer comments in three accepted formats: CMT: ... ENDCMT, <cmt> ... </cmt>, and <comment> ... </comment>. Then /humanize:start-rlcr-loop docs/plan.md runs the loop. There is also /humanize:ask-gemini for web research, which requires the Gemini CLI. Note that this is a third external tool, optional but present in the command surface.

The monitor is a separate shell function, not a Claude Code view

Monitoring happens outside Claude Code. The README is explicit: run it in another terminal, not inside Claude Code. You source the script, either directly with source <path/to/humanize>/scripts/humanize.sh or by adding it to your .bashrc or .zshrc, and then call one of four subcommands. humanize monitor rlcr watches the loop. humanize monitor skill watches all skill invocations across codex and gemini. humanize monitor codex and humanize monitor gemini narrow that to one provider each. This is a deliberate split. The agent loop occupies the Claude Code session, and a second terminal watches the state from outside. It works, but it means the tool has two surfaces to learn: slash commands inside the session and a shell function outside it. The README also mentions a Bitter Lesson Workflow documented in docs/bitlesson.md, covering project memory, selector routing, and delta validation. The README gives no description of what those three terms mean in practice, so treat that document as required reading rather than optional.

Where the loop stops being the right tool

The dependency on codex CLI is the hard boundary. Without it there is no reviewer, and without a reviewer RLCR is just a plan-driven Claude Code session with extra ceremony. The second constraint is the plan. A loop that iterates until acceptance criteria are met will not terminate well if the criteria are vague, and the README does not describe a fallback for plans that lack them. Third, the project is Shell. Every command listed here is a slash command or a sourced script, and the default branch is main, which means you are executing repository code in your shell environment. That is normal for this category of tool and still worth reading before you source anything. Fourth, the licence field in the repository metadata is unknown while the README's License section says MIT. That is a discrepancy in the supplied material, and I cannot resolve it from here. If licence terms matter to your organisation, check the LICENSE file directly rather than trusting either signal. Finally, the README points to Humanize2 as under active development in a separate repository, which suggests the project's own maintainers see the current line as having a successor.

Against a plain Claude Code session with a manual review step

The honest alternative is not a competing plugin. It is what you already do: write a plan, let Claude Code implement, then open a second session or a second tool and ask for a review by hand. The difference is in what gets automated. In the manual version, you decide when a review happens and you carry the review comments back into the next prompt yourself. In Humanize, the review is a phase of the loop, the severity markers come from Codex, and the issues route back into implementation automatically until they clear. The trade-off is control against throughput. Manual review lets you stop early when the remaining findings are cosmetic, and it lets you ignore a reviewer that is being pedantic. The loop does not obviously give you that, and the README does not describe a way to waive a finding. The refine-plan command is the closest thing to a human override point, and it operates on the plan, not on the review output. That is the design's sharpest edge and its clearest cost.

Maintenance surface and what the MIT label does not settle

The README states version 1.16.0, and the repository's last push is 2026-08-28. No releases were retrieved, so version 1.16.0 is a README claim rather than a tagged artifact I can point at. The maintenance cost here is mostly environmental. You are tracking three CLIs: Claude Code as the host, codex CLI for review, and optionally Gemini CLI for /humanize:ask-gemini. Each has its own install path and its own breakage modes, and the plugin's install docs are split across docs/install-for-claude.md, docs/install-for-codex.md, and docs/install-for-kimi.md. That last file is worth noting: the README documents a Kimi CLI skill setup alongside the Claude and Codex paths, so the skill runtime is not strictly Claude-only even though the plugin is. On licensing, the README's License section says MIT, which is permissive and generally allows commercial use and modification with attribution. The repository metadata says unknown. I am not giving legal advice and cannot reconcile the two from the supplied material, so verify the LICENSE file before you depend on it.

Editorial conclusion

Adopt Humanize if you already drive Claude Code from a plan file and can install the codex CLI, because the reviewer role is the whole product and it does not exist without that binary. Do not adopt it if you want a single-tool setup, if your work has no written acceptance criteria for a loop to terminate against, or if you cannot read Shell scripts before running them. Verify three things first: that codex CLI is installed and callable, that the config hierarchy under docs/usage.md#configuration matches where you intend to put your settings, and that the plan file you feed to /humanize:start-rlcr-loop actually states acceptance criteria, since that is what the loop iterates toward.

Official sources

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