Claudeex getest: Claude Code en Codex in een plan-loop

Claudeex getest: Claude Code en Codex in een plan-loop

Het plan zag er schoon uit. Twaalf genummerde treden. Architectuurdiagram in prijsverlaging. Volgorde voor databasemigratie aangegeven. Ik stond op het punt op "implementeren" te drukken toen ik me herinnerde dat ik Claudeex had geïnstalleerd, dus ik dacht dat ik het zou laten draaien voordat ik iets zou verzenden.

Ronde één kwam terug met zeven problemen. Drie ervan waren serieus. Eén daarvan ('het plan roept een webhook aan voordat de databaserij bestaat') zou me op dinsdag om 23.00 uur een hele middag foutopsporing hebben gekost. Bij het plan dat ik op het punt stond te verzenden, was in stap vier een racevoorwaarde ingebakken.

Dat is het moment waarop ik Claudeex niet langer als een curiosum zag, maar begon te beschouwen als iets dat ik de afgelopen zes maanden had moeten doen.

Als je het nog niet hebt gezien: Claudeex is een klein bash- en YAML-harnas dat Claude Code en de OpenAI Codex CLI in een planningslus verandert. Claude Code stelt een plan op, Codex controleert het, Claude Code herziet, Codex controleert de revisie, enzovoort totdat u een configureerbare round cap bereikt. Standaard is drie ronden. Het geheel draait op de stop hook van Claude Code, die de uitvoering tussen beurten pauzeert, zodat het bash-script naar codex exec kan worden gestuurd voor de auditpas.

Ik heb de afgelopen twee weken het op echt klantwerk uitgevoerd - een bezoekersanalysepagina, een Stripe-webhook-refactor, een klein Laravel-beheerdersdashboard - en er is hier genoeg dat ik wil doornemen wat werkt, waar de naden zichtbaar zijn, en waarom planningslussen met twee modellen op het punt staan ​​de standaard te worden voor iets complexers dan een CRUD-formulier.

Wat Claudeex eigenlijk is (buiten de README)

De pitch is eenvoudig: Claude Code is goed in het opstellen van plannen, Codex is goed in het vinden van gaten erin, en de meeste planningsfouten zijn te ontdekken als je een tweede model het plan met een kritische blik laat lezen. Dus in plaats van jij te vragen om het tweede model te zijn, automatiseert Claudeex het heen-en-weer-verkeer.

Mechanisch gezien bestaat het uit vier delen:

1. Een bash-opstartprogramma dat een prompt neemt, een YAML-statusbestand schrijft en Claude Code start met de rechtse hoekconfiguratie geladen
2. Een YAML-statusbestand dat de prompt, het totale aantal rondes, de huidige iteratie en eventuele vastgezette contextbestanden (zoals scope.md of architecture.md) bijhoudt
3. Een Claude Code stophaak die wordt afgevuurd nadat Claude een planningsbeurt heeft voltooid, het statusbestand leest en beslist of Codex moet worden aangeroepen of Claude moet worden voltooid
4. Drie slash-opdrachten — /plan, /review en /cancel — plus een /rollback voor het wissen van de planstatus als u een schone lei wilt

De stophaak is het slimme onderdeel. Claude Code's stophaak vuurt één keer per beurt wanneer Claude klaar is met reageren, en een stophaak die eindigt met code 2 dwingt Claude om te blijven werken. Claudeex gebruikt deze exit-2-truc om het Codex-audittranscript terug in het gesprek te injecteren alsof Claude zelf feedback van een recensent heeft ontvangen, en vraagt ​​Claude vervolgens om te herzien. Vanuit de context van Claude Code lijkt het gewoon een nieuwe wending, maar de wending bevat toevallig een gestructureerde kritiek van een ander grensmodel.

Als je mijn overzicht van de Claude Code en Codex twee-agent workflow hebt gelezen, is het mentale model vergelijkbaar. Het verschil is dat Claudeex de lus in de Claude Code-sessie zelf inbouwt - u hoeft transcripties niet handmatig tussen terminals door te sluisen of kritiek te kopiëren en te plakken. De haak doet het.

Waarom planning met twee modellen beter is dan planning met één model

Ik wil hier voorzichtig mee zijn, omdat de voor de hand liggende formulering – ‘twee modellen zijn beter dan één’ – het soort vage bewering is dat ik normaal gesproken uit een concept zou schrappen. Dus laat me specifiek worden over wat er feitelijk verandert.

Wanneer Claude Code alleen een plan opstelt, opereert het vanuit een enkele distributie van 'hoe goede plannen eruitzien'. Het heeft zijn eigen trainingsvooroordelen. Het heeft zijn eigen blinde vlekken. Als ik het vraag om 'het plan nog eens te controleren', wordt het feitelijk gevraagd het niet met zichzelf eens te zijn, iets waar taalmodellen berucht om zijn. Er is onderzoek naar sycofantie en zelfconsistentie dat inzicht geeft in het waarom: modellen die met RLHF zijn getraind, hebben de neiging zich aan hun eerste antwoord te houden en dit vervolgens te verdedigen, zelfs als ze worden gevraagd kritiek te leveren.

Codex is een ander model met een andere trainingspijplijn. Het huidige productiemodel in de Codex CLI is GPT-5.5 (met GPT-5.4 als fallback als uw account nog niet is geüpgraded). Wanneer Codex een door Claude geschreven plan controleert, leest het proza ​​dat in een iets andere cognitieve stijl is geschreven, en is het veel meer bereid om dingen te markeren die Claude verdoezeld heeft. De asymmetrie is de waarde. Codex vangt dingen op Claude schreef verleden; Claude vangt dingen op die Codex gemist zou hebben als het in plaats daarvan het plan had opgesteld.

In de praktijk bedraagt ​​het vangstpercentage voor bugs in de planningsfase bij de projecten die ik de afgelopen twee weken Claudeex heb doorlopen, ergens rond de 80% in de eerste twee tot drie rondes. Na ronde drie worden de marginale rendementen mager: Codex begint stilistische voorkeuren te signaleren in plaats van daadwerkelijke problemen. Daarom is de standaardwaarde van drie ronden correct. Ik probeerde het op vijf in te stellen voor een complexe taak en de vierde ronde was Codex die ruzie maakte over de vraag of ik een enum of een string moest gebruiken voor een statusveld. Ronde vijf was dat Codex van gedachten veranderde over ronde vier. Drie rondes is de goede plek.

Het slash-command oppervlak

Er zijn vier slash-opdrachten en je hebt er eigenlijk maar twee nodig per dag.

/plan <prompt> is het werkpaard. Je geeft het een beschrijving van wat je wilt bouwen, zet optioneel enkele contextbestanden vast, zoals scope.md of architecture.md, en de lus wordt uitgevoerd. Claude concepten, Codex audits, Claude herzieningen. Aan het einde krijg je een definitief plan met de schrappingen en toevoegingen van elke ronde weergegeven in rood en groen, zodat je kunt zien hoe het plan evolueerde. Als je ooit een serieuze code-review hebt gedaan en de PR-transformatie van een junior engineer tussen v1 en v3 hebt gezien, voelt de diff-weergave precies zo aan.

/review is de alleen-lezen versie. Er is een bestaand plan voor nodig (een plan dat jij hebt geschreven, een plan dat een teamgenoot heeft geschreven, een plan dat Claude in een vorige sessie heeft geschreven) en voer Codex eroverheen uit zonder enige revisiestap. U krijgt de auditopmerkingen en dat is alles. Ik gebruik dit voor plannen die ik ga overdragen aan een andere ontwikkelaar; het is een goedkope second opinion voordat de werkzaamheden beginnen.

/cancel is een noodstop. Als de lus ontspoort - Codex begint afhankelijkheden te hallucineren, Claude begint dezelfde sectie in cirkels te herschrijven - kun je de run netjes onderbreken zonder het YAML-statusbestand in een kapotte halve staat achter te laten.

/rollback wist de planstatus volledig. Handig als u opnieuw wilt beginnen vanaf een schone lei zonder Claude Code opnieuw te starten.

De syntaxis is belangrijker dan je zou verwachten. De eerste keer dat ik /plan uitvoerde, gaf ik het een prompt van één zin: "bouw een bezoekersanalysepagina die geen gebruik maakt van derden." Claude schreef een redelijk maar generiek plan. Codex heeft het gecontroleerd en de eerste reactie was: "de prompt is te vaag om te evalueren; wat is het succescriterium?" Dat is een feature, geen bug. De optionele ask-user-input tool die bij Claudeex wordt geleverd, is er specifiek voor deze momenten: wanneer een prompt te vaag is om er tegenin te gaan, pauzeert deze de lus en stelt hij u verduidelijkende vragen voordat hij verdergaat. Ik leerde leiding geven met /plan plus een paragraaf met context en een vastgezette scope.md, en de kwaliteit van elke ronde daarna verbeterde merkbaar.

Hoe de Bash en YAML er eigenlijk uitzien

Het opstartprogramma is klein genoeg om van begin tot eind te lezen. Hier is de vorm ervan, met de ruis verwijderd:

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

Dat is het hele instappunt. Al het andere bevindt zich in de hook-configuratie en het statusbestand. De hook-configuratie registreert een stop-hook die naar een klein shell-script wijst:

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

En audit.sh is de brug naar Codex. Het script leest de status YAML, controleert de huidige fase- en rondetelling en beslist of Codex moet worden aangeroepen of Claude moet worden voltooid:

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

Het exit-2-patroon doet al het zware werk. Zoals de Claude Code hooks-referentie beschrijft, dwingt een stop hook die eindigt met status 2 Claude om door te werken, waarbij de stderr-uitvoer van de hook terug in het gesprek wordt geïnjecteerd. Claudeex gebruikt dat om de kritiek van Codex terug te sturen naar Claude alsof het een nieuwe wending is - en Claude reageert door het bestaande plan te herzien.

Het is de moeite waard om te zeggen: dit is ducttape, maar het is goede ducttape. Het haaksysteem is niet ontworpen voor cross-model vijandige lussen. Het is ontworpen voor zaken als 'automatisch formatteren bij bewerken' of 'gevaarlijke opdrachten blokkeren'. Het feit dat het kan worden hergebruikt voor zoiets uitgebreids is een klein bewijs van hoe goed de primitieven zijn gekozen.

De demo die ik heb gebouwd om hem te testen

Ik had een echte testcase nodig, dus heb ik iets uitgekozen dat ik eigenlijk wilde verzenden: een bezoekersanalysetool van één pagina die interacties op mijn site bijhoudt zonder gegevens naar een externe service te sturen. Geen Google Analytics, geen Plausibel, geen Fathom. Gewoon mijn eigen backend die klikken, scrolls en tijd op de pagina van mijn eigen bezoekers verzamelt.

De reden dat dit een goede Claudeex-testcase is, is dat het zich op een lastig kruispunt bevindt van frontend-instrumentatie, backend-opslag en privacywetgeving. Er zijn minstens vier manieren om het fout te doen, en de meeste van die manieren zijn planningsfouten, geen codeerfouten. U kunt het JavaScript correct schrijven en toch iets illegaals verzenden onder GDPR. U kunt het databaseschema correct ontwerpen en toch een systeem creëren dat de pagina op langzame netwerken crasht. De bugs verbergen zich stroomopwaarts van de code.

Ik heb twee contextbestanden vastgemaakt: scope.md (functionele vereisten, inclusief de regel "geen derden" en een lijst met gebeurtenissen die moeten worden gevolgd) en architecture.md (een schets van de stack: Laravel-backend, vanille JS-frontend, MySQL voor opslag, Redis voor het bufferen van hoogfrequente gebeurtenissen). Then I ran:

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

Ongeveer 15 tot 20 minuten iteratie later had ik een plan dat ik daadwerkelijk zou verzenden. De eerste ronde leverde een redelijk eerste ontwerp op dat de toestemmingsstroom volledig negeerde: Claude behandelde GDPR als een voetnoot in plaats van als een poortvereiste. De eerste kritiek van Codex begon met "de toestemmingsstroom ontbreekt volledig; zonder deze zouden er geen gebeurtenissen moeten plaatsvinden", wat precies het soort dingen is dat mij tijdens de productie zou hebben gebeten. Ronde twee voegde de toestemmingspoort toe, maar introduceerde een ander probleem: er waren frontendbuffergebeurtenissen in localStorage voordat toestemming werd verleend, wat op zichzelf in sommige interpretaties een GDPR-schending is. Codex ving dat op in ronde twee. Ronde drie had een schone versie waarbij de frontend niets opslaat totdat toestemming is gegeven, en vervolgens een wachtrij met intent-recorded gebeurtenissen naar de backend spoelt.

Het diff-zicht aan het einde was het deel dat mij het meest verraste. Claudeex toont het plan met rood doorgestreepte weglatingen en groen gemarkeerde toevoegingen, ronde voor ronde. Je kunt precies zien wat de audit opleverde en waar het plan versterkt werd. Het komt het dichtst in de buurt van een codebeoordelingservaring voor plannen in plaats van code.

Claudeex versus Claude Code alleen

Hier is de vergelijking waar ik steeds op terugkom. Na twee weken beide te hebben uitgevoerd (soms dezelfde prompt door beide, soms afwisselend op basis van de complexiteit van het project) vormen de verschillen een duidelijk patroon.

ion-functies, veiligheidsgevoelig werk, alles wat met gegevens te maken heeft |

De symbolische kosten zijn reëel en de moeite waard om eerlijk over te zijn. Drie rondes Claude-planning plus drie rondes Codex-audit zijn niet gratis. Voor een snel script of een prototype is de overhead niet de moeite waard; u kunt gewoon een plan uitvoeren, het zelf scannen en verzenden. Voor alles waarbij een planningsfout u meer dan 30 minuten debuggen zou kosten, betaalt Claudeex zichzelf terug bij de eerste keer opslaan.

Het verduidelijkingsgedrag is het onderschatte voordeel. De optionele tool voor invoer door de gebruiker verandert vage aanwijzingen in productieve gesprekken in plaats van vol vertrouwen verkeerde plannen. In mijn ervaring is ongeveer een derde van de aanwijzingen die ik schrijf te vaag om tegen te plannen - en Claudeex is de eerste tool die ik heb gebruikt die dat consequent onderkent voordat een plan wordt gegenereerd dat zelfverzekerd verkeerd interpreteert wat ik wilde.

Als je een gerelateerde vergelijking wilt: de Claude Code en Codex plug-in dynamische duo-workflow is de handmatige versie van wat Claudeex automatiseert. De plug-inroute is flexibeler; Claudeex is meer eigenwijs. Ik gebruik beide, afhankelijk van de taak.

Waar Claudeex tekort schiet

Ik wil hier eerlijk over zijn, omdat het artikel anders nutteloos zou zijn.

Het is broos in lange contexten. Wanneer het plan en het audittranscript lang genoeg worden (ergens meer dan 30.000 tokens gecombineerd) begint Claude uit het oog te verliezen in welke ronde het zich bevindt en regenereert het soms hele secties die Codex al heeft goedgekeurd. Dit is een probleem met contextbeheer en niet per se een Claudeex-bug. Maar het is de naad waar de ducttape zichtbaar is.

Het YAML-statusbestand is niet geschikt voor parallel werk. Als u twee Claudeex-sessies tegelijkertijd in dezelfde repo probeert uit te voeren, zullen ze elkaars statusbestanden vertrappen. Er is standaard geen isolatie per sessie. Ik heb er omheen gewerkt door submappen per functie te maken, maar het is een echte wrat.

Codex hallucineert soms afhankelijkheden. Dit gebeurt ongeveer één op de tien rondes. Codex zal een plan bekritiseren omdat het "de Redis Streams-installatie mist" terwijl het plan Redis Streams niet echt nodig heeft. Claude zal, gezien die kritiek, nuttig de Redis Streams-installatie toevoegen. Je krijgt uiteindelijk een plan dat complexer is dan nodig is, waarbij de infrastructuur wordt geïntroduceerd door een audithallucinatie. De oplossing is om zelf de verschillen van elke ronde te lezen en wijzigingen af ​​te wijzen die niet overeenkomen met de werkelijkheid. Dat betekent dat Claudeex de mens niet daadwerkelijk uit de kringloop verwijdert, maar het werk van de mens alleen maar eenvoudiger maakt.

Het is geen magie voor greenfield-werk. Als je geen scope.md of architecture.md hebt om vast te pinnen, besteden de eerste rondes van de lus veel cycli aan discussie over de reikwijdte. Claudeex werkt het beste als u al strategisch heeft nagedacht en hulp wilt bij de tactische planning. Als je nog steeds aan het uitzoeken bent wat je moet bouwen, zal de lus je niet helpen beslissen. Het zal alleen maar een plan voor het verkeerde blijven verfijnen.

De modelasymmetrie kan omslaan. Codex is meestal goed in audits. Maar als het onderwerp afdwaalt naar de sterkere gebieden van Claude - alles wat te maken heeft met antropische specifieke tools, agentische workflows of Claude Code's eigen hooks-systeem, bijvoorbeeld - is het concept van Claude soms beter dan de audit van Codex. In die gevallen voegt de lus ruis toe in plaats van signaal. U leert herkennen wanneer u zich in een van die zones bevindt en voert /plan slechts één keer uit zonder de auditstap, of gebruikt /review met een langere drempel van ronde drie.

Voorbij code: waar dit patroon nog meer werkt

Wat me echt verbaasde, is hoe goed het patroon zich uitstrekt voorbij de code. Ik heb Claudeex de afgelopen week getest op niet-codeplanningstaken en de resultaten zijn interessant genoeg om te vermelden.

Ik heb het op een diadeck-overzicht weergegeven voor een workshop die ik in mei geef. Het eerste concept van Claude was solide: een logische stroom, behoorlijke sectie-indelingen, redelijke tijdsschattingen. Uit de audit van Codex bleek dat de workshop geen oefeningen had in het middelste derde deel, wat zou betekenen dat er 40 minuten open gepraat zou worden na de energiepiek rond minuut 25. Dat had ik niet gemerkt. Ik zou het tijdens de repetitie hebben opgemerkt, maar de repetitie zou de avond ervoor hebben plaatsgevonden. Claudeex ving het op voordat ik voorbereidingstijd had verspild.

Ik heb het uitgevoerd op basis van een functiespecificatie voor een freelanceklant - niet de code, maar alleen het functiebeschrijvingsdocument dat in het voorstel zat. Ronde één is voorbij. Ronde twee markeerde Codex dat het document het gelukkige pad beschreef, maar nooit vermeldde wat er gebeurt als de externe API niet beschikbaar is. De klant tekende af voor een v3 met een sierlijke degradatieparagraaf. Die paragraaf maakt nu contractueel deel uit van wat ik hen verschuldigd ben.

Ik heb het nog niet geprobeerd op Excel-modellen of financiële documenten, maar ik zie geen reden waarom het niet zou werken. Het patroon is generiek: overal waar je een plan in afwaardering kunt schrijven en een ander model kunt vragen het te controleren, is de lus van toepassing. Dit is ook waar ik het zie convergeren met het bredere patroon dat ik heb behandeld in Claude Code's ultraplanmodus - beide gaan over het formaliseren van de planningsstap in plaats van deze te behandelen als een door vibraties aangedreven inleiding tot codering.

Installatie, werkelijke kosten en waarop u het moet uitvoeren

Als uw omgeving al is ingesteld, duurt het ongeveer tien minuten om het actief te krijgen.

Prerequisites:

• Claude Code geïnstalleerd en aangemeld
• Codex CLI geïnstalleerd (npm i -g @openai/codex of brew install --cask codex) en aangemeld
• yq geïnstalleerd (brew install yq op macOS)
• Een repository waar u het wilt uitvoeren

Install:

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

First run:

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

Reken de eerste keer op 15 tot 20 minuten voor een redelijk complex plan. De Codex CLI gebruikt het model waartoe uw account toegang heeft: GPT-5.5 als u de nieuwste versie gebruikt, en GPT-5.4 als dat niet het geval is. Beide werken prima voor kritiek in auditstijl; GPT-5.5 is aanzienlijk scherper in het opmerken van subtiele problemen.

Wat de kosten betreft kost een lus van drie ronden op een redelijk complex plan ongeveer drie tot vier keer de kosten van een enkele Claude Code-planningsbeurt. Voor freelancewerk en werk voor klanten is dat een afrondingsfout. Voor persoonlijke experimenten zou je het misschien alleen op de moeilijkere problemen willen uitvoeren en /plan (zonder de lus) de kleine dingen laten afhandelen.

Waar moet u het eerst op uitvoeren: elke functie waarbij een planningsfout u meer dan een halve dag aan herbewerking zou kosten. Authenticatiestromen. Betalingsintegraties. Datamigraties. Alles met gelijktijdigheid. Alles wat te maken heeft met GDPR of HIPAA. Dit zijn de gebieden waar 15 minuten geautomatiseerde audit zichzelf tien keer terugbetaalt. Als u werk doet dat verband houdt met beveiliging, is dezelfde logica van toepassing - en het patroon van de beveiligingsscanneragent in Claude Code past op natuurlijke wijze bij Claudeex aan de planningskant.

Sla dit over: bugfixes waarbij de bug al is geïsoleerd, kleine aanpassingen aan de gebruikersinterface, alles wat u eerder hebt gedaan en waar u in uw slaap een plan voor kunt schrijven. De overhead is het niet waard.

Veelgestelde vragen

Wat is Claudeex en hoe werkt het?

Claudeex is een iteratieve planningslus waarbij Claude Code een plan opstelt, de OpenAI Codex CLI het controleert, en Claude Code herziet – dit wordt herhaald voor een configureerbaar aantal rondes (standaard drie). Het gebruikt een Claude Code-stophaak met exitcode 2 om de kritiek van Codex terug in het gesprek te injecteren alsof het een nieuwe wending is. Voor een volledig overzicht van de bash- en YAML-implementatie, zie het gedeelte hierboven over het opstartprogramma en het auditscript.

Hoeveel rondes heeft Claudeex nodig om de meeste planningsbugs op te vangen?

In twee tot drie rondes worden tijdens mijn tests ongeveer 80% van de planningsfouten opgespoord. Ronde vier en daarna levert afnemende opbrengsten op en brengt vaak stilistische voorkeuren aan het licht in plaats van feitelijke problemen. De standaard van drie rondes is goed afgestemd. Zie de vergelijkingstabel hierboven voor de volledige context over tijd en tokenkosten.

Werkt Claudeex voor niet-code planningstaken?

Ja. Het patroon werkt voor elk plan dat in prijsverlagingen is geschreven en dat een ander model kan controleren: diacontouren, functiespecificaties, projectvoorstellen. Ik heb het getest op workshopdecks en freelance klantspecificaties met sterke resultaten. In het gedeelte 'Beyond Code' hierboven worden specifieke voorbeelden besproken.

Wat is het verschil tussen /plan en /review in Claudeex?

/plan voert de volledige iteratieve lus uit: concept, audit, herziening, herhaling. /review is alleen-lezen: het voert Codex één keer uit over een bestaand plan en retourneert de auditopmerkingen zonder enige revisiestap. Gebruik /review als u een second opinion wilt over een plan dat u of een teamgenoot al heeft geschreven.

Is Claudeex de extra tokenkosten waard?

Voor productiefuncties, beveiligingsgevoelig werk of iets waarbij een planningsfout meer dan 30 minuten debuggen zou kosten: ja. De tokenkosten van 2,5-3x betalen zichzelf terug de eerste keer dat er een raceconditie wordt gedetecteerd. Voor prototypes, wegwerpscripts of werk dat je al vele malen eerder hebt gedaan, is de overhead niet gerechtvaardigd.

Wat ik hiervan meeneem

The morning after my first real Claudeex run, I went back and looked at three plans I had shipped in the previous month — plans I had been happy with at the time. Ik heb ze allemaal door /review gehaald om te zien wat Codex zou hebben opgevangen.

Alle drie hadden minstens één probleem. Twee hadden raceomstandigheden die ik had gemist. One had a missing rollback path on a destructive migration that, in fairness, would have been caught in code review — but only if the reviewer was paying close attention. Geen van hen was catastrofaal. Alle drie zouden minder gênant zijn geweest als de audit had plaatsgevonden voordat ik de bestelling had verzonden, in plaats van twee weken later achteraf.

Dat is het deel dat mij te pakken heeft gekregen. Niet de demo. Niet de diff-weergave. Het besef dat ik plannen van middelmatige kwaliteit had verzonden en ze klaar had genoemd omdat niets in mijn workflow ze ooit had teruggedrongen. Claude Code duwt niet terug. Ik ga niet terug, omdat ik de prompt heb geschreven en ik hoop dat het plan goed zal zijn. Het enige in deze lus dat geen skin in het spel heeft, is Codex.

Het model dat er niet om geeft of uw plan goed is, is het model dat u wilt laten controleren.

Het plan dat ik bijna had verzonden voordat ik Claudeex installeerde – het plan met de raceconditie ingebakken in stap vier – zou aan mij voorbij zijn gegaan. Het zou voorbij Claude zijn gekomen. Het zou niet voorbij Codex zijn gekomen, omdat Codex het niet heeft geschreven en geen reden had om het te verdedigen. Dat is de asymmetrie die de lus uitbuit, en dat is de asymmetrie die het de moeite waard maakt om te draaien.

Voordat u het volgende plan verzendt, moet u vanavond een tweede model doornemen, voordat u het volgende plan verzendt. Als u Codex hebt geïnstalleerd, doe dit dan handmatig. Als je het geautomatiseerd wilt hebben, installeer dan Claudeex. Hoe dan ook: laat iets dat niets om je plan geeft, je vertellen wat er mis mee is. Je zult geen spijt krijgen van de tien minuten.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io