Claude Code + Codex: de Dynamic Duo-workflow die levert
Ik had hem bijna niet geïnstalleerd. De Codex plugin-melding bereikte Claude Code op een vrijdagmiddag, en mijn onmiddellijke reactie was dezelfde als die van de meeste ingenieurs als de tool van een concurrent in hun primaire tool verschijnt: "dit wordt een janky bridge die elke andere release verbreekt." Ik had een Laravel-implementatie om op te passen en drie blogposts stonden in de wachtrij via de agent stack. Plug-ininstallaties stonden niet op de lijst.
Toen zag ik zaterdagochtend hoe Claude Code vrolijk een schemamigratie met vijf tabellen plantte, het migratiebestand verzond en een externe-sleutelbeperking miste die de staging op maandag zou hebben vernietigd. Niet omdat Claude slecht is. Omdat Claude zich in de 'build-modus' bevond, en niet in de 'sceptische modus'. Dat is de kloof die Codex plugin voor Claude Code wil dichten, en die zaterdag is de dag waarop ik stopte met het kiezen van partij in het modellendebat.
Ik gebruik beide modellen nu zes weken achter elkaar. Claude Code op Opus 4.7 als de primaire bouwer. Codex op GPT 5.5 als de plaatselijke scepticus. Verschillende rollen, dezelfde terminal, één workflow. De kostenwiskunde werkt. De uitvoerkwaliteit is verbeterd op een manier die ik niet had verwacht. En de domme model-tribal-argumenten waar ik mijn energie aan verspilde, verdwenen op het moment dat de eerste /codex:review terugkwam met drie nummers die ik zonder nadenken zou hebben verzonden.
Dit is de werkstroom. De daadwerkelijke opdrachten, de daadwerkelijke overdrachten, de daadwerkelijke instellingen voer ik uit op echte clientbuilds en op mijn eigen contentstapel met meerdere merken. Blijf bij mij tijdens patroon drie - dat is waar de kostenbesparingen veranderen van 'leuk' naar 'dit verandert mijn planniveau volgende maand'.
Waarom het single-modeldebat de verkeerde vraag is
De AI Twitter-loop zit al twee jaar vast aan hetzelfde argument: welk codeermodel het beste is. GPT 5.5 versus Opus 4.7. Codex versus Claude Code. Cursor versus windsurf versus Zed. Kies een stam, verdedig deze op de tijdlijn en herhaal de volgende releasecyclus.
Dit is wat mij opviel toen ik stopte met het spelen van dat spel. De twee toonaangevende modellen hebben werkelijk verschillende vormen. Claude Code, vooral op Opus 4.7, is een creatieve generalist. Het plant goed over architectuur, kopiëren, ontwerptokens en productstroom. Het schrijft zelfverzekerd. Het hallucineert ook vol vertrouwen - en dat is de afweging waarvoor je je aanmeldt als je een model wilt dat wordt verzonden in plaats van te blijven staan. Ik heb de verschillen op modelniveau besproken in GPT 5.5 versus Opus 4.7 getest op echte codeerbuilds en in mijn praktijkgerichte recensie van GPT 5.5 in Codex. De korte versie: het zijn aanvullingen, geen vervangingen.
Codex op GPT 5.5 is een ander dier. Het is symbolisch gierig. Het is chirurgisch. Het houdt van een gefocust diff. Vraag het om een enkele functie te herstructureren en het levert een schone patch op met redenering over randgevallen. Vraag het om een SaaS-dashboard helemaal opnieuw te plannen en het schrijft kortere, minder ambitieuze steigers dan Claude. Geen van beide is een fout: het is persoonlijkheid.
Het dynamische duo-idee is eenvoudig: stop met vragen welke "beter" is en begin te vragen welke op welke stoel moet worden gezet. Bouwer versus recensent. Tekenaar versus redacteur. Optimist versus scepticus. De native Codex plugin maakt de overdracht zo snel dat u het daadwerkelijk doet, in plaats van te zweren dat u het zult doen en nooit het tweede gereedschap zult openen.
Er vindt hier een mentale verschuiving plaats die een week of twee in beslag neemt. Je denkt niet langer aan "de AI" als iets waar je aan werkt. Je begint te denken aan ‘het team’ – twee specialisten die het productief oneens zijn, waarbij jij oordeelt. Alleen al die framing veranderde de hoeveelheid code die ik bij de eerste implementatie schoon verscheepte.
Maar voordat dat allemaal werkt, moet de plug-in zijn geïnstalleerd en moeten de juiste slash-opdrachten binnen handbereik zijn. Dat is waar de meeste pijn bij vroege adoptie plaatsvindt.
De Codex-plug-in installeren (de twee minuten durende versie)
De plug-in wordt rechtstreeks door OpenAI gepubliceerd. Dat is belangrijk omdat het het ondersteuningsmodel bepaalt. Dit is geen gemeenschapsbrug die elke andere Claude Code-release doorbreekt. Het is een officieel onderhouden integratie die aan beide kanten wordt bijgewerkt.
De installatie is in plug-in-marktplaatsstijl. Binnen Claude Code voegt u de OpenAI-marktplaats toe en installeert u vervolgens de codex-plug-in ervan. De Codex plugin GitHub repository bevat de huidige opdracht, maar de essentie bestaat uit twee regels /plugin marketplace add en /plugin install. Daarna heb je een nieuwe set slash-opdrachten onder de codex:-naamruimte.
Het eerste wat ik zou doen is /codex:setup uitvoeren om te bevestigen dat de lokale Codex CLI bereikbaar is. De plug-in sluit aan op de Codex CLI onder de motorkap - het is geen zelfstandige API-client, het is een wrapper die de context van Claude Code doorsluist naar Codex-sessies en de resultaten terugsluist. Als uw Codex CLI niet is aangemeld of niet het juiste abonnement heeft, zal de plug-in u dit vertellen en kunt u het probleem één keer oplossen.
Een opmerking over de plannen, want dit is waar de meeste mensen de fout in gaan. Claude Code leeft van het Anthropic-abonnement waarvoor u al betaalt. Codex leeft op zijn eigen OpenAI-abonnement. De combinatie maakt het duo kosteneffectief, en ik zal in een paar secties op die prijsberekening ingaan - maar je hebt ze allebei nodig, en je hebt ze nodig op niveaus die passen bij hoe agressief je ze allemaal gaat gebruiken.
Het slash-commandooppervlak dat u dagelijks gebruikt, is klein. De twee grote zijn /codex:review voor inline codebeoordeling van alles wat zich in uw huidige Claude Code-context bevindt, en /codex:rescue voor volledige codebase-audits of gedelegeerde taken die op de achtergrond worden uitgevoerd. Daar omheen zitten /codex:status, /codex:result en /codex:cancel voor het beheren van asynchrone runs. Er is ook een beoordelingspoortvlag op setup-niveau — /codex:setup --enable-review-gate — die Codex bij elke Claude-beurt in een Stop-hook-recensent verandert. Die laatste is krachtig, duur, en ik zal je precies vertellen wanneer je hem moet inschakelen.
Dat is de inventaris. Nu de daadwerkelijke workflows.
Workflow 1: De tegenstrijdige planningscyclus
Dit is het patroon dat ik het vaakst gebruik, en het patroon dat stroomafwaarts de grootste symbolische besparingen oplevert.
De installatie is eenvoudig. Claude Code stelt eerst het implementatieplan op: schema, modules, contractoppervlakken, volgorde van wijzigingen. Ik heb het hier lang laten duren. Een planningssessie van 30 minuten tot 90 minuten met Claude in de planmodus levert een compacte prijsopgave op met specifieke bestandspaden, functiehandtekeningen en migratiestappen. Dit is de thuisbasis van Claude. Het is goed in architectuur en in het verhalend uitleggen waarom de architectuur zo is vormgegeven.
Voordat ik een implementatieregel schrijf, activeer ik Codex. Het oorspronkelijke commando is /codex:review tegen het plandocument, maar in de praktijk vraag ik het vijandig: "bekijk dit plan alsof jij de ingenieur bent die deze code over zes maanden zal erven en vijandig staat tegenover de oorspronkelijke auteur." Dat kader is belangrijk. Een beleefde recensie geeft je cosmetische feedback. Een vijandige framing geeft je de bugs waar je echt om geeft.
Wat terugkomt is het soort feedback waarvoor je een senior engineer zou betalen. Bij de Laravel-migratie die ik bovenaan noemde, markeerde Codex de ontbrekende externe-sleutelbeperking, een kolom voor zachte verwijdering die wel in de bovenliggende tabel stond maar ontbrak in de onderliggende tabel, en een unieke index die bij gelijktijdige schrijfbewerkingen een impasse zou hebben veroorzaakt. Geen van deze zou alleen al zichtbaar zijn geweest vanuit het migratiebestand; Codex leidde ze af uit het bredere schema en de controllerlogica die met dezelfde tabellen te maken had.
De lus wordt vervolgens uitgevoerd: Claude werkt het plan bij, Codex controleert opnieuw, Claude wordt opnieuw bijgewerkt. Meestal zijn twee rondes voldoende. Drie rondes betekende dat het plan vanuit een andere hoek moest worden herschreven en dat Claude de oorspronkelijke fout herstelde. Als ik zie dat er een derde ronde nodig is, schrap ik het plan en begin ik opnieuw met een andere ontbinding.
Hier is het kosteninzicht dat mij een maand kostte om te internaliseren. Tegenstrijdige planningssessies verbranden tokens, maar ze verbranden goedkope tokens - Codex beoordeling van een afwaarderingsplan is een paar duizend inputtokens en een paar duizend outputtokens. Implementatie is daarentegen de dure fase. Elke bug die u bij de planning tegenkomt, is een bug waarvoor u niet hoeft te betalen om code te schrijven, te debuggen en te repareren. Mijn ruwe interne benchmark voor een typische feature-build: 60 tot 90 minuten vijandige planning bespaart iets in de orde van 3 tot 5 uur implementatie-iteratie. De tokenwiskunde volgt dezelfde vorm.
De brug naar het volgende patroon is dit: planningslussen zijn geweldig voor greenfield-werk, maar de meeste dagen ben je geen greenfield-werk. Je zit in een bestaande codebase die al zijn eigen meningen heeft, en je hebt een andere vorm van hulp nodig.
Workflow 2: Incrementeel bouwen met Codex-achtergrondaudits
Dit is het patroon dat ik gebruik op bestaande klantcodebases: Laravel-apps, SaaS-dashboards van bureaus, de inhoudsstapel op [Ramlit] (https://www.ramlit.com), alles.
De structuur: Claude Code doet het actieve gebouw op de voorgrond. Ik ben in stroom. Codex voert /codex:rescue-audits uit op de achtergrond op welk subsysteem ik momenteel aanraak.
Achtergrondmodus is hier de ontgrendeling. Wanneer u /codex:rescue activeert met een niet-triviaal bereik, start de plug-in de run als achtergrondtaak en geeft de controle onmiddellijk terug aan Claude Code. Je blijft bouwen. Enkele minuten later – meestal ergens tussen drie en twaalf uur, afhankelijk van de omvang – is de audit voltooid. U controleert /codex:status om te zien wat er is gedaan en vervolgens /codex:result om de bevindingen te lezen.
Het cruciale gedrag: dit onderbreekt je flow niet. De grootste productiviteitsmoordenaar bij agentische codering is niet de slechte modeluitvoer, maar de context-switch-belasting. Elke keer dat u stopt met bouwen om te beoordelen, betaalt u een overstapkosten op de heenweg en nog een op de terugweg. Achtergrond Codex-audits elimineren dit volledig. Je bent nog steeds aan het bouwen wanneer de beoordeling plaatsvindt.
De vorm van de audits die ik het vaakst uitvoer: beveiligingsbeoordeling van elke module die de auth- of invoerparsing afhandelt, schaalbaarheidsbeoordeling van elke controller die in aanraking komt met een tabel die veel schrijft, en code-hygiënebeoordeling van alles wat ik verwacht aan een andere ontwikkelaar over te dragen. Elk daarvan is een geparametriseerd reddingsverzoek: u vertelt Codex waar u wilt dat het naar zoekt, richt het op de relevante map en laat het malen.
Een praktische opmerking over de contextgrootte. De plug-in stuurt de relevante werkset naar Codex, maar voor volledige codebase-audits moet je er soms scope-hints aan doorgeven: welke mappen er toe doen, welke je moet negeren, welke pakketten worden verkocht. Codex op het 1M-contextvenster van GPT 5.5 slokt middelgrote codebases in hun geheel op, maar op grotere monorepos wil je nog steeds een bereik hebben. Ik wijs het meestal naar de map waarin ik actief werk, plus de direct aangrenzende afhankelijkheden (de modellen die een controller aanraakt, de migraties die een model aanraakt), en sla al het andere over.
Als je liever een team hebt dat deze volledige dual-agent-installatie uitvoert als een service voor je codebase, dan is dit precies het soort betrokkenheid dat Ramlit op zich neemt voor klanten die productie-Laravel en Node-stacks draaien - dezelfde patronen, verschillende schaal.
Het volgende patroon is het patroon dat dit van een mooie workflow verandert in een echte poort van productiekwaliteit.
Workflow 3: Eindaudit vóór release
Er is een reden waarom senior engineers schonere code leveren dan junioren, en het is niet zo dat ze bij de eerste keer minder bugs schrijven. Het is dat ze een laatste-pass-gewoonte hebben ingebakken: het moment waarop ze stoppen, terug scrollen naar de bovenkant van het diff en het lezen alsof ze het nooit hebben geschreven. De meeste AI-coderingsworkflows slaan die stap volledig over omdat het model gewoon doorgaat.
Het pre-release-auditpatroon herstelt dit.
De monteur: vuur de dag vóór de implementatie, of op het moment dat een feature branch functioneel voltooid is, /codex:rescue af op het hele diff met een focus op veiligheid en hygiëne. Ik formuleer het verzoek als "bekijk deze vestiging alsof u de oproepbare ingenieur bent die zal worden opgeroepen als iets in deze PR de productie verbreekt." Dezelfde vijandige framing als de planningslus, toegepast op voltooide code.
De bevindingen die ik uit deze laatste passage krijg, vallen meestal in vier emmers. Ten eerste: beveiligingslekken die Claude niet zouden signaleren omdat Claude ze schreef en er een goed gevoel over had. Hiaten in de vervalsing van verzoeken tussen locaties, ontbrekende autorisatiecontroles op routes die eruit zien als gelezen eindpunten maar in werkelijkheid de status muteren, loginstructies die stilletjes door de gebruiker aangeleverde invoer afdrukken. Ten tweede: privacylekken in foutmeldingen. Stacktraces retourneren databasekolomnamen. Validatieberichten die bevestigen of er een e-mail in het systeem bestaat. Ten derde: prestatie-voetgeweren. N+1 queries binnen een Blade-lus, een JSON-kolom die wordt gedeserialiseerd binnen een strakke binnenlus, een Eloquent-relatie die is ingesteld op lazy-load wanneer deze gretig zou moeten zijn. Ten vierde – hygiëne. Dode code, opmerkingen die de implementatie tegenspreken, functienamen die liegen over wat de functie doet.
Geen van deze zijn op zichzelf catastrofaal. Het zijn allemaal dingen waarvan je over een jaar, als je je eigen codebase probeert te lezen, ervoor zorgt dat je de laptop in brand wilt steken.
Er is een configuratiekeuze die hier van belang is. U kunt de pre-release-audit uitvoeren als een eenmalige redding, of u kunt de beoordelingspoort inschakelen met /codex:setup --enable-review-gate en Codex elke Claude-reactie op de branch laten stoppen. De Stop-hook-aanpak is agressiever: Codex beoordeelt elke Claude-beurt, blokkeert de stop als er problemen worden gevonden en dwingt Claude deze op te lossen voordat je verder kunt gaan. Dat is het /codex-auto-review doorlopende luspatroon in de geest. Het is ook de duurste modus in de plug-in. Ik schakel het alleen in gedurende de laatste 24 uur voordat een productie wordt geïmplementeerd op gevoelige codepaden, en ik schakel het uit zodra de implementatie landt. De kosten om het fulltime aan te laten staan, zouden mijn planlimieten binnen een week laten smelten.
Dit is ook het patroon dat goed aansluit bij de stapel vaardigheden van agenten die ik rond Claude Code heb gebouwd – audits vóór de release, beoordelingspoorten en op vaardigheden gebaseerde hooks bevinden zich allemaal op dezelfde architecturale laag.
Workflow 4: Gedelegeerde uitvoering wanneer Claude tegen een muur aanloopt
Meestal is het duo Claude-builds, Codex-reviews. Maar er zijn domeinen waar Claude worstelt op manieren die de strijd niet waard zijn. Wanneer dat gebeurt, draai je de polariteit om: Claude wordt de planner en Codex wordt de uitvoerder.
Het meest voorkomende geval voor mij is alles wat Python-zwaar is en dat een zorgvuldige typebehandeling vereist: asynchrone generatoren, complexe dataklasse-hiërarchieën, alles waarbij de eigenaardigheden van het typesysteem er toe doen. Claude Code op Opus 4.7 is hier volledig capabel, maar ik heb gemerkt dat bij taken waarbij de foutmodus bestaat uit subtiele type-mismatches die compileren maar tijdens runtime kapot gaan, Codex op GPT 5.5 strakkere first-pass-code produceert. Misschien is het de tokenizer-efficiëntie. Misschien is het precies waar het trainingscorpus van GPT 5.5 leeft. Ik heb geen duidelijke uitleg, alleen het patroon.
Het delegatiemechanisme is /codex:rescue met een expliciete 'implementeren, niet alleen beoordelen'-framing. Met de plug-in kunt u werk delegeren en als achtergrondtaak uitvoeren: u activeert het verzoek, u blijft in Claude Code aan een andere module werken en u komt terug wanneer Codex de implementatie retourneert. De overdracht terug naar de hoofdsessie van Claude Code gebeurt via /codex:result, die de diff in uw werkcontext dumpt, waar Claude het kan oppikken, bekijken en integreren.
Er is een discipline die er hier toe doet. Delegeer geen werk aan Codex dat u niet zelf kunt beoordelen. Het hele punt van dual-agent-codering is dat jij de jury bent: als beide modellen het eens zijn, verzend jij; als ze het er niet mee eens zijn, beslis jij. Als u iets zo ver buiten uw expertise delegeert dat u niet meer kunt zeggen of het resultaat correct is, keert u terug naar het vertrouwen op één model, alleen vertrouwt u nu het model waarnaar u delegeert, zonder dat u iets heeft om mee te vergelijken. Dat is nog erger dan helemaal niet delegeren.
De gevallen waarin delegatie goed werkt, zijn domeinen waarin u het probleem goed genoeg begrijpt om een verkeerd antwoord te ontdekken, maar waar u uw ochtend niet wilt besteden aan het implementatie-gromwerk. Dat is een veel kleiner oppervlak dan "elke taak waar Claude middelmatig in is", en de discipline om binnen dat kleinere oppervlak te blijven is wat de workflow eerlijk houdt.
Workflow 5: de continue lus voor gevoelige builds
Dit is het patroon dat ik bereik voor misschien één build op de tien: de configuratie waarbij elk deel van de voorgaande vier workflows tegelijkertijd op dezelfde branch draait.
De opstelling ziet er als volgt uit. Planmodus in Claude Code, gecombineerd met vijandige Codex-beoordeling van het plan. Zodra het plan zich stabiliseert, begint de uitvoering. Achtergrond /codex:rescue-audits worden continu uitgevoerd op de modules die worden gebouwd. De beoordelingspoort staat aan, dus Codex Stopt elke Claude-reactie. Aan het einde van elke werkdag wordt een laatste /codex:rescue uitgevoerd tegen het volledige diff. De volgende ochtend begint met het lezen van de nachtelijke auditresultaten en beslissen wat er moet worden gerepareerd voordat de nieuwbouw begint.
Dit is de configuratie met maximale paranoia. Het is langzaam. Het is duur. En met de juiste constructie is het de moeite waard.
De juiste soort build is alles waarbij het verzenden van een bug echte kosten met zich meebrengt die verder gaan dan 'Ik moet een hotfix pushen'. Betalingsstromen. Authenticatiesystemen. Alles wat met klantgegevens te maken heeft. Migraties die niet triviaal omkeerbaar zijn. Compliance-relevante codepaden.
Ik heb deze configuratie vorige maand uitgevoerd op een HIPAA-aangrenzende clientbuild - een CRM voor de gezondheidszorg waarbij het gedrag van het auditlogboek aantoonbaar correct moest zijn. De configuratie met continue lus heeft twee dingen opgespoord die anders in productie zouden zijn gekomen: een sessie-token-lek in foutreacties en een berekening van het retentievenster die een dag-van-week-grens afwijkend was. Beide zouden een regelgevende puinhoop zijn geweest. Beide kwamen voort uit Codex-beoordelingspassen die Claude op zichzelf niet zou hebben gemarkeerd, omdat Claude ze schreef en als voltooid beschouwde.
Buiten deze gevallen met hoge inzet is de continue lus overdreven. Alleen al het symbolische wetsvoorstel maakt het onhoudbaar voor routinewerk. Maar weten wanneer je het moet aanzetten – en gedisciplineerd zijn om het weer uit te zetten – is wat ‘ingenieurs die AI gebruiken’ onderscheidt van ‘ingenieurs die AI goed gebruiken’.
Een echte demo: de URL Shortener-build
Laat me het op een concreet project zetten, zodat de abstractie terechtkomt.
Ik heb een URL-verkorter gebouwd – het soort ‘klein SaaS-project’ dat eigenlijk vol randgevallen zit. Bitly-stijl. Aangepaste slugs, vervaldata, klikanalyses, snelheidsbeperkingen, de werken. Stack: Next.js 15 frontend, Postgres backend, geïmplementeerd op een VPS van $ 20 per maand.
Claude Code deed het eerste schavot. Drie uur, enkele Opus 4.7-sessie, schone output. App draaide bij de eerste implementatie. De autorisatie werkte. Het verkorten werkte. Het analysedashboard weergegeven. Met elke redelijke maatregel was de bouw voltooid.
Vervolgens heb ik /codex:rescue op de hele codebasis uitgevoerd, met als doel "de dingen te vinden die me pijn zullen doen als dit echt verkeer bereikt".
Wat terugkwam was ongemakkelijk. Codex heeft zes problemen gemarkeerd. De slug-generatie gebruikte Math.random() voor korte codes, wat prima is totdat je botsingen in de shortlink-tabel tegenkomt - op dat moment was de logica voor opnieuw proberen een strakke lus zonder uitstel. Bij de verwerking van de vervaldatum werd overal uitgegaan van UTC, maar het invoerformulier accepteerde de lokale tijd zonder conversie, wat betekende dat elke link die 'vandaag' afliep, als al verlopen kon worden beschouwd, afhankelijk van aan welke kant van middernacht de gebruiker woonde. De snelheidsbegrenzer was per IP, maar er was geen upstream proxy-headercontrole, dus een enkele Cloudflare IP zou de bucket voor iedereen erachter kunnen uitputten. En zo verder.
Vervolgens heb ik /codex:rescue opnieuw uitgevoerd, deze keer specifiek gericht op de functie voor het verlopen van links met vijandige framing - "daag dit ontwerp uit vanuit het perspectief van iemand die het probeert te verbreken." Codex kwam terug met randgevallen die ik niet eens mentaal had gemodelleerd: tijdzoneafwijkingen bij de vervalcontrole, links die precies om middernacht op de grensdag verlopen, de vraag wat 'verlopen' betekent wanneer de klik en de controle 30 seconden na elkaar plaatsvinden tijdens een zomertijdovergang.
Geen van deze zou alleen vanuit Claude schoon zijn verzonden. Geen van deze zou ook uit een enkele menselijke recensie naar voren zijn gekomen, omdat menselijke recensenten de neiging hebben zich te concentreren op de code die er is, en niet op de code die ontbreekt. De vijandige beoordelingsmodus van Codex is structureel goed in het vinden van de ontbrekende code: de validatie die er had moeten zijn, de zaak die afgehandeld had moeten worden, de aanname die ter discussie had moeten worden gesteld.
De verkorter ging in productie en alle zes de problemen waren verholpen. Kosten van de dual-agent run: een paar dollar aan Codex-tokens voor het Anthropic-plan waar ik al voor betaalde. Kosten als ik de originele Claude-build had verzonden en de bugs in de productie had opgelost: op zijn minst een weekend patchen, mogelijk een beveiligingsincident, vrijwel zeker een brand bij de klantenondersteuning.
Die wiskunde is het hele veld.
De prijzen en abonnementswiskunde
Dit is waar de dual-agent-configuratie feitelijk financieel zinvol is, omdat de voor de hand liggende zorg is dat het uitvoeren van twee betaalde AI-niveaus uw factuur verdubbelt. Dat is niet het geval – als je de plannen goed opstelt.
Mijn huidige configuratie: Claude Code met het Anthropic-abonnement van $ 100 per maand, met Opus 4.7 ingesteld als het standaardmodel. Dat is het werkpaard. Het grootste deel van de daadwerkelijke codegeneratie, planning en conversatie vindt hier plaats, en het hogere niveau is gerechtvaardigd omdat Opus-runs de dure zijn.
Codex maakt gebruik van het OpenAI-abonnement van $ 20 per maand. De plug-in gebruikt Codex selectief – voor beoordelingspassen, achtergrondaudits en incidentele gedelegeerde uitvoering. Het tokenverbruik aan de Codex-kant is aanzienlijk lager dan aan de Claude-kant, omdat Codex niet de zware generatie doet. Het geeft kritiek. Kritiek is goedkoper dan creatie. Het $20-abonnement verwerkt het volume comfortabel voor een workflow van één ontwikkelaar met een gezonde bouwfrequentie.
De gecombineerde maandelijkse uitgaven bedragen $ 120. Vergeleken met de $100 kostende Claude-installatie die ik eerder gebruikte, is dat een stijging van 20 procent in de toolingkosten. De uitvoerkwaliteit is zo sterk gestegen dat de wiskunde zich bij een enkele klantbetrokkenheid ruimschoots terugbetaalt: één productiefout die niet wordt verzonden, is meer dan een jaar van het verschil waard.
Er is een configuratie waar je voorzichtig mee moet zijn: de beoordelingspoort kan, als hij aan blijft staan, sneller door Codex-tokens kauwen dan het plan van $ 20 comfortabel kan absorberen. Als u review-gate-on als standaardmodus gebruikt, hebt u een hogere OpenAI-laag nodig. Ik laat de beoordelingspoort standaard uitgeschakeld en schakel deze alleen in gedurende de laatste 24 uur vóór een gevoelige implementatie. Dat houdt de planwiskunde eerlijk.
De tegengestelde implicatie: u moet Codex niet uitvoeren op een hoger plan dan Claude, tenzij uw workflow is omgekeerd (Codex doet de primaire generatie, Claude doet de beoordeling). Voor de meeste builds is Claude de zware generator en Codex de chirurgische reviewer, en de planniveaus moeten die asymmetrie weerspiegelen.
Wat dit betekent voor niet-ingenieurs
Als je contentstacks, agentworkflows of operationele automatisering bouwt in plaats van productiecode, is het dual-agent-patroon nog steeds van toepassing - en ik voer het uit op mijn eigen multi-brand contentpijplijn, wat het grootste deel van mejba.me en de merkfamilie doorloopt.
De vorm is hetzelfde. Claude stelt de agentprompt, de workflowdefinitie en de logica voor het genereren van inhoud op. Codex beoordeelt de vraag naar dubbelzinnigheid, de workflow voor foutmodi, de inhoudslogica voor randgevallen. Wanneer ik een nieuwe contentagent bouw, vraag ik Claude meestal om de systeemprompt te schrijven, en vraag ik Codex vervolgens om elke manier te vinden waarop die prompt verkeerd kan worden gelezen. Het aantal latente bugs dat naar boven komt, is consistent hoger dan ik verwacht.
Er is een gerelateerd patroon in de manier waarop ik de steigers van het agentteam leid: planningsvaardigheden in Claude Code, vaardigheden van uitvoerder gedelegeerd aan Codex wanneer de taak chirurgische precisie vereist. Ik heb de fundamentele vaardighedenlaag behandeld in mijn stuk over de beste Claude Code-vaardigheden voor zakelijke efficiëntie, en de dual-agent-uitbreiding van die stapel is waar de workflow nu leeft.
Het principe dat geldt voor zowel engineering als operationeel werk: vraag niet één model om de bouwer en de criticus te zijn. De functiebeschrijvingen zijn verschillend. De cognitieve frames zijn verschillend. De uitvoer die u krijgt van een model in de 'bouwmodus' verschilt structureel van de uitvoer die u krijgt van hetzelfde model in de 'beoordelingsmodus'. Het verdelen van de rol over twee specialisten met twee verschillende persoonlijkheden levert strikt betere resultaten op dan één specialist vragen om beide hoeden te dragen.
De grenzen die de moeite waard zijn om te weten
Een dergelijke goede workflow heeft een eerlijke disclaimer nodig.
Ten eerste is de plug-in nog jong. Het is onlangs verzonden en het slash-commandooppervlak zal evolueren. De exacte opdrachtnamen en vlaggen die ik vandaag gebruik, zullen waarschijnlijk in de komende paar maanden worden aangepast. Behandel de officiële Codex plugin repository als uw bron van waarheid voor de huidige syntaxis - wat ik hier heb beschreven is het patroon, niet noodzakelijkerwijs de exacte bezwering voor altijd.
Ten tweede zullen de twee modellen het soms oneens zijn op manieren die niet productief zijn. Je krijgt gevallen waarin Codex een probleem signaleert waar Claude op de juiste manier omheen is gebouwd, of waarin Claude iets implementeert dat Codex anders zou hebben gebouwd, maar geen van beide versies is verkeerd. De workflow gaat ervan uit dat jij, de mens, de jury bent. Als je bij een bepaald meningsverschil niet kunt zeggen welk van de twee modellen gelijk heeft, ontaardt het dual-agent-patroon in 'twee AI's die ruzie maken terwijl je kijkt'. Kies de meningsverschillen die je daadwerkelijk kunt oplossen.
Ten derde bestaat er een reëel risico op beslissingsmoeheid. Het uitvoeren van vijandige recensies over alles maakt van elk onderdeel een debat. Het patroon werkt omdat de beoordelingen een bepaalde reikwijdte hebben: vijandige planning aan het begin, audits aan het eind, normale beoordelingen op verzoek in het midden. Als je review-gate-aan als je standaardmodus inschakelt en deze nooit uitschakelt, begint de wrijving te vergroten en keert de productiviteitswinst om. Discipline over wanneer elk patroon wordt geactiveerd, is het verschil tussen "dit is de workflow" en "dit is de reden dat ik ben gestopt met het gebruik van AI."
Ten vierde kunnen de kosten oplopen. De planwiskunde die ik heb beschreven, is wat ik waarneem tijdens mijn werklast: één ingenieur, meerdere merken, enkele tientallen builds per maand. Als u het in een team uitvoert, of als u voortdurend aan het bouwen bent, moet u het tokenverbruik rechtstreeks volgen in plaats van erop te vertrouwen dat de planniveaus het zullen absorberen. De /codex:status en /codex:result van de plug-in zijn zowel observatietools als workflowtools. Gebruik ze om de rekening zichtbaar te houden.
Ten vijfde is dit geen vervanging voor codebeoordeling door een mens die uw domein daadwerkelijk begrijpt. Beide modellen zijn patroonmatchers die werken op basis van trainingsgegevens. Ze vangen het soort insecten dat ze eerder hebben gezien. Een nieuwe architectonische fout – iets dat verkeerd is op een manier die niemand heeft gedocumenteerd – zal aan beide voorbijgaan. Het dual-agent-patroon verhoogt uw vloer; het verhoogt je plafond niet. Menselijke beoordeling door senioren is nog steeds van belang, vooral als het gaat om de oproepen die nog niet in het trainingscorpus voorkomen.
Het enige dat je deze week kunt proberen
Als je één concreet experiment wilt dat je zal vertellen of deze workflow bij jouw bouwstijl past: installeer de plug-in vanavond en morgenochtend voer je /codex:review uit op wat je aan het eind van de dag verzendt.
Dat is het. Herstructureer uw workflow niet. Schakel de beoordelingspoort niet in. Voer geen vijandige planningslussen uit. Neem gewoon wat Claude Code u helpt morgen op te bouwen, en vraag Codex vlak voordat u zich vastlegt wat het ziet.
Als de recensie niets oplevert (Codex is het ermee eens dat de code schoon is, geen aantekeningen), heb je tien cent uitgegeven en bevestigd dat Claude het goed heeft gedaan. Dat is op zichzelf al iets waard. Vertrouwen is een resultaat.
Als de recensie drie dingen bevat die je niet hebt gezien (en bij de meeste builds zal dat wel het geval zijn), heb je zojuist geleerd wat voor soort bugs je huidige workflow bevat, en je hebt het geleerd voor de kosten van één Codex-run. Beide uitkomsten zijn informatie die je niet had kunnen krijgen zonder het tweede model in de lus.
Vanaf daar wordt de workflow rijker. De planningslussen, de achtergrondaudits, de pre-release-poorten, de continue lussen op gevoelige code - ze komen allemaal voort uit dezelfde startzet. Twee modellen, één terminal, bouwer en scepticus in dezelfde workflow.
Het modeldebat was het verkeerde debat. De echte vraag was altijd: wat is het juiste team? Het blijkt dat het team bestaat uit twee specialisten die het niet productief met elkaar eens zijn, en jij bent de ingenieur die beslist wie gelijk heeft. Dat is een betere baan dan de ingenieur zijn die één model uitkiest en dit op Twitter verdedigt.
Zaterdagochtend, zes weken geleden, was ik bijna de engineer die de plugin niet had geïnstalleerd. Ik ben blij dat ik dat niet ben.
Veelgestelde vragen
Wat is de Codex plugin voor Claude Code?
De Codex plugin is de officiële integratie van OpenAI waarmee u Codex slash-opdrachten binnen Claude Code kunt uitvoeren zonder de sessie te verlaten. Het stelt Codex bloot als code-reviewer, codebase-auditor en gedelegeerde uitvoerder, met opdrachten als /codex:review, /codex:rescue, /codex:status, /codex:result en /codex:cancel. Zie de vijf bovenstaande workflows voor de volledige workflowpatronen.
Heb ik aparte abonnementen nodig voor Claude Code en Codex?
Ja: Claude Code gebruikt uw Anthropic-abonnement en Codex gebruikt uw OpenAI-abonnement. Het duo is kosteneffectief omdat Codex het goedkopere hulpmiddel is in een bouwer/recensent-splitsing. Mijn huidige configuratie draait op het $100 Anthropic plan met Opus 4.7 als primair en het $20 OpenAI plan voor Codex reviewwerk, wat in totaal $120 per maand oplevert voor één ontwikkelaar.
Wanneer moet ik de Codex beoordelingspoort inschakelen?
Schakel de beoordelingspoort via /codex:setup --enable-review-gate alleen in gedurende de laatste 24 uur voordat een productie wordt geïmplementeerd op gevoelige codepaden – betalingen, authenticatie, alles wat met compliance te maken heeft. Als u dit ingeschakeld laat terwijl uw standaardmodus de Codex-tokens sneller verbrandt dan het standaardplan absorbeert, wordt de iteratie aanzienlijk vertraagd. Schakel het uit zodra de inzet landt.
Werkt de plug-in voor niet-coderende workflows zoals inhoud of agent stack's?
Ja: het dual-agent-patroon vertaalt zich rechtstreeks naar contentpijplijnen en agentworkflows. Claude stelt prompts, systeemberichten en workflowdefinities op; Codex controleert ze op dubbelzinnigheid, foutmodi en randgevallen. Ik voer dit uit op mijn contentstapel met meerdere merken en het brengt latente bugs aan het licht die de configuratie met één model nooit heeft opgemerkt.
Zullen de namen van de slash-opdrachten veranderen als de plug-in wordt bijgewerkt?
Waarschijnlijk wel – de plug-in is nieuw en de syntaxis van opdrachten zal in de komende paar releasecycli evolueren. Behandel de [officiële Codex plugin GitHub-opslagplaats] (https://github.com/openai/codex-plugin-cc) als uw bron van waarheid voor huidige opdrachten. De hier beschreven werkstroompatronen blijven stabiel, zelfs als de namen van individuele opdrachten veranderen.
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
