Claudeex testé : Claude Code et Codex dans une boucle de plan

Claudeex testé : Claude Code et Codex dans une boucle de plan

Le plan avait l'air propre. Douze étapes numérotées. Schéma d'architecture en markdown. Ordre de migration de la base de données précisé. J'étais sur le point d'appuyer sur « implémenter » quand je me suis souvenu que Claudeex était installé, alors j'ai pensé que je le laisserais fonctionner avant d'expédier quoi que ce soit.

Le premier tour est revenu avec sept problèmes. Trois d’entre eux étaient sérieux. L'un d'eux - "le plan appelle un webhook avant que la ligne de la base de données n'existe" - m'aurait coûté un après-midi complet de débogage à 23 heures un mardi. Le plan que j'étais sur le point d'expédier comportait une condition de concurrence intégrée à la quatrième étape.

C'est à ce moment-là que j'ai arrêté de considérer Claudeex comme une curiosité et que j'ai commencé à y penser comme le genre de chose que j'aurais dû exécuter au cours des six derniers mois.

Si vous ne l'avez pas encore vu, Claudeex est un petit harnais bash et YAML qui transforme Claude Code et la CLI OpenAI Codex en une boucle de planification. Claude Code rédige un plan, Codex l'audite, Claude Code le révise, Codex audite la révision, et ainsi de suite jusqu'à ce que vous atteigniez un plafond rond configurable. La valeur par défaut est trois tours. Le tout repose sur le hook d'arrêt de Claude Code, qui suspend l'exécution entre les tours afin que le script bash puisse demander à codex exec la réussite de l'audit.

J'ai passé les deux dernières semaines à l'exécuter sur un travail client réel - une page d'analyse des visiteurs, un refactoriseur de webhook Stripe, un petit tableau de bord d'administration Laravel - et il y en a suffisamment ici pour que je veuille expliquer ce qui fonctionne, où les coutures apparaissent et pourquoi les boucles de planification à deux modèles sont sur le point de devenir la valeur par défaut pour quelque chose de plus complexe qu'un formulaire CRUD.

Qu'est-ce que Claudeex (au-delà du README)

Le pitch est simple : Claude Code est doué pour rédiger des plans, Codex est doué pour y trouver des trous, et la plupart des bugs de planification sont détectables si vous demandez simplement à un deuxième modèle de lire le plan avec un œil critique. Ainsi, au lieu de vous demander d'être le deuxième modèle, Claudeex automatise les allers-retours.

Mécaniquement, il s'agit de quatre pièces :

1. Un lanceur bash qui répond à une invite, écrit un fichier d'état YAML et démarre Claude Code avec la configuration du hook droit chargée
2. Un fichier d'état YAML qui suit l'invite, le nombre total de tours, l'itération en cours et tous les fichiers de contexte épinglés (comme scope.md ou architecture.md)
3. Un crochet d'arrêt Claude Code qui se déclenche une fois que Claude termine un tour de planification, lit le fichier d'état et décide s'il faut invoquer Codex ou laisser Claude terminer
4. Trois commandes barre oblique — /plan, /review et /cancel — plus une /rollback pour effacer l'état du plan lorsque vous souhaitez une table rase

Le crochet d'arrêt est la partie la plus intelligente. Le crochet d'arrêt de Claude Code se déclenche une fois par tour lorsque Claude finit de répondre](https://code.claude.com/docs/en/hooks) et un crochet d'arrêt qui sort avec le code 2 force Claude à continuer de fonctionner. Claudeex utilise cette astuce de sortie 2 pour réinjecter la transcription d'audit Codex dans la conversation comme si Claude lui-même avait reçu les commentaires d'un réviseur, puis demande à Claude de la réviser. Vu du contexte de Claude Code, cela ressemble à un autre tournant, mais il se trouve que le tournant contient une critique structurée d'un modèle frontière différent.

Si vous avez lu mon détail du workflow à deux agents Claude Code et Codex, le modèle mental est similaire. La différence est que Claudeex intègre la boucle dans la session Claude Code elle-même — vous n'avez pas besoin de transmettre manuellement les transcriptions entre les terminaux ou de copier-coller les critiques. Le crochet le fait.

Pourquoi la planification à deux modèles bat la planification à un modèle

Je veux être prudent ici parce que le cadrage évident – « deux modèles valent mieux qu’un » – est le genre d’affirmation vague que je couperais normalement d’un brouillon. Alors laissez-moi être précis sur ce qui change réellement.

Lorsque Claude Code élabore seul un plan, il fonctionne à partir d'une distribution unique de « à quoi ressemblent les bons plans ». Il a ses propres biais de formation. Il a ses propres angles morts. Lorsque je lui demande de « revérifier le plan », on lui demande essentiellement d'être en désaccord avec lui-même, ce pour quoi les modèles linguistiques sont notoirement mauvais. Il existe des recherches sur la flagornerie et l'auto-cohérence qui expliquent pourquoi : les modèles formés avec RLHF ont tendance à s'engager sur leur première réponse, puis à la défendre, même lorsqu'ils sont invités à critiquer.

Codex est un modèle différent avec un pipeline de formation différent. Le modèle de production actuel dans la CLI Codex est GPT-5.5 (avec GPT-5.4 comme solution de secours si votre compte n'a pas encore été modifié). Lorsque Codex audite un plan rédigé par Claude, il lit de la prose écrite dans un style cognitif légèrement différent et il est beaucoup plus disposé à signaler les éléments que Claude a passés sous silence. L'asymétrie est la valeur. Codex détecte les éléments écrits par Claude ; Claude détecte des éléments que Codex aurait manqués s'il avait rédigé le plan à la place.

En pratique, sur les projets que j'ai exécutés sur Claudeex au cours des deux dernières semaines, le taux de capture des bugs en phase de planification se situe autour de 80 % au cours des deux à trois premiers tours. Après le troisième tour, les rendements marginaux s'amenuisent : Codex commence à signaler des préférences stylistiques plutôt que de réels problèmes. C'est pourquoi la valeur par défaut de trois tours est correcte. J'ai essayé de le définir sur cinq sur un travail complexe et au quatrième tour, Codex se demandait si je devais utiliser une énumération ou une chaîne pour un champ d'état. Au cinquième tour, Codex a changé d'avis à propos du quatrième tour. Trois tours, c'est le juste milieu.

La surface des slash commands

Il existe quatre commandes slash et vous n’en avez réellement besoin que de deux au quotidien.

/plan <prompt> est la bête de somme. Vous lui remettez une description de ce que vous souhaitez construire, épinglez éventuellement certains fichiers de contexte comme scope.md ou architecture.md, et la boucle s'exécute. Brouillons Claude, audits Codex, révisions Claude. À la fin, vous obtenez un plan final avec les suppressions et les ajouts de chaque tour affichés en rouge et vert afin que vous puissiez voir comment le plan a évolué. Si vous avez déjà effectué une révision sérieuse du code et observé la transformation PR d'un ingénieur junior entre la v1 et la v3, la vue différentielle ressemble exactement à cela.

/review est la version en lecture seule. Il prend un plan existant — celui que vous avez écrit, celui qu'un coéquipier a écrit, celui que Claude a écrit lors d'une session précédente — et exécute Codex dessus sans aucune étape de révision. Vous recevez les commentaires de l'audit et c'est tout. Je l'utilise sur des plans que je suis sur le point de confier à un autre développeur ; c'est un deuxième avis bon marché avant le début des travaux.

/cancel est un arrêt d'urgence. Si la boucle déraille – Codex commence à halluciner les dépendances, Claude commence à réécrire la même section en rond – vous pouvez interrompre l'exécution proprement sans laisser le fichier d'état YAML dans un demi-état cassé.

/rollback efface entièrement l'état du plan. Utile lorsque vous souhaitez repartir de zéro sans redémarrer Claude Code.

La syntaxe compte plus que ce à quoi vous vous attendriez. La première fois que j'ai exécuté /plan, je lui ai donné une invite d'une phrase : "créer une page d'analyse des visiteurs qui ne fait pas appel à des tiers". Claude a rédigé un plan raisonnable mais générique. Codex l'a audité et le premier commentaire était "l'invite est trop vague pour être évaluée ; quel est le critère de réussite ?" C'est une fonctionnalité, pas un bug. L'outil optionnel ask-user-input fourni avec Claudeex est spécifiquement là pour ces moments : lorsqu'une invite est trop vague pour être planifiée, elle met la boucle en pause et vous demande des questions de clarification avant de continuer. J'ai appris à diriger avec /plan plus un paragraphe de contexte et un scope.md épinglé, et la qualité de chaque tour s'est ensuite sensiblement améliorée.

À quoi ressemblent réellement les Bash et YAML

Le lanceur est suffisamment petit pour lire de bout en bout. En voici la forme, avec la coupure du bruit :

#!/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"

C’est tout le point d’entrée. Tout le reste réside dans la configuration du hook et dans le fichier d'état. La configuration du hook enregistre un hook d'arrêt pointé sur un petit script shell :

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

Et audit.sh est le pont vers Codex. Le script lit l'état YAML, vérifie la phase actuelle et le nombre de tours, et décide s'il faut appeler Codex ou laisser Claude terminer :

#!/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

Le modèle de sortie 2 fait tout le gros du travail. Comme le décrit la référence des hooks Claude Code, un hook d'arrêt se terminant avec le statut 2 force Claude à continuer à travailler, la sortie stderr du hook étant réinjectée dans la conversation. Claudeex l'utilise pour renvoyer la critique de Codex à Claude comme s'il s'agissait d'un nouveau tour – et Claude répond en révisant le plan en place.

Cela vaut la peine de le dire : c’est du ruban adhésif, mais c’est du bon ruban adhésif. Le système de crochets n’a pas été conçu pour les boucles contradictoires entre modèles. Il a été conçu pour des choses comme le « formatage automatique lors de l'édition » ou le « blocage des commandes dangereuses ». Le fait qu'il puisse être réutilisé pour quelque chose d'aussi élaboré est un petit témoignage de la qualité du choix des primitifs.

La démo que j'ai construite pour la tester sous contrainte

J'avais besoin d'un véritable cas de test, j'ai donc choisi quelque chose que je voulais réellement proposer : un outil d'analyse des visiteurs d'une seule page qui suit les interactions sur mon site sans envoyer de données à un service tiers. Pas de Google Analytics, pas de Plausible, pas de Fathom. Juste mon propre backend collectant les clics, les défilements et le temps passé sur la page de mes propres visiteurs.

La raison pour laquelle il s’agit d’un bon scénario de test Claudeex est qu’il se situe à une intersection délicate entre l’instrumentation frontale, le stockage back-end et la loi sur la confidentialité. Il existe au moins quatre façons de se tromper, et la plupart de ces méthodes sont des erreurs de planification, et non des erreurs de codage. Vous pouvez écrire correctement le JavaScript tout en expédiant quelque chose d'illégal sous GDPR. Vous pouvez concevoir correctement le schéma de base de données tout en créant un système qui fait planter la page sur les réseaux lents. Les bugs se cachent en amont du code.

J'ai épinglé deux fichiers de contexte : scope.md (exigences fonctionnelles, y compris la règle "pas de tiers" et une liste d'événements à suivre) et architecture.md (une esquisse de la stack - backend Laravel, frontend vanilla JS, MySQL pour le stockage, Redis pour la mise en mémoire tampon des événements à haute fréquence). Puis j'ai couru :

/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.

Environ 15 à 20 minutes d'itération plus tard, j'avais un plan que j'allais réellement expédier. Le premier tour a produit une première ébauche raisonnable qui ignorait complètement le flux de consentement : Claude traitait GDPR comme une note de bas de page plutôt que comme une exigence de contrôle. La première critique de Codex s'est ouverte sur "le flux de consentement est totalement absent ; sans lui, aucun événement ne devrait se déclencher", ce qui est exactement le genre de chose qui m'aurait mordu en production. Le deuxième tour a ajouté la porte de consentement mais a introduit un problème différent : il y avait les événements de tampon frontal dans localStorage avant que le consentement ne soit accordé, ce qui est en soi une violation de GDPR dans certaines interprétations. Codex l'a attrapé au deuxième tour. Le troisième tour avait une version propre dans laquelle le frontend ne stocke rien jusqu'à ce que le consentement soit donné, puis vide une file d'attente d'événements enregistrés avec l'intention vers le backend.

La vue différentielle à la fin est la partie qui m'a le plus surpris. Claudeex montre le plan avec les suppressions barrées en rouge et les ajouts surlignés en vert, tour par tour. Vous pouvez voir exactement ce que l’audit a détecté et où le plan a été renforcé. C'est la chose la plus proche que j'ai vue d'une expérience de révision de code pour les plans plutôt que pour le code.

Claudeex contre Claude Code seul

Voici la comparaison à laquelle je reviens sans cesse. Après deux semaines d’exécution des deux – parfois la même invite dans les deux, parfois en alternance en fonction de la complexité du projet – les différences se répartissent en un schéma clair.

fonctionnalités ioniques, travaux sensibles à la sécurité, tout ce qui touche aux données |

Le coût symbolique est réel et mérite d’être honnête. Trois cycles de planification Claude plus trois cycles d'audit Codex ne sont pas gratuits. Pour un script rapide ou un prototype, les frais généraux n'en valent pas la peine : vous pouvez simplement exécuter un plan, le numériser vous-même et l'expédier. Pour tout cas où un bug de planification vous coûterait plus de 30 minutes de débogage, Claudeex s'amortit dès la première sauvegarde.

Le comportement de clarification est l’avantage sous-estimé. L'outil facultatif de demande de saisie à l'utilisateur transforme des invites vagues en conversations productives au lieu de plans erronés en toute confiance. D'après mon expérience, environ un tiers des invites que j'écris sont trop vagues pour pouvoir être planifiées - et Claudeex est le premier outil que j'ai utilisé qui détecte cela de manière cohérente avant de générer un plan qui interprète mal en toute confiance ce que je voulais.

Si vous souhaitez une comparaison connexe, le workflow duo dynamique des plugins Claude Code et Codex est la version manuelle de ce que Claudeex automatise. La route des plugins est plus flexible ; Claudeex est plus opiniâtre. J'utilise les deux, selon le travail.

Où Claudeex échoue

Je veux être honnête à ce sujet car sinon l’article serait inutile.

Il est fragile dans les contextes longs. Lorsque le plan et la transcription d'audit deviennent suffisamment longs (au-delà de 30 000 jetons combinés) Claude commence à perdre la trace du tour dans lequel il se trouve et régénère parfois des sections entières que Codex a déjà approuvées. Il s'agit d'un problème de gestion de contexte, pas d'un bogue Claudeex en soi. Mais c’est la couture où apparaît le ruban adhésif.

Le fichier d'état YAML n'est pas idéal pour le travail parallèle. Si vous essayez d'exécuter deux sessions Claudeex dans le même référentiel en même temps, elles se piétineront mutuellement. Il n'y a pas d'isolation par session par défaut. J'ai contourné ce problème en créant des sous-répertoires par fonctionnalité, mais c'est une véritable verrue.

Codex hallucine parfois les dépendances. Cela se produit environ une fois sur dix. Codex critiquera un plan pour « manque la configuration de Redis Streams » alors que le plan n'a pas réellement besoin de Redis Streams. Claude, compte tenu de cette critique, ajoutera utilement la configuration de Redis Streams. Vous vous retrouvez avec un plan plus complexe qu’il ne devrait l’être, avec une infrastructure introduite par une hallucination d’audit. La solution consiste à lire vous-même les différences de chaque tour et à rejeter les modifications qui ne correspondent pas à la réalité. Ce qui signifie que Claudeex ne supprime pas réellement l'humain de la boucle, mais facilite simplement son travail.

Ce n'est pas magique pour un nouveau travail. Lorsque vous n'avez pas de scope.md ou de architecture.md à épingler, les premiers tours de la boucle passent de nombreux cycles à discuter de la portée. Claudeex fonctionne mieux lorsque vous avez déjà réfléchi à la stratégie et que vous avez besoin d'aide pour la planification tactique. Si vous ne savez toujours pas quoi construire, la boucle ne vous aidera pas à prendre une décision. Il ne fera que continuer à affiner un plan pour la mauvaise chose.

L'asymétrie du modèle peut s'inverser. Codex est bon en audit la plupart du temps. Mais lorsque le sujet dérive vers les domaines forts de Claude – tout ce qui a trait aux outils spécifiques à Anthropic, aux flux de travail agents ou au système de hooks propre à Claude Code, par exemple – le brouillon de Claude est parfois meilleur que l'audit de Codex. Dans ces cas, la boucle ajoute du bruit plutôt que du signal. Vous apprenez à reconnaître quand vous vous trouvez dans l'une de ces zones et exécutez simplement /plan une fois sans l'étape d'audit, ou utilisez /review avec un seuil de troisième ronde plus long.

Au-delà du code : là où ce modèle fonctionne ailleurs

Ce qui m'a vraiment surpris, c'est à quel point le modèle s'étend au-delà du code. J'ai testé Claudeex sur des tâches de planification sans code la semaine dernière et les résultats sont suffisamment intéressants pour être mentionnés.

Je l'ai présenté sur un plan de présentation de diapositives pour un atelier que je donne en mai. La première ébauche de Claude était solide : un flux logique, des répartitions de sections décentes, des estimations de temps raisonnables. L'audit de Codex a signalé que l'atelier ne comportait aucun exercice dans le tiers médian, ce qui signifierait 40 minutes de conversation directe après le pic d'énergie vers la 25e minute. Je ne l'avais pas remarqué. Je l'aurais capté en répétition, mais la répétition aurait eu lieu la veille. Claudeex l'a détecté avant que je perde du temps de préparation.

Je l'ai exécuté sur une spécification de fonctionnalité pour un client indépendant - pas le code, juste le document de description de fonctionnalité qui figurait dans la proposition. Le premier tour est passé. Au deuxième tour, Codex a signalé que le document décrivait le chemin heureux, mais n'a jamais mentionné ce qui se passe lorsque le tiers API est en panne. Le client a signé une version 3 qui comprenait un paragraphe de dégradation gracieuse. Ce paragraphe fait désormais partie contractuellement de ce que je leur dois.

Je ne l'ai pas encore essayé sur des modèles Excel ou des documents financiers, mais je ne vois aucune raison pour que cela ne fonctionne pas. Le modèle est générique : partout où vous pouvez écrire un plan en markdown et demander à un autre modèle de l'auditer, la boucle s'applique. C'est également là que je le vois converger avec le modèle plus large que j'ai couvert dans le mode ultra plan de Claude Code : les deux visent à formaliser l'étape de planification au lieu de la traiter comme un préambule au codage axé sur les vibrations.

Configuration, coût réel et sur quoi l'exécuter

Le faire fonctionner prend environ dix minutes si votre environnement est déjà configuré.

Prérequis :

• Claude Code installé et connecté
• Codex CLI installé (npm i -g @openai/codex ou brew install --cask codex) et connecté
• yq installé (brew install yq sur macOS)
• Un dépôt où vous souhaitez l'exécuter

Installer :

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

Première exécution :

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

La première fois, comptez 15 à 20 minutes pour un plan moyennement complexe. La CLI Codex utilisera le modèle auquel votre compte a accès – GPT-5.5 si vous utilisez la dernière version, GPT-5.4 sinon. Les deux fonctionnent bien pour la critique de type audit ; GPT-5.5 est nettement plus précis pour détecter les problèmes subtils.

En termes de coût, une boucle de trois tours sur un plan moyennement complexe me coûte environ trois à quatre fois le coût d'un seul tour de planification Claude Code. Pour le travail indépendant et client, il s’agit d’une erreur d’arrondi. Pour des expériences personnelles, vous souhaiterez peut-être l'exécuter uniquement sur les problèmes les plus difficiles et laisser /plan (sans la boucle) gérer les petites choses.

Sur quoi l'exécuter en premier : toute fonctionnalité sur laquelle une erreur de planification vous coûterait plus d'une demi-journée de retouche. Flux d’authentification. Intégrations de paiement. Migrations de données. Tout ce qui est simultané. Tout ce qui touche GDPR ou HIPAA. Ce sont les domaines dans lesquels 15 minutes d’audit automatisé sont dix fois plus rentables. Si vous effectuez un travail lié à la sécurité, la même logique s'applique - et le modèle d'agent d'analyseur de sécurité dans Claude Code s'associe naturellement à Claudeex du côté de la planification.

Ignorez-le pour : les corrections de bugs où le bug est déjà isolé, les petits ajustements de l'interface utilisateur, tout ce que vous avez fait auparavant et dont vous pourriez écrire le plan pendant votre sommeil. Les frais généraux n’en valent pas la peine.

Questions fréquemment posées

Qu'est-ce que Claudeex et comment ça marche ?

Claudeex est une boucle de planification itérative dans laquelle Claude Code rédige un plan, la CLI OpenAI Codex l'audite et Claude Code le révise - en répétant pendant un nombre configurable de tours (trois par défaut). Il utilise un crochet d'arrêt Claude Code avec le code de sortie 2 pour réinjecter la critique de Codex dans la conversation comme s'il s'agissait d'un nouveau tour. Pour une présentation complète de l'implémentation de bash et YAML, consultez la section ci-dessus sur le lanceur et le script d'audit.

De combien de tours Claudeex a-t-il besoin pour détecter la plupart des bugs de planification ?

Deux à trois tours détectent environ 80 % des bugs de planification lors de mes tests. Le quatrième tour et les suivants produisent des rendements décroissants et font souvent apparaître des préférences stylistiques plutôt que des problèmes réels. La valeur par défaut de trois tours est bien réglée. Consultez le tableau de comparaison ci-dessus pour obtenir un contexte complet sur le temps et le coût des jetons.

Claudeex fonctionne-t-il pour les tâches de planification sans code ?

Oui. Le modèle fonctionne pour tout plan écrit en markdown qu'un autre modèle peut auditer : plans de diapositives, spécifications de fonctionnalités, propositions de projet. Je l'ai testé sur des présentations d'atelier et sur des spécifications de clients indépendants avec d'excellents résultats. La section « Au-delà du code » ci-dessus présente des exemples spécifiques.

Quelle est la différence entre /plan et /review dans Claudeex ?

/plan exécute la boucle itérative complète : rédiger, auditer, réviser, répéter. /review est en lecture seule : il exécute une fois Codex sur un plan existant et renvoie les commentaires d'audit sans aucune étape de révision. Utilisez /review lorsque vous souhaitez un deuxième avis sur un plan que vous ou un coéquipier avez déjà rédigé.

Claudeex vaut-il le coût supplémentaire du jeton ?

Pour les fonctionnalités de production, les travaux sensibles à la sécurité ou tout ce pour quoi un bug de planification coûterait plus de 30 minutes de débogage – oui. Le coût du jeton de 2,5 à 3x est amorti la première fois qu'il détecte une condition de concurrence critique. Pour les prototypes, les scripts jetables ou le travail que vous avez effectué plusieurs fois auparavant, la surcharge n'est pas justifiée.

Ce que j'ai emporté

Le matin après ma première véritable exécution de Claudeex, je suis revenu et j'ai examiné trois plans que j'avais expédiés le mois précédent – des plans dont j'étais satisfait à l'époque. J'ai parcouru chacun d'eux via /review pour voir ce que Codex aurait capturé.

Tous les trois avaient au moins un problème. Deux avaient des conditions de course que j'avais manquées. Il manquait un chemin de restauration lors d’une migration destructrice qui, en toute honnêteté, aurait été détectée lors de la révision du code – mais seulement si le réviseur y prêtait une attention particulière. Aucun d’entre eux n’a été catastrophique. Les trois auraient été moins embarrassants si l’audit avait eu lieu avant mon expédition au lieu de deux semaines plus tard rétrospectivement.

C'est la partie qui m'a attiré. Pas la démo. Pas la vue différentielle. La prise de conscience que j'avais expédié des plans de qualité moyenne et que je les avais qualifiés de terminés parce que rien dans mon flux de travail ne les avait jamais repoussés. Claude Code ne repousse pas. Je ne repousse pas, car j'ai écrit l'invite et je souhaite que le plan soit bon. La seule chose dans cette boucle qui n'a pas de skin dans le jeu est Codex.

Le modèle qui ne se soucie pas de savoir si votre plan est bon est le modèle que vous souhaitez auditer.

Le plan que j'ai presque expédié avant d'installer Claudeex - celui avec la condition de concurrence intégrée à la quatrième étape - m'aurait dépassé. Cela aurait dépassé Claude. Il n’aurait pas dépassé Codex, car Codex ne l’a pas écrit et n’avait aucune raison de le défendre. C’est l’asymétrie que la boucle exploite, et c’est l’asymétrie qui vaut la peine d’être exécutée.

Ce soir, avant d'expédier le prochain plan que vous êtes sur le point d'expédier, exécutez-le via un deuxième modèle. Si Codex est installé, faites-le manuellement. Si vous souhaitez que cela soit automatisé, installez Claudeex. Quoi qu’il en soit, laissez quelque chose qui ne se soucie pas de votre plan vous dire ce qui ne va pas. Vous ne regretterez pas les dix minutes.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io