How I AI: GPT-5.3 Codex vs. Claude Opus 4.6—Shipping 44 PRs in 5 Days
I put OpenAI's GPT-5.3 Codex and Anthropic's Claude Opus 4.6 head-to-head, using them to redesign my marketing site and refactor a complex component. Discover the powerful, real-world workflow I used to ship 93,000 lines of code in just five days.
Claire Vo
Full episode
Watch or listen
Workflows from this episode
- How to Combine Claude Opus and GPT-5.3 Codex for High-Velocity Code Refactoring
- How to Redesign a Marketing Website Using Claude Opus 4.6 for Creative Development
Episode outline
I didn't test these on a toy landing page. I dropped them into an established codebase: my ChatPRD marketing site and then our core application. I wanted to see how they handled both creative, greenfield work and messy, detail-heavy refactors. Very quickly, it became obvious that each model belonged in a different part of my AI engineering stack.
Across five days, I merged 44 pull requests containing 98 commits. Those changes added almost 93,000 lines and removed 87,000, for about 5,000 net new lines across the core application and related work.
Here are the two workflows that mattered most and the multi-model setup I'm actually using now.
Give both models the same redesign brief
The creative website redesign workflow isolates the Opus side of my test: a broad visual brief, a working codebase, and enough freedom to propose a distinct direction.
I started with a deliberately ambitious task: redesigning the ChatPRD marketing site. The current site works well for product-led growth, but as we move further upmarket, I wanted something that felt more polished and enterprise-ready. It was a good test of how OpenAI's GPT-5.3 Codex and Anthropic's Claude Opus 4.6 handle broad, design-heavy work inside a real codebase.
GPT-5.3 Codex: restrained and systems-minded
I started in OpenAI's new Codex desktop app, and the app itself impressed me immediately. It puts core Git concepts front and center with clear visualizations of repositories, branches, work trees, and diffs. That's useful both for experienced engineers juggling agentic workflows and newer developers still learning how these systems work. I also really like how 'Skills' and 'Automations' are treated as first-class features instead of buried zip files and setup docs.

I started with a very high-level prompt and intentionally gave the model a lot of creative freedom:
Optimize the marketing site and this repo for PLG plus enterprise. You can create new pages, redesign templates, et cetera, to make it the highest quality marketing site I could have.

Unfortunately, this is where I hit my first wall. I found that the GPT-5.x Codex models are so literal. They follow instructions incredibly well, but they do it blindly, without nuance or creative interpretation. For a task like this, that literalness became a huge bottleneck. It would explicitly write copy that said things like, "If you're here for product-led growth, click here... If you are here as an enterprise customer, click here." It lacked the subtlety needed for a high-quality marketing site.
What followed was a frustrating loop where every round of feedback caused the model to overfit to my latest instruction. Ask for more integration content and suddenly the whole homepage revolved around integrations. The funniest example came after I asked for a more content-dense site, similar to Hex. A few prompts later, Codex produced this headline:
"A dense product workflow for AI powered teams."

I had to laugh. I wanted a content-dense site, not a product with a dense workflow! In the end, after a lot of back and forth, the result was... okay. It redesigned the homepage and an enterprise page but didn't touch the rest of the site as requested. The code was solid, but the design and copy just weren't there.
Claude Opus 4.6: fast and visually assertive
I took the exact same task over to Cursor with Opus 4.6. The harness matters here. I still think Cursor's does a particularly good job surfacing planning, to-dos, and long-running task management in a way that helps these models perform better.
I gave Opus the same high-level prompt. It explored the repository, made a plan, and began building components independently. The first result had stronger copy but generic default styling, so I gave it direct visual feedback.
I want it to look like I spent a million dollars on my design with the best agencies out here... I want you to develop a unique and modern frontend visual style. This is Tailwind Indigo AI slop.

And somehow, that did the trick. Opus took the criticism well and came back with a redesign that actually felt thoughtful. It kept our existing brand aesthetic but elevated it, using our real colors and graphics instead of placeholders and creating much stronger enterprise-focused sections. The result looked polished, distinct, and aligned with what I had in my head. More importantly, once I approved the direction, it consistently applied those styles across the rest of the site, including the pricing page and other sections. This is almost certainly the version we'll ship.

For this broad website redesign, I preferred Opus 4.6. It planned more independently, responded better to creative feedback, and carried the approved direction across more of the site.
Use Opus to build and Codex to review
The Opus-and-Codex refactoring workflow captures the pairing I settled on after the comparison: one model creates momentum, the other interrogates the implementation before shipping.
The redesign test was useful, but most of my actual work happens deep in the backend. This is where the combination of both models really clicked for me. I was refactoring a messy set of components for our MCP connectors for tools like GitHub, Linear, and others. The implementation had become inconsistent and difficult to maintain, and I needed a reusable system that was still flexible enough to customize.
The dynamic ended up feeling a lot like pairing an eager product engineer with a very opinionated principal engineer.
Let Opus establish the first draft
I started in Cursor with Opus 4.6 and asked it to refactor our tool components. Just like with the website work, Opus planned well and executed quickly. It created a flexible component structure, built out the front-end pieces, and got the system about 80 to 90 percent of the way there. The result looked good, worked well, and was dramatically cleaner than what we had before. Opus is the engineer who happily ships features all day long.
Ask Codex to review architecture and performance
Once Opus had produced a solid first draft, I moved the code into the Codex app and changed the assignment completely. Instead of asking it to build, I asked it to act like a principal engineer doing an aggressive production review. The review brief focused on architecture, performance, scalability, customization, and avoiding overfitting.
I've redesigned tool usage in this index. It's gone through several rounds of feedback. Can you review the architecture and performance and see if you have any feedback we should consider before shipping. We're looking for something scalable, but customizable and we don't wanna overfit in any direction.
This is where GPT-5.3 Codex really stood out. It tore through the codebase, surfaced high-impact issues and edge cases Opus had missed, prioritized them, and asked useful clarifying questions before making changes. Once I approved the fixes, it polished the implementation into something production-ready. The final code passed our AI-powered Bugbot review, which also runs on a Codex model, and we shipped it.

This has become my default workflow. GPT-5.3 Codex really does feel like a principal software engineer: sometimes stubborn about building net-new things, but incredibly good at finding weaknesses in existing code. Opus moves fast and gets features over the line. Codex hardens the work before production. Together, they cover each other's weaknesses unusually well.
Speed, cost, and task selection
Opus 4.6 Fast was much faster in my use and cost roughly six times as much as the standard model. I cited an approximate price of $150 per million output tokens and treated that figure as an estimate.
The ROI is hard to ignore. Shipping 44 PRs and features of this scope would normally take months of engineering time and cost far more than the model bill. Even the expensive models are cheap relative to the output they unlock. That said, as my friend from Cody at Sentry warned me, "don't pick the wrong task" for the fast model, or you may end up with a bill you regret.
How I divide the work
The tests did not produce one universal winner. I found the models useful at different stages of the same engineering workflow.
- I use Claude Opus 4.6 for broad implementation, UI work, and early product exploration.
- I use GPT-5.3 Codex for code review, architecture analysis, edge cases, and production hardening.
My current handoff is simple: let Opus build the first strong version, then ask Codex to challenge the architecture and implementation before shipping.
The comparison is useful because it avoids declaring one permanent winner. Model behavior changes, and the right choice depends on whether the current bottleneck is visual exploration, implementation speed, architectural judgment, or review.
Watch or listen
Sponsors
Thanks for supporting How I AI
Make your app enterprise-ready today
Build your next product with ChatPRD
Turn an idea into a PRD, user stories, and a plan.


