Claudeex getestet: Claude Code und Codex im Planungs-Loop

Claudeex getestet: Claude Code und Codex im Planungs-Loop

Der Plan sah sauber aus. Zwölf nummerierte Schritte. Architekturdiagramm im Markdown. Reihenfolge der Datenbankmigration ausgeschrieben. Ich wollte gerade auf „Implementieren“ klicken, als mir einfiel, dass ich Claudeex installiert hatte, also beschloss ich, es laufen zu lassen, bevor ich etwas verschicke.

Runde eins kam mit sieben Ausgaben zurück. Drei davon waren ernst. Eine davon – „Der Plan ruft einen Webhook auf, bevor die Datenbankzeile existiert“ – hätte mich an einem Dienstag um 23 Uhr einen ganzen Nachmittag des Debuggens gekostet. Der Plan, den ich ausliefern wollte, enthielt in Schritt vier eine Rennbedingung.

Das war der Moment, in dem ich aufhörte, Claudeex als eine Kuriosität zu betrachten, und begann, es als etwas zu betrachten, das ich in den letzten sechs Monaten hätte betreiben sollen.

Falls Sie es noch nicht gesehen haben: Claudeex ist ein kleiner Bash- und YAML-Kabelbaum, der Claude Code und die OpenAI Codex CLI in eine Planungsschleife verwandelt. Claude Code entwirft einen Plan, Codex prüft ihn, Claude Code überarbeitet, Codex prüft die Revision und so weiter, bis Sie eine konfigurierbare runde Obergrenze erreichen. Der Standardwert beträgt drei Runden. Das Ganze läuft auf dem Stopp-Hook von

Ich habe die letzten zwei Wochen damit verbracht, es bei echten Kundenarbeiten auszuführen – einer Besucheranalyseseite, einem Stripe-Webhook-Refactor, einem kleinen Laravel-Admin-Dashboard – und es gibt hier genug, dass ich durchgehen möchte, was funktioniert, wo die Nähte sichtbar sind und warum Planungsschleifen mit zwei Modellen bald zum Standard für alles werden, was komplexer als ein CRUD-Formular ist.

Was Claudeex eigentlich ist (über README hinaus)

Der Pitch ist unkompliziert: Claude Code ist gut darin, Pläne zu entwerfen, Codex ist gut darin, Lücken darin zu finden, und die meisten Planungsfehler lassen sich erkennen, wenn Sie einfach ein zweites Modell den Plan mit kritischem Auge lesen lassen. Anstatt also Sie zu bitten, das zweite Modell zu sein, automatisiert Claudeex das Hin und Her.

Mechanisch besteht es aus vier Teilen:

1. Ein Bash-Launcher, der eine Eingabeaufforderung entgegennimmt, eine YAML-Statusdatei schreibt und Claude Code mit der richtigen geladenen Hook-Konfiguration startet
2. Eine YAML-Statusdatei, die die Eingabeaufforderung, die Gesamtzahl der Runden, die aktuelle Iteration und alle angehefteten Kontextdateien (wie scope.md oder architecture.md) verfolgt.
3. Ein Claude Code-Stopp-Hook, der ausgelöst wird, nachdem Claude eine Planungsrunde beendet hat, die Statusdatei liest und entscheidet, ob Codex aufgerufen oder Claude beendet werden soll
4. Drei Schrägstrichbefehle – /plan, /review und

Der Stopphaken ist der Clou. Der Stopphaken von Claude Code wird einmal pro Runde ausgelöst, wenn Claude nicht mehr reagiert, und ein Stopphaken, der mit Code 2 beendet wird, zwingt Claude, weiterzuarbeiten. Aus dem Kontext von Claude Code sieht es einfach wie eine weitere Runde aus – aber die Runde enthält zufällig eine strukturierte Kritik aus einem anderen Grenzmodell.

Wenn Sie meine Aufschlüsselung des Zwei-Agenten-Workflows Claude Code und Codex gelesen haben, ist das mentale Modell ähnlich. Der Unterschied besteht darin, dass Claudeex die Schleife in die Claude Code-Sitzung selbst integriert – Sie müssen Transkripte nicht manuell zwischen Terminals weiterleiten oder Kritiken kopieren und einfügen. Der Haken macht es.

Warum die Zwei-Modell-Planung die Ein-Modell-Planung übertrifft

Ich möchte hier vorsichtig sein, denn die offensichtliche Formulierung – „zwei Modelle sind besser als eines“ – ist die Art vager Behauptung, die ich normalerweise aus einem Entwurf herausschneiden würde. Lassen Sie mich also näher darauf eingehen, was sich tatsächlich ändert.

Wenn Claude Code einen Plan alleine entwirft, geht er von einer einzigen Verteilung aus, „wie gute Pläne aussehen“. Es hat seine eigenen Trainingsvoreingenommenheiten. Es hat seine eigenen blinden Flecken. Wenn ich es auffordere, „den Plan noch einmal zu überprüfen“, bedeutet das im Wesentlichen, dass es mit sich selbst nicht einverstanden ist, was Sprachmodelle notorisch schlecht kann. Es gibt Untersuchungen zu Speichelleckerei und Selbstkonsistenz, die den Grund dafür aufzeigen: Mit RLHF trainierte Modelle tendieren dazu, sich auf ihre erste Antwort festzulegen und diese dann zu verteidigen, selbst wenn sie zu Kritik aufgefordert werden.

Codex ist ein anderes Modell mit einer anderen Trainingspipeline. Das aktuelle Produktionsmodell in der Codex-CLI ist GPT-5.5 (mit GPT-5.4 als Fallback, wenn Ihr Konto noch nicht erweitert wurde). Wenn Codex einen von Claude erstellten Plan prüft, liest es Prosa, die in einem etwas anderen kognitiven Stil geschrieben ist, und ist viel eher bereit, Dinge zu markieren, die Claude beschönigt hat. Die Asymmetrie ist der Wert. Codex fängt Dinge ab, die Claude in der Vergangenheit geschrieben hat; Claude erfasst Dinge, die Codex übersehen hätte, wenn es stattdessen den Plan entworfen hätte.

In der Praxis liegt die Fangquote bei Fehlern in der Planungsphase bei den Projekten, die ich in den letzten zwei Wochen mit Claudeex durchlaufen habe, in den ersten zwei bis drei Runden bei etwa 80 %. Nach der dritten Runde werden die Grenzerträge dünner – Codex fängt an, eher stilistische Präferenzen als tatsächliche Probleme zu melden. Deshalb ist die Vorgabe von drei Runden richtig. Ich habe versucht, es bei einem komplexen Job auf fünf zu setzen, und in der vierten Runde diskutierte Codex darüber, ob ich eine Enumeration oder eine Zeichenfolge für ein Statusfeld verwenden sollte. In der fünften Runde änderte Codex seine Meinung über die vierte Runde. Drei Runden sind der Sweet Spot.

Die Slash-Befehlsoberfläche

Es gibt vier Slash-Befehle, von denen Sie täglich nur zwei benötigen.

/plan <prompt> ist das Arbeitstier. Sie übergeben ihm eine Beschreibung dessen, was Sie erstellen möchten, heften optional einige Kontextdateien wie scope.md oder architecture.md an und die Schleife wird ausgeführt. Claude-Entwürfe, Codex-Audits, Claude-Überarbeitungen. Am Ende erhalten Sie einen endgültigen Plan mit den Löschungen und Hinzufügungen aus jeder Runde, die in Rot und Grün angezeigt werden, damit Sie sehen können, wie sich der Plan entwickelt hat. Wenn Sie jemals eine ernsthafte Codeüberprüfung durchgeführt und die PR-Transformation eines Junior-Ingenieurs zwischen v1 und v3 beobachtet haben, fühlt sich die Diff-Ansicht genau so an.

/review ist die schreibgeschützte Version. Es nimmt einen vorhandenen Plan – einen, den Sie geschrieben haben, einen, den ein Teamkollege geschrieben hat, einen, den Claude in einer früheren Sitzung geschrieben hat – und führt Codex ohne Revisionsschritt darüber aus. Sie erhalten die Audit-Kommentare und das war’s. Ich verwende dies für Pläne, die ich gerade an einen anderen Entwickler übergeben möchte. Es handelt sich um eine günstige Zweitmeinung vor Arbeitsbeginn.

/cancel ist ein Notstopp. Wenn die Schleife aus dem Ruder läuft – Codex fängt an, Abhängigkeiten zu halluzinieren, Claude beginnt, denselben Abschnitt im Kreis neu zu schreiben – können Sie den Lauf sauber unterbrechen, ohne dass die Zustandsdatei YAML in einem kaputten Halbzustand bleibt.

/rollback löscht den Planstatus vollständig. Nützlich, wenn Sie ganz von vorne beginnen möchten, ohne Claude Code neu zu starten.

Die Syntax ist wichtiger, als Sie erwarten würden. Als ich /plan zum ersten Mal ausführte, gab ich ihm eine Aufforderung mit einem Satz: „Erstellen Sie eine Besucheranalyseseite, die keine Drittanbieter nutzt.“ Claude hat einen vernünftigen, aber allgemeinen Plan geschrieben. Codex hat es geprüft und der erste Kommentar lautete: „Die Eingabeaufforderung ist zu vage, um sie zu bewerten. Was ist das Erfolgskriterium?“ Das ist eine Funktion, kein Fehler. Das optionale Ask-User-Input-Tool, das mit Claudeex geliefert wird, ist speziell für diese Momente da – wenn eine Eingabeaufforderung zu vage ist, um sie zu planen, unterbricht es die Schleife und stellt Ihnen klärende Fragen, bevor Sie fortfahren. Ich habe gelernt, mit /plan plus einem Kontextabsatz und einem angehefteten scope.md zu führen, und die Qualität jeder Runde danach hat sich merklich verbessert.

Wie Bash und YAML tatsächlich aussehen

Der Launcher ist klein genug, um ihn von Ende zu Ende lesen zu können. Hier ist die Form mit dem Rauschunterdrückung:

#!/usr/bin/env bash
set -euo pipefail

PROMPT="$1"
ROUNDS="${2:-3}"
STATE_FILE=".claudeex/state.yaml"

mkdir -p .claudeex

cat > "$STATE_FILE" <<EOF
prompt: |
  $PROMPT
rounds_total: $ROUNDS
rounds_completed: 0
phase: drafting
context_files:
  - scope.md
  - architecture.md
EOF

claude --hook-config .claudeex/hooks.json \
       --slash-command "/plan $PROMPT"

Das ist der gesamte Einstiegspunkt. Alles andere befindet sich in der Hook-Konfiguration und der Statusdatei. Die Hook-Konfiguration registriert einen Stopp-Hook, der auf ein kleines Shell-Skript zeigt:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": ".claudeex/audit.sh"
          }
        ]
      }
    ]
  }
}

Und audit.sh ist die Brücke zu Codex. Das Skript liest den YAML-Status, prüft die aktuelle Phase und Rundenanzahl und entscheidet, ob Codex aufgerufen oder Claude beendet werden soll:

#!/usr/bin/env bash
set -euo pipefail

STATE_FILE=".claudeex/state.yaml"
ROUNDS_TOTAL=$(yq '.rounds_total' "$STATE_FILE")
ROUNDS_DONE=$(yq '.rounds_completed' "$STATE_FILE")
PHASE=$(yq '.phase' "$STATE_FILE")

if [ "$PHASE" = "drafting" ] && [ "$ROUNDS_DONE" -lt "$ROUNDS_TOTAL" ]; then
  PLAN=$(cat .claudeex/plan-current.md)
  CRITIQUE=$(codex exec "Audit this plan for correctness, missing edge cases, race conditions, and broken dependencies. Be specific. Cite line numbers." --input "$PLAN")

  echo "$CRITIQUE" > .claudeex/critique-round-$((ROUNDS_DONE + 1)).md
  yq -i ".rounds_completed = $((ROUNDS_DONE + 1))" "$STATE_FILE"

  # Exit 2 forces Claude Code to keep working with the critique injected
  cat <<EOF >&2
Round $((ROUNDS_DONE + 1)) audit from Codex:

$CRITIQUE

Please revise the plan addressing each point.
EOF
  exit 2
fi

exit 0

Das Exit-2-Muster erledigt die ganze schwere Arbeit. Wie in der Claude Code-Hooks-Referenz beschrieben wird, zwingt ein Stop-Hook, der mit Status 2 beendet wird, Claude dazu, weiterzuarbeiten, wobei die stderr-Ausgabe des Hooks wieder in die Konversation eingefügt wird. Claudeex nutzt dies, um die Kritik von

Es ist erwähnenswert: Das ist Klebeband, aber es ist gutes Klebeband. Das Hakensystem wurde nicht für modellübergreifende gegnerische Schleifen entwickelt. Es wurde für Dinge wie „Automatische Formatierung bei Bearbeitung“ oder „Gefährliche Befehle blockieren“ entwickelt. Die Tatsache, dass es für etwas so Aufwändiges umfunktioniert werden kann, ist ein kleiner Beweis dafür, wie gut die Grundelemente ausgewählt wurden.

Die Demo, die ich erstellt habe, um sie einem Stresstest zu unterziehen

Ich brauchte einen echten Testfall, also habe ich etwas ausgewählt, das ich eigentlich liefern wollte: ein Analysetool für Einzelseitenbesucher, das Interaktionen auf meiner Website verfolgt, ohne Daten an einen Drittanbieterdienst zu senden. Kein Google Analytics, kein Plausible, kein Fathom. Nur mein eigenes Backend, das Klicks, Scrolls und die Verweildauer auf der Seite meiner eigenen Besucher sammelt.

Der Grund dafür, dass dies ein guter Claudeex-Testfall ist, liegt darin, dass er an einer schwierigen Schnittstelle zwischen Frontend-Instrumentierung, Backend-Speicher und Datenschutzgesetzen angesiedelt ist. Es gibt mindestens vier Möglichkeiten, etwas falsch zu machen, und die meisten davon sind Planungsfehler, keine Programmierfehler. Sie können das JavaScript korrekt schreiben und dennoch etwas Illegales unter GDPR versenden. Sie können das Datenbankschema richtig entwerfen und trotzdem ein System erstellen, das die Seite in langsamen Netzwerken zum Absturz bringt. Die Fehler verstecken sich vor dem Code.

Ich habe zwei Kontextdateien angeheftet: Dann lief ich:

/plan Build a visitor interaction tracking page following scope.md and architecture.md. Plan should cover schema, frontend instrumentation, backend ingestion, and the consent flow.

Ungefähr 15 bis 20 Minuten später hatte ich einen Plan, den ich tatsächlich versenden würde. Runde eins brachte einen vernünftigen ersten Entwurf hervor, der den Einwilligungsfluss völlig ignorierte – Claude behandelte GDPR als Fußnote und nicht als Gating-Anforderung. Die erste Runde der Kritik von Codex begann mit „Der Zustimmungsfluss fehlt völlig; ohne ihn sollten keine Ereignisse ausgelöst werden“, was genau die Art von Sache ist, die mich in der Produktion gebissen hätte. Runde zwei fügte das Consent Gate hinzu, führte jedoch zu einem anderen Problem: Es gab die Frontend-Pufferereignisse in localStorage, bevor die Einwilligung erteilt wurde, was in einigen Interpretationen selbst eine GDPR-Verletzung darstellt. Codex hat das in Runde zwei geschafft. Runde drei hatte eine saubere Version, bei der das Frontend nichts speichert, bis die Einwilligung erteilt wird, und dann eine Warteschlange mit absichtlich aufgezeichneten Ereignissen an das Backend weiterleitet.

Die Diff-Ansicht am Ende hat mich am meisten überrascht. Claudeex zeigt den Plan Runde für Runde mit rot durchgestrichenen Löschungen und grün hervorgehobenen Ergänzungen. Sie können genau sehen, was bei der Prüfung festgestellt wurde und wo der Plan gestärkt wurde. Es kommt einem Code-Review-Erlebnis für Pläne und nicht für Code am nächsten, was ich je gesehen habe.

Claudeex vs. Claude Code allein

Hier ist der Vergleich, auf den ich immer wieder zurückkomme. Nach zwei Wochen, in denen beide ausgeführt wurden – manchmal derselbe Prompt durch beide, manchmal abwechselnd je nach Projektkomplexität – ergeben die Unterschiede ein klares Muster.

Ionenfunktionen, sicherheitsrelevante Arbeiten, alles, was Daten berührt |

Die symbolischen Kosten sind real und es lohnt sich, ehrlich zu sein. Drei Runden Claude-Planung plus drei Runden Codex-Prüfung sind nicht kostenlos. Für ein schnelles Skript oder einen Prototyp lohnt sich der Aufwand nicht – Sie können einfach einen Plan ausführen, ihn selbst scannen und versenden. Für alles, wo ein Planungsfehler Sie mehr als 30 Minuten Debugging kosten würde, amortisiert sich Claudeex beim ersten Speichern.

Das Aufklärungsverhalten ist der unterschätzte Vorteil. Das optionale Ask-User-Input-Tool verwandelt vage Aufforderungen in produktive Gespräche statt in sicher falsche Pläne. Meiner Erfahrung nach sind etwa ein Drittel der von mir verfassten Eingabeaufforderungen zu vage, als dass man sie bei der Planung berücksichtigen könnte – und Claudeex ist das erste Tool, das ich verwendet habe, das dies konsequent erkennt, bevor es einen Plan erstellt, der sicher falsch interpretiert, was ich wollte.

Wenn Sie einen verwandten Vergleich wünschen, ist der dynamische Duo-Workflow für Claude Code- und Codex-Plugins die manuelle Version dessen, was Claudeex automatisiert. Die Plugin-Route ist flexibler; Claudeex ist eigensinniger. Je nach Auftrag verwende ich beides.

Wo Claudeex zu kurz kommt

Ich möchte diesbezüglich ehrlich sein, denn sonst wäre der Artikel nutzlos.

Bei langen Kontexten ist es brüchig. Wenn der Plan und das Prüfprotokoll lang genug werden – irgendwo über 30.000 Token zusammen – verliert Claude den Überblick darüber, in welcher Runde er sich befindet, und generiert manchmal ganze Abschnitte neu, die Codex bereits genehmigt hat. Dies ist ein Kontextverwaltungsproblem und kein Claudeex-Fehler an sich. Aber es ist die Naht, an der das Klebeband sichtbar ist.

Die YAML-Statusdatei eignet sich nicht für paralleles Arbeiten. Wenn Sie versuchen, zwei Claudeex-Sitzungen gleichzeitig im selben Repo auszuführen, überlasten sie sich gegenseitig mit den Statusdateien. Standardmäßig gibt es keine Isolation pro Sitzung. Ich habe es umgangen, indem ich funktionsspezifische Unterverzeichnisse erstellt habe, aber es ist ein echtes Problem.

Codex halluziniert manchmal Abhängigkeiten. Dies passiert ungefähr in jeder zehnten Runde. Codex wird einen Plan dafür kritisieren, dass „das Redis Streams-Setup fehlt“, wenn der Plan Redis Streams eigentlich nicht benötigt. Claude wird angesichts dieser Kritik hilfreich das Redis Streams-Setup hinzufügen. Am Ende steht ein Plan, der komplexer ist, als er sein müsste, mit einer Infrastruktur, die durch eine Audit-Halluzination eingeführt wurde. Die Lösung besteht darin, die Unterschiede jeder Runde selbst zu lesen und Änderungen abzulehnen, die nicht der Realität entsprechen. Das bedeutet, dass Claudeex den Menschen nicht wirklich aus der Schleife entfernt – es erleichtert lediglich die Arbeit des Menschen.

Es ist keine Zauberei für die Arbeit auf der grünen Wiese. Wenn Sie keinen scope.md oder architecture.md zum Anheften haben, verbringen die ersten Runden der Schleife viele Zyklen damit, über den Umfang zu streiten. Claudeex funktioniert am besten, wenn Sie bereits strategisch gedacht haben und Hilfe bei der taktischen Planung benötigen. Wenn Sie immer noch darüber nachdenken, was Sie bauen sollen, hilft Ihnen die Schleife nicht bei der Entscheidung. Es wird einfach immer wieder einen Plan für die falsche Sache verfeinern.

Die Modellasymmetrie kann sich umkehren. Codex ist meistens gut bei Audits. Aber wenn sich das Thema in Richtung der stärkeren Bereiche von In diesen Fällen fügt die Schleife eher Rauschen als Signal hinzu. Sie lernen, zu erkennen, wann Sie sich in einer dieser Zonen befinden, und /plan einfach einmal ohne den Prüfschritt auszuführen oder /review mit einem längeren Schwellenwert für Runde drei zu verwenden.

Jenseits des Codes: Wo sonst dieses Muster funktioniert

Was mich wirklich überrascht hat, ist, wie gut sich das Muster über den Code hinaus erstreckt. Ich habe Claudeex in der letzten Woche auf Nicht-Code-Planungsaufgaben getestet und die Ergebnisse sind interessant genug, um sie zu erwähnen.

Ich habe es auf einer Dia-Deck-Skizze für einen Workshop ausgeführt, den ich im Mai gebe. Der erste Entwurf von Claude war solide – ein logischer Ablauf, ordentliche Abschnittsaufschlüsselungen, angemessene Zeitschätzungen. Die Prüfung von Codex ergab, dass es im Workshop keine Übungen im mittleren Drittel gab, was nach dem Energiegipfel um die 25. Minute herum 40 Minuten direktes Sprechen bedeuten würde. Das war mir nicht aufgefallen. Ich hätte es bei der Probe mitbekommen, aber die Probe hätte am Abend zuvor stattgefunden. Claudeex hat es erkannt, bevor ich Vorbereitungszeit verschwendet habe.

Ich habe es auf einer Feature-Spezifikation für einen freiberuflichen Kunden ausgeführt – nicht auf dem Code, sondern nur auf dem Feature-Beschreibungsdokument, das in den Vorschlag aufgenommen wurde. Runde eins ist vorbei. In Runde zwei wies Codex darauf hin, dass das Dokument den glücklichen Weg beschrieb, aber nie erwähnte, was passiert, wenn der Drittanbieter API ausfällt. Der Kunde hat eine Version 3 genehmigt, die einen Abschnitt über eine ordnungsgemäße Verschlechterung enthielt. Dieser Absatz ist nun vertraglich Teil dessen, was ich ihnen schulde.

Ich habe es noch nicht mit Excel-Modellen oder Finanzdokumenten ausprobiert, sehe aber keinen Grund, warum es nicht funktionieren würde. Das Muster ist generisch: Überall dort, wo Sie einen Plan in Markdown schreiben und ein anderes Modell bitten können, ihn zu prüfen, wird die Schleife angewendet. Hier sehe ich auch eine Konvergenz mit dem umfassenderen Muster, das ich im Ultra-Plan-Modus von Claude Code behandelt habe – bei beiden geht es um die Formalisierung des Planungsschritts, anstatt ihn als schwingungsgesteuerte Präambel der Codierung zu behandeln.

Einrichtung, tatsächliche Kosten und worauf man es ausführen sollte

Wenn Ihre Umgebung bereits eingerichtet ist, dauert es etwa zehn Minuten, es zum Laufen zu bringen.

Voraussetzungen:

• Claude Code installiert und angemeldet
• Codex CLI installiert (npm i -g @openai/codex oder brew install --cask codex) und angemeldet
• yq installiert (brew install yq auf macOS) – Ein Repo, in dem Sie es ausführen möchten

Installieren:

git clone <claudeex-repo-url> .claudeex
chmod +x .claudeex/*.sh

Erster Lauf:

.claudeex/run.sh "build a visitor analytics page following scope.md"

Rechnen Sie beim ersten Mal mit 15 bis 20 Minuten für einen mäßig komplexen Plan. Die Codex-CLI verwendet das Modell, auf das Ihr Konto Zugriff hat – GPT-5.5, wenn Sie die neueste Version verwenden, GPT-5.4, wenn nicht. Beide eignen sich gut für Kritik im Audit-Stil. GPT-5.5 ist deutlich schärfer bei der Erkennung subtiler Probleme.

Kostenmäßig kostet mich eine Drei-Runden-Runde bei einem mäßig komplexen Plan etwa das Drei- bis Vierfache einer einzelnen Claude Code-Planungsrunde. Bei freiberuflicher Arbeit und Kundenarbeit handelt es sich um einen Rundungsfehler. Für persönliche Experimente möchten Sie es möglicherweise nur bei schwierigeren Problemen ausführen und /plan (ohne Schleife) die kleinen Dinge erledigen lassen.

Was Sie zuerst ausführen sollten: Jede Funktion, bei der ein Planungsfehler Sie mehr als einen halben Tag Nacharbeit kosten würde. Authentifizierungsflüsse. Zahlungsintegrationen. Datenmigrationen. Alles mit Parallelität. Alles, was GDPR oder HIPAA berührt. Das sind die Bereiche, in denen sich 15 Minuten automatisiertes Audit zehnfach amortisieren. Wenn Sie sicherheitsnahe Arbeiten ausführen, gilt die gleiche Logik – und das Sicherheitsscanner-Agent-Muster in Claude Code wird auf der Planungsseite auf natürliche Weise mit

Überspringen Sie es für: Fehlerbehebungen, bei denen der Fehler bereits isoliert ist, kleine Änderungen an der Benutzeroberfläche, alles, was Sie zuvor getan haben und für das Sie im Schlaf den Plan schreiben könnten. Der Mehraufwand lohnt sich dafür nicht.

Häufig gestellte Fragen

Was ist Claudeex und wie funktioniert es?

Claudeex ist eine iterative Planungsschleife, in der Claude Code einen Plan entwirft, die OpenAI Es verwendet einen Claude Code-Stopp-Hook mit Exit-Code 2, um die Kritik von Codex wieder in die Konversation einzubringen, als wäre es eine neue Wendung. Eine vollständige Anleitung zur Bash- und YAML-Implementierung finden Sie im obigen Abschnitt zum Launcher und Audit-Skript.

Wie viele Runden benötigt Claudeex, um die meisten Planungsfehler zu erkennen?

In zwei bis drei Runden werden in meinen Tests etwa 80 % der Planungsfehler erkannt. Runde vier und darüber hinaus führen zu sinkenden Erträgen und bringen oft eher stilistische Präferenzen als tatsächliche Probleme zum Vorschein. Die Vorgabe von drei Runden ist gut abgestimmt. Den vollständigen Kontext zu Zeit und Token-Kosten finden Sie in der Vergleichstabelle oben.

Funktioniert Claudeex für Nicht-Code-Planungsaufgaben?

Ja. Das Muster funktioniert für jeden in Markdown geschriebenen Plan, den ein anderes Modell prüfen kann – Folienumrisse, Funktionsspezifikationen, Projektvorschläge. Ich habe es auf Workshop-Decks und Spezifikationen von freiberuflichen Kunden getestet und dabei starke Ergebnisse erzielt. Der Abschnitt „Beyond Code“ oben führt Sie durch konkrete Beispiele.

Was ist der Unterschied zwischen /plan und /review in Claudeex?

/plan führt die vollständige Iterationsschleife aus: Entwurf, Prüfung, Überarbeitung, Wiederholung. /review ist schreibgeschützt – es führt Codex einmal über einen vorhandenen Plan aus und gibt die Prüfkommentare ohne Revisionsschritt zurück. Verwenden Sie /review, wenn Sie eine zweite Meinung zu einem Plan wünschen, den Sie oder ein Teamkollege bereits geschrieben haben.

Ist Claudeex die zusätzlichen Token-Kosten wert?

Für Produktionsfunktionen, sicherheitsrelevante Arbeiten oder alles, wo ein Planungsfehler mehr als 30 Minuten Debugging kosten würde – ja. Die 2,5- bis 3-fachen Token-Kosten amortisieren sich, wenn zum ersten Mal eine Rennbedingung auftritt. Bei Prototypen, wegwerfbaren Skripten oder Arbeiten, die Sie schon oft gemacht haben, ist der Mehraufwand nicht gerechtfertigt.

Was ich mitgenommen habe

Am Morgen nach meinem ersten echten Claudeex-Lauf ging ich zurück und schaute mir drei Pläne an, die ich im Vormonat verschickt hatte – Pläne, mit denen ich damals zufrieden war. Ich habe jeden von ihnen durch /review laufen lassen, um zu sehen, was Codex gefangen hätte.

Alle drei hatten mindestens ein Problem. Zwei hatten Rennbedingungen, die ich übersehen hatte. Einer hatte einen fehlenden Rollback-Pfad bei einer destruktiven Migration, der fairerweise bei der Codeüberprüfung aufgefallen wäre – aber nur, wenn der Prüfer genau aufgepasst hätte. Keiner davon war katastrophal. Alle drei wären weniger peinlich gewesen, wenn die Prüfung vor dem Versand stattgefunden hätte und nicht zwei Wochen später im Nachhinein.

Das ist der Teil, der mich erwischt hat. Nicht die Demo. Nicht die Diff-Ansicht. Die Erkenntnis, dass ich Pläne von mittlerer Qualität verschickt hatte und sie als erledigt bezeichnete, weil nichts in meinem Arbeitsablauf sie jemals zurückgedrängt hatte. Claude Code drückt nicht zurück. Ich wehre mich nicht, denn ich habe die Aufforderung geschrieben und bin fest davon überzeugt, dass der Plan gut wird. Das Einzige in dieser Schleife, das im Spiel keinen Skin hat, ist Codex.

Das Modell, dem es egal ist, ob Ihr Plan gut ist, ist das Modell, das Sie prüfen möchten.

Der Plan, den ich vor der Installation von Es hätte es über Claude hinaus geschafft. Es wäre nicht über Codex hinausgekommen, da Codex es nicht geschrieben hat und keinen Grund hatte, es zu verteidigen. Das ist die Asymmetrie, die die Schleife ausnutzt, und das ist die Asymmetrie, die es wert ist, ausgeführt zu werden.

Bevor Sie heute Abend den nächsten Plan versenden, führen Sie ihn durch ein zweites Modell. Wenn Sie Codex installiert haben, führen Sie dies manuell aus. Wenn Sie es automatisieren möchten, installieren Sie Claudeex. So oder so – lassen Sie sich von etwas, dem Ihr Plan egal ist, sagen, was daran falsch ist. Sie werden die zehn Minuten nicht bereuen.

Lassen Sie uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

• Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io