De auteur reflecteert op een week waarin Codex intensiever werd gebruikt dan Claude. De belangrijkste observaties zijn:
Output en Stijl: Codex voelt technischer aan (vergeleken met Data uit Star Trek), terwijl Claude meer communiceert als een collega.
Codeergedrag: Codex produceert simpelere architecturen en minder commentaar in Ruby, terwijl Claude complexere oplossingen biedt die vaak meer randgevallen afhandelen.
Workflow: De auteur geeft de voorkeur aan gefocuste sessies met Codex en de CLI-aanpak van MCP's boven de automatisering van Claude.
Gebruiksvriendelijkheid: Claude is intuïtiever in het begrijpen van intenties en het werken met externe tools zoals Jira, terwijl Codex strikter de instructies volgt maar soms moeite heeft met complexe Git-operaties.
Conclusie: Het fundamentele verschil is dat Claude proactief probeert te raden wat de gebruiker wil, terwijl Codex fungeert als een assistent die exact doet wat er gevraagd wordt zonder te overdrijven.
Eerste indrukken: Een week lang vaker Codex dan Claude gebruikt
Terwijl ik dit jaar heb geprobeerd om Claude en Codex gelijk te houden, met dezelfde set plugins/skills en dergelijke, had Claude meer skills. Ik had namelijk skills gemaakt uit sommige sessies en niet alle zijn overgezet naar Codex. De oplossing hiervoor is simpel: wijs Codex naar de skills-map van Claude en vraag het om deze te transformeren.
Wanneer ik haast had (zoals bij het debuggen van iets dat urgent voelde), opende ik nog steeds Claude, omdat ik me daar op een bepaalde manier meer thuis voelde. Ik zeg niet dat het beter was, maar het was vertrouwd, en bij het debuggen is het gebruik van tools die je kent belangrijk.
Wijzigingen gemaakt door Codex bevatten minder commentaren in Ruby/Ruby on Rails-code. Dat beviel me erg goed, en ik zal binnenkort enkele experimenten delen die ik hierover heb uitgevoerd.
De output van de Codex agent harness is veel "technischer" dan die van Claude. Claude voelt meer als een collega in een Tuple-sessie die tegen je schrijft, terwijl Codex meer aanvoelt als een versie van Data uit Star Trek.
Ik wil veel meer sessies van Codex openen en deze gefocust houden, in plaats van één grote sessie van Claude zoals ik dat voorheen deed. Dit is misschien niet specifiek voor Codex, maar ik merkte het op tijdens het werken met Codex.
Het lijkt me dat Codex wijzigingen sneller doorvoert dan Claude. Maar nadat de belangrijkste wijzigingen waren gedaan, kostte het veel tijd om de pull request af te ronden: veel tests opnieuw draaien, review, enzovoort. Ik hou van de grondigheid hiervan, maar uiteindelijk was er geen tijdwinst.
Het leek me dat Codex een veel simpelere oplossing creëerde in termen van code-architectuur dan Claude. Claude neigt ernaar om veel dingen te maken: abstracties, concepten, Sorbet-signatures, type-aliases, enzovoort. Codex was wat beperkter en creëerde minder. Deze week testte ik ook een verbeterde flow van code research → design change → review change → implement → verify. Ik liet beiden dezelfde vereisten implementeren met behulp van dezelfde documenten; de code van Claude was iets complexer, maar handelde meer gevallen af.
Codex maakte ook fouten. Claude kon mijn intentie begrijpen om af te wijken van ander werk en deze synchroon te houden. Codex deed vervelende dingen, zoals branch A die target branch B, die weer target main. Toen ik vroeg om te rebasen, rebasete het met main, wat resulteerde in een PR met meer dan 4000 toevoegingen. Ik moest expliciet zijn en vragen om alleen met het target te rebasen.
Voor Codex was het werken met Jira en Atlassian een worsteling in mijn omgeving, waar ik de CLI-tool gebruik en niet de MCP. Het opende JIRA om me te vragen in te loggen, schakelde toen over naar de CLI, en daarna weer terug naar de browser. In dit geval was Claude veel enthousiaster om te krijgen wat ik wilde en dit te doen op de manier waarop ik het wilde, gebaseerd op eerdere sessies.
Wat betreft MCP's vind ik de CLI-aanpak van Codex prettiger, waarbij het me vraagt om codex mcp login uit te voeren en elke keer de juiste authenticatie- en autorisatieflow opent. Claude probeert dit soms automatisch in een beurt te doen, waardoor het vast kan lopen.
Conclusie
Ik denk dat het belangrijkste verschil dat ik voel tussen Claude en Codex is dat Claude probeert om verder te gaan dan waar om gevraagd wordt en te raden wat je misschien wilt en dit vervolgens direct doet, terwijl Codex meer als een metgezel is die doet wat je zegt, maar het niet overdrijft. Het stopt bij het eerste teken dat het klaar zou kunnen zijn.
Enkele korte en zeer persoonlijke indrukken van het vaker gebruiken van Codex dan Claude deze week (ik hoop in het weekend een volledige analyse te maken).
Eerste indrukken: Een week lang vaker Codex dan Claude gebruikt
Terwijl ik dit jaar heb geprobeerd om Claude en Codex gelijk te houden, met dezelfde set plugins/skills en dergelijke, had Claude meer skills. Ik had namelijk skills gemaakt uit sommige sessies en niet alle zijn overgezet naar Codex. De oplossing hiervoor is simpel: wijs Codex naar de skills-map van Claude en vraag het om deze te transformeren.
Wanneer ik haast had (zoals bij het debuggen van iets dat urgent voelde), opende ik nog steeds Claude, omdat ik me daar op een bepaalde manier meer thuis voelde. Ik zeg niet dat het beter was, maar het was vertrouwd, en bij het debuggen is het gebruik van tools die je kent belangrijk.
Wijzigingen gemaakt door Codex bevatten minder commentaren in Ruby/Ruby on Rails-code. Dat beviel me erg goed, en ik zal binnenkort enkele experimenten delen die ik hierover heb uitgevoerd.
De output van de Codex agent harness is veel "technischer" dan die van Claude. Claude voelt meer als een collega in een Tuple-sessie die tegen je schrijft, terwijl Codex meer aanvoelt als een versie van Data uit Star Trek.
Ik wil veel meer sessies van Codex openen en deze gefocust houden, in plaats van één grote sessie van Claude zoals ik dat voorheen deed. Dit is misschien niet specifiek voor Codex, maar ik merkte het op tijdens het werken met Codex.
Het lijkt me dat Codex wijzigingen sneller doorvoert dan Claude. Maar nadat de belangrijkste wijzigingen waren gedaan, kostte het veel tijd om de pull request af te ronden: veel tests opnieuw draaien, review, enzovoort. Ik hou van de grondigheid hiervan, maar uiteindelijk was er geen tijdwinst.
Het leek me dat Codex een veel simpelere oplossing creëerde in termen van code-architectuur dan Claude. Claude neigt ernaar om veel dingen te maken: abstracties, concepten, Sorbet-signatures, type-aliases, enzovoort. Codex was wat beperkter en creëerde minder. Deze week testte ik ook een verbeterde flow van code research → design change → review change → implement → verify. Ik liet beiden dezelfde vereisten implementeren met behulp van dezelfde documenten; de code van Claude was iets complexer, maar handelde meer gevallen af.
Codex maakte ook fouten. Claude kon mijn intentie begrijpen om af te wijken van ander werk en deze synchroon te houden. Codex deed vervelende dingen, zoals branch A die target branch B, die weer target main. Toen ik vroeg om te rebasen, rebasete het met main, wat resulteerde in een PR met meer dan 4000 toevoegingen. Ik moest expliciet zijn en vragen om alleen met het target te rebasen.
Voor Codex was het werken met Jira en Atlassian een worsteling in mijn omgeving, waar ik de CLI-tool gebruik en niet de MCP. Het opende JIRA om me te vragen in te loggen, schakelde toen over naar de CLI, en daarna weer terug naar de browser. In dit geval was Claude veel enthousiaster om te krijgen wat ik wilde en dit te doen op de manier waarop ik het wilde, gebaseerd op eerdere sessies.
Wat betreft MCP's vind ik de CLI-aanpak van Codex prettiger, waarbij het me vraagt om codex mcp login uit te voeren en elke keer de juiste authenticatie- en autorisatieflow opent. Claude probeert dit soms automatisch in een beurt te doen, waardoor het vast kan lopen.
Conclusie
Ik denk dat het belangrijkste verschil dat ik voel tussen Claude en Codex is dat Claude probeert om verder te gaan dan waar om gevraagd wordt en te raden wat je misschien wilt en dit vervolgens direct doet, terwijl Codex meer als een metgezel is die doet wat je zegt, maar het niet overdrijft. Het stopt bij het eerste teken dat het klaar zou kunnen zijn.
Zichtbare categorieën
Kies welke categorieën je wilt zien.
Over deze site
Waarom Tech-update?
Tech-update is ontstaan omdat ik merkte dat ik dagelijks veel verschillende websites moest bezoeken om interessant technieuws te vinden. Dat kon efficiënter.
Hoe werkt het?
Meerdere keren per etmaal gaat mijn zelfgebouwde AI-agent op zoek naar interessante artikelen op blogs en nieuwssites.
Vindt hij iets relevants, dan wordt het artikel naar het Nederlands vertaald en op Tech-Update geplaatst.
Van ieder artikel maakt de AI ook een korte samenvatting. Zo kun je snel bepalen of het de moeite waard is om het volledige artikel te lezen.
Bij ieder artikel staat altijd een link naar de oorspronkelijke bron (vaak een Engelstalige website).
Artikelen kun je bewaren als favoriet, vastzetten in de zijbalk of terugvinden via de zoekfunctie.
In de instellingen (tandwielikoon rechtsboven) geef je aan in welk soort nieuws je geïnteresseert bent.