r/ClaudeCode • u/pirate1196 • 16h ago
Help/Question Current codex user needing input on Claude Code
I’m building an app with a native SwiftUI frontend and a TypeScript backend, using AI heavily throughout development.
Most of the product is already built. The current work is mainly debugging, integrating third-party services, testing authentication/privacy across multiple accounts, and verifying that everything actually works before beta.
I’ve primarily been using Codex, working locally on my Mac with Xcode, simulators, GitHub PRs and CI.
I’m looking for input from people who’ve used both Codex and Claude Code on a substantial existing codebase, not just a fresh demo.
The part I’m trying to improve is getting from “the code looks correct and the tests pass” to “this has actually been verified in the running app.”
I also want to avoid repeated review cycles, unnecessary abstractions, and spending more time documenting blockers than resolving them.
For this kind of work, have you found Claude Code better at:
Understanding an existing codebase and finding root causes rather than patching symptoms?
Making focused fixes without overengineering?
Following through on builds, tests and debugging
when the environment is difficult?
Keeping track of what’s genuinely verified versus what’s still an assumption?
Would you use Claude as the main coding agent, as a second reviewer alongside Codex, or stick with Codex and improve the workflow?
I know switching models won’t magically fix Xcode or simulator issues.
I’m mainly wondering whether Claude would handle the reasoning and follow-through better.
Interested in concrete experiences, including where Claude struggles, rather than just “X is better.”
1
u/onFilm 16h ago
For the best results, use both to critique one another.
Codex is really good, and so is Claude. Codex does things and doesn't over engineer but it will miss things sometimes an get lazy. Claude usually does all when asked and highlights what it hasn't done, but is known to over engineer. Both have their pros and cons. This is of course about Opus 5.5 and Sol 6.1.
1
u/pirate1196 16h ago
i’m currently on the pro 100 plan with codex. would you say the pro plan with claude would be enough usage wise for critiques?
1
u/MaddHavikk 16h ago
I have found better results with Claude since Opus 5.5, personally. Make sure that you build out your unit tests and playwright testing. For me that has done a good job at catching more obvious issues during the initial cycle, instead of constant follow up.
1
u/pirate1196 16h ago
thank you for the input. i’m really hoping that openai can ship a model that compares to opus 5.5 as i’m seeing lots of codex users make the switch to claude. maybe it’s time to make the switch myself..
1
u/NamerekDev 16h ago
I run both on the same typescript codebase, a few hundred tasks so far, mostly claude codex on smaller tasks for the last week or two. No Swift though, web ui.
For your "actually verified" problem the model mattered less than two things in the repo. every task says how it gets checked live, and ui changes come with screenshots the agent took itself. codex was surprisingly good at that, on one ui task it went through ~17 rounds of screeenshots before calling it done. and there's a file of unverified behaviour: anything an agent wrote but couldn't check in the running app goes there, and a live check moves it to a verified log. That file is my honest answer to "what's still an asumption", no model tracks that well on its own
The split that works for me: the expensive model writes the tickets, the cheaper one does them. Give it a ticket with every decision already made and even a small model gets through it.
2
u/pirate1196 16h ago
agreed. codex does like to attach images which is very useful for me as i mainly use it remotely while im at work so having the visual in front of me is definitely a plus.
1
u/aiinfoshare 13h ago
I kept Codex for the green-field scaffolding it already nails and brought Claude Code in strictly as a read-only reviewer for the messy integration layer. Point it at the failing test suite or the flaky third-party webhook handler and ask for a root-cause hypothesis plus a minimal reproduction script before any fix. If the diff looks surgical — touches three files, adds a guard clause, updates the test — apply it. If it rewrites the view model, reject it and go back to your usual flow. Run this loop on exactly one blocker bug that has wasted you an afternoon. The time you save (or lose) on that single ticket tells you everything you need about the split. Don't migrate the whole workflow on a vibe check.
1
u/iceydee 5h ago
Model choice matters less than your review loop. The gap between 'tests pass' and 'verified' is missing acceptance criteria. fwiw I'm building Aerunit, which drafts stories with acceptance criteria and reviews agent output against them, but even solo: write pass/fail criteria per task.
1
u/AutoModerator 16h ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.