Humanize: Claude Code mit unabhängigem Codex-Review im Ralph-Loop

Ein Modell baut, ein zweites prüft: der Kern von RLCR

Der Ausgangspunkt ist ein bekanntes Problem: Wer ein LLM den eigenen Code schreiben lässt, lässt es meist auch bewerten. Der Prüfer sieht damit dieselben blinden Flecken wie der Autor. Humanize setzt an dieser Stelle an und trennt die beiden Rollen. Claude implementiert, Codex rezensiert. Die Abkürzung RLCR steht laut README für Ralph-Loop with Codex Review, inspiriert vom offiziellen ralph-loop-Plugin, und liest sich zugleich als Reinforcement Learning with Code Review. Die Zielgruppe sind Entwickler, die Claude Code schon als Arbeitswerkzeug einsetzen und den Review nicht demselben Modell überlassen wollen. Das Plugin selbst ist in Shell geschrieben und wird über den Marketplace-Mechanismus von Claude Code verteilt, nicht als eigenständiges Programm.

Zwei Phasen, ein Kreislauf

Die Dokumentation beschreibt den Loop mit zwei Phasen. In der Implementierungsphase arbeitet Claude und Codex liest Zusammenfassungen. In der Code-Review-Phase prüft Codex die Codequalität und vergibt Schweregrad-Marker. Beanstandungen fließen zurück in die Implementierung, und das so lange, bis sie abgearbeitet sind. Die Abbruchbedingung sind die Akzeptanzkriterien aus dem Plan, nicht eine feste Rundenzahl. Wer den Ablauf steuern will, muss also den Plan so schreiben, dass er prüfbare Kriterien enthält. Ein Plan aus vagen Zielen macht den Loop entweder endlos oder wirkungslos. Optional lässt sich der Durchlauf mit Agent Teams parallelisieren, was das README unter Swarm Mode führt. Ob die Parallelisierung in der eigenen Umgebung tatsächlich Konflikte vermeidet, lässt sich aus dem Material nicht ableiten.

Der Mensch bleibt Architekt, per Designprüfung vor dem Start

Vor dem Loop steht ein Schritt, den das README unter Begin with the End in Mind führt: Humanize prüft, ob der Nutzer den Plan verstanden hat, den er ausführen lassen will. Der Anspruch ist, dass der Mensch Architekt bleibt. In der Praxis bedeutet das eine zusätzliche Rückfrage vor dem ersten Durchlauf, und die ist der Grund, warum der Einstieg länger dauert als ein einzelner Prompt. Der Nutzen liegt auf der Hand: Wer den Plan nicht erklären kann, kann auch das Ergebnis nicht beurteilen. Der Preis ist ein manueller Zwischenschritt, den kein Automatismus ersetzt.

Installation und die vier Befehle des Alltags

Die Installation läuft über den Marketplace von Claude Code. Zuerst wird die Quelle registriert, dann das Plugin installiert:

/plugin marketplace add PolyArch/humanize /plugin install humanize@PolyArch

Für experimentelle Funktionen nennt das README zusätzlich die Variante mit dem dev-Branch:

/plugin marketplace add PolyArch/humanize#dev

Für den Review verlangt das Plugin die codex CLI von OpenAI, die separat eingerichtet werden muss. Der Arbeitsablauf beginnt optional mit einer Ideenskizze:

/humanize:gen-idea "add undo/redo to the editor"

Die Ausgabe landet laut README standardmäßig unter .humanize/ideas/<slug>-<timestamp>.md. Der Schalter --n steuert, wie viele parallele Richtungen die Idee erkunden, voreingestellt sind es sechs. Wer bereits Notizen hat, übergibt statt eines freien Satzes einen Pfad zu einer .md-Datei. Aus der Skizze entsteht der Plan:

/humanize:gen-plan --input draft.md --output docs/plan.md

Wenn Reviewer Kommentare hinterlassen haben, lassen sich diese vor der Umsetzung einarbeiten. Das README nennt dafür drei Markierungsformen: CMT: bis ENDCMT, <cmt> bis </cmt> und <comment> bis </comment>. Der Aufruf lautet:

/humanize:refine-plan --input docs/plan.md

Gestartet wird der Loop mit einem Planpfad:

/humanize:start-rlcr-loop docs/plan.md

Für Recherchen im Web nennt das README einen weiteren Befehl, der die Gemini CLI voraussetzt:

/humanize:ask-gemini What are the latest best practices for X?

Monitoring läuft außerhalb von Claude Code

Der Fortschritt wird nicht im Plugin-Fenster verfolgt, sondern in einem zweiten Terminal. Dazu wird das Shell-Skript des Projekts geladen, entweder einmalig pro Sitzung oder dauerhaft über .bashrc beziehungsweise .zshrc:

source <path/to/humanize>/scripts/humanize.sh

Danach stehen mehrere Ansichten bereit: humanize monitor rlcr für den Loop selbst, humanize monitor skill für alle Skill-Aufrufe, humanize monitor codex und humanize monitor gemini für die Aufrufe der jeweiligen CLI. Dass das Monitoring ausdrücklich außerhalb von Claude Code läuft, ist eine bewusste Trennung: Der laufende Agent soll nicht durch die eigene Statusanzeige gestört werden. Für den Betrieb heißt das aber auch, dass zwei Prozesse parallel laufen und ein zweites Terminal offen bleiben muss.

Zwei externe CLIs, ein Shell-Skript, MIT-Lizenz

Humanize ist kein in sich geschlossenes Werkzeug. Es setzt Claude Code voraus, für den Review zusätzlich die codex CLI, für die Recherchefunktion optional die Gemini CLI. Die Dokumentation verweist außerdem auf eine eigene Einrichtung für Codex und für Kimi. Jede dieser Abhängigkeiten hat eigene Zugangsdaten, eigene Aktualisierungszyklen und eigene Ausfälle. Fällt eine der CLIs aus, steht der Loop. Das ist der eigentliche Betriebsaufwand, und er wird im README nicht klein gerechnet. Die Lizenz ist MIT, was die Nutzung und Weitergabe im Rahmen der Lizenzbedingungen erlaubt; welche Bedingungen das im Einzelfall sind, ist mit der eigenen Rechtsabteilung zu klären und nicht Gegenstand dieser Betrachtung. Eine Versionsnummer nennt das README mit 1.16.0. Reguläre Releases wurden für diese Betrachtung nicht abgerufen, es gibt also keinen belegbaren Release-Zyklus, an dem sich ein Upgrade-Plan festmachen ließe. Das Repository verweist zudem auf Humanize2 als Nachfolger in aktiver Entwicklung, was die Frage aufwirft, wie lange die 1.x-Linie gepflegt wird. Diese Frage beantwortet das Material nicht.

Wo der Ansatz an Grenzen stößt

Der Review durch ein zweites Modell ist kein Review durch einen Menschen. Codex prüft Codequalität und vergibt Schweregrade, aber ob diese Prüfung die fachlichen Anforderungen trifft, hängt am Plan. Ein falsch geschnittenes Akzeptanzkriterium wird von keinem Reviewer korrigiert, weil beide Seiten dieselbe Beschreibung lesen. Wer eine Änderung in wenigen Minuten selbst erledigt, bezahlt mit Humanize den vollen Preis: Ideenskizze, Plan, Designprüfung, Loop, Monitoring. Der Ralph-Loop ist für Aufgaben gedacht, die mehrere Runden brauchen. Für einen Einzeiler ist er die falsche Wahl. Ebenso ungeeignet ist er, wenn kein Zugang zur codex CLI besteht oder wenn die Umgebung keine zweite CLI installieren darf. Und wer keinen Plan formulieren will, sondern direkt losbauen möchte, umgeht genau den Mechanismus, der den Rest zusammenhält.

Was andere Werkzeuge anders machen

Der naheliegende Vergleich ist das ralph-loop-Plugin, von dem Humanize laut README abstammt. Dort läuft die Schleife ohne externen Reviewer: Dasselbe Modell, das schreibt, entscheidet auch, wann es fertig ist. Humanize tauscht diese Einfachheit gegen eine zweite Stimme im Prozess. Der Unterschied liegt nicht im Umfang der Funktionen, sondern in der Rollentrennung: Ein einzelnes Modell kann einen Fehler in seinem eigenen Entwurf nicht bemerken, wenn es ihn beim Schreiben bereits akzeptiert hat. Der Preis dieser Trennung ist eine zusätzliche Abhängigkeit und ein zweiter Ausfallpunkt. Für Solo-Arbeit an kleinen Projekten ist der einfachere Loop ausreichend; der doppelte Review lohnt sich dort, wo Fehler teuer sind. Eine dritte Variante wäre, den Review manuell an ein anderes Modell zu geben, ohne den Loop zu automatisieren. Das spart die Plugin-Ebene, kostet aber den Automatismus, der Beanstandungen zurück in die Implementierung trägt.

Redaktionelles Fazit

Sinnvoll ist Humanize für Teams, die Claude Code bereits produktiv nutzen, den Review-Schritt aber nicht demselben Modell überlassen wollen, und die bereit sind, zusätzlich die codex CLI zu betreiben. Wer keinen Zugang zu Codex hat, nur kleine Einmaländerungen vornimmt oder keinen Plan als Eingabe formulieren will, sollte es nicht einführen. Vor dem ersten produktiven Loop ist zu prüfen, ob die Annahme der Dokumentation zutrifft, dass der Review von einem anderen Modell kommt, und ob die Version 1.16.0 im eigenen Setup die Dateien unter .humanize/ideas/ tatsächlich anlegt.

Offizielle Quellen

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