Codex is technically better than Claude Code, but I stopped using it for one specific reason

Codex is technically better than Claude Code, but I stopped using it for one specific reason


In 2026, practically everyone is a builder. In fact, people whose coding knowledge once ended at printing Hello World have gone all-in on building apps and spend more time talking to their terminal than to actual people. The reason coding has become so accessible to the masses is because of how many good coding agents exist now. Anthropic and OpenAI are the two biggest names in the AI world currently, and that’s true when we talk about their AI coding agents as well.

Claude Code and Codex sit at the top of most people’s lists, and you’ll always find debates over which one deserves your money and is worth your subscription. Admittedly, I’ve been part of many of these debates, and I’m constantly trying to figure out which one I’d actually keep if I had to pick just one. Despite being a huge Claude Code fan, I’ve been using Codex more and more lately, and I’ve come around to the idea that it’s the stronger agent in many respects. However, there’s one reason that stops me from making the switch permanent, and it has absolutely nothing to do with speed, pricing, or context windows.

Every software has two sides

A half nobody ever sees

Codex is technically better than Claude Code, but I stopped using it for one specific reason

While you can use coding agents like Codex and Claude Code for countless non-coding tasks, the reason most people open them is still to build something. Even if you haven’t formally studied the fundamentals of coding and all you do within a terminal agent while coding is send prompts, you figure out fast that an app has two sides to it.

There’s the backend, which handles the logic, the database, the API calls, the library, and essentially all the boring stuff the user never sees. Then there’s the frontend, which is the part every user certainly does see, and it’s where the actual design lives. The layout, the spacing, the typography, the colors, the buttons people actually click on. The frontend and backend are both essential, obviously. An app that looks incredible and does absolutely nothing is a mockup, and an app that works perfectly and looks like a 2003 forum is one nobody sticks around in willingly.

However, they aren’t really judged the same way. For instance, when you open a new app, I’m certain you’ve never once thought about how clean its database schema is. You’ve likely also never thought of the logic it uses to fetch your data, or the library it was built with, or how many API calls it fired off to load the page you’re looking at. Well, you might have if you’re a developer by profession, but you get the idea.

For most people, the interface is the app. You notice whether the spacing looks deliberate or accidental, whether the buttons look like buttons, and whether the whole thing feels like someone actually cared. And you decide within about two seconds whether it’s worth your time. The backend earns you nothing if the frontend loses the room first. Codex is very good at one of these two things, and it still needs some serious work on the other.

Codex isn’t a great designer

Functional, correct, and completely joyless

focusguard application window showing writing lock feature with word goal input field on mac desktop

Codex is great at the backend, and in many cases, I’ve found it to be better than Claude Code. I’ve found Codex is much better at actually following your instructions instead of going haywire and doing whatever it deems is best. For the backend specifically, this matters a lot when you’re iterating and trying to improve certain parts since you typically know what you want to get done and just want the agent to do it for you the way you instruct it. Claude Code has a habit of deciding it knows better halfway through a task, whereas Codex just does the thing you asked. It’s also a lot more proactive in asking questions and planning, and I’ve found the code it ships is typically much more reliable. So, when Codex hands me backend code, I generally trust it.

Unfortunately, I can’t say the same about the frontend it produces, and I’m yet to have a good experience with it on the first try. Every single time, I end up going back and forth with it, and eventually give up on it and find an alternate way. Codex’s designs just…lack personality. The frontend it produces is almost always bland, depressing to look at, and it does the very opposite of what I mentioned an appealing frontend does. The UI it produces just blatantly looks vibe-coded and lacks any creativity.

Claude Code, on the other hand, is great at frontend. Before I even began properly vibe-coding, I was using Claude to spin up quick artifacts and mockups, and the results impressed me even back then. The results it produces look a lot more modern and aesthetically appealing, and while they always look minimalist, they still have something going on.

claude code on desktop pc, lamp in view

Minimalism done properly is a bunch of small deliberate decisions, not the absence of decisions, and that’s the distinction Codex has never managed to land. Codex’s designs always just look like the placeholder version of the thing. The one you’d throw together to prove the layout works before someone actually designs it!

While I initially thought it was just me with this perspective, a quick scroll on X and Reddit told me everything I needed to know. These communities are filled with people describing my exact experience, and almost nobody arguing the premise. There’s a thread on r/codex titled “Codex is great for backend, but terrible for frontend” where the OP notes that on complex CSS layouts, React/Vue component state, or UI details, Codex often spits out outdated code or just completely misses modern frontend best practices.

The most useful diagnosis I found frames it as a tradeoff rather than a defect. As one commenter on a Reddit post put it, Codex is programmed to follow very detailed instructions, but it can’t really understand and follow context the way Claude can. That maps exactly onto what I like about it. The thing that makes Codex trustworthy on the backend (it does what you said, nothing more) is the same thing that makes it useless on the frontend, where half the job is knowing what you didn’t say.

Workarounds are the only answer anyone has

Ask why it’s bad, get told how to avoid it

To be fair, this isn’t a problem with Codex. Instead, the underlying model is what’s letting it down. Codex, the CLI, is excellent, and I genuinely can’t think of a single bad thing to say about it. Until OpenAI’s models play catch up and get better at frontend, you can either accept that everything you build with Codex will look mediocre, or you can stitch together a workflow to compensate.

For instance, what I’ve found works best for me is to design the UI in Figma manually, feed it to ChatGPT’s image models to get a proper mockup out of it, and then hand that image to Codex with instructions to match it exactly. Codex is genuinely good at that part. Give it a picture and tell it to reproduce what’s in the picture, and it’ll do it faithfully, because that’s an instruction-following task, and instruction-following is the thing it’s best at. Another thing I’ve done is connect Codex to Open Design, which gives it an actual design layer to work against instead of leaving it to invent one.

You can also use Anthropic’s frontend-design skill, which several people have adapted for Codex with good results. You can also explore third-party tools like Impeccable and Stitch. So, you don’t need to entirely ditch Codex over this issue, but as someone who isn’t a fan of jumping from one tool to another and would rather have one thing that just works, none of these appeals to me much!



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *