Insights  /  Collaboration & Alignment

Collaboration & Alignment

Claude vs. Codex? I Think We're Asking the Wrong Question

After building the same website with Claude and Codex, I stopped asking which one was better. Both can design, both can code, but they bring very different instincts to the work. Maybe choosing an AI is less about capability, and more about choosing the right collaborator for the task at hand.

Over the past few months, I’ve been building my website with a lot of help from AI, and somewhere along the way I found myself regularly switching between Claude and Codex.

At first, I assumed that eventually I would settle on one. I’d use both for long enough, figure out which one was better and that would become my default. It seemed like the obvious outcome, especially when so much of the conversation around AI still revolves around comparisons, benchmarks and which model happens to be ahead this week. Except that never really happened.

The more I worked with both, the more I noticed that I was reaching for them at different moments. It wasn’t necessarily because one couldn’t do what I needed — most of the time, both could — but because the amount and type of direction I had to give them was different. Eventually I realised I wasn’t really choosing between two AI tools. I was choosing between two different collaborators.


When I’m designing, Claude seems to understand what I care about

I’m a designer, so when I’m working on the design of my website, I already have a fairly clear idea of what I’m trying to achieve. I understand the system, I know why certain patterns exist, and I can tell when something technically works but somehow doesn’t feel right.

This is where working with Claude feels particularly natural to me.

It isn’t simply that it can produce a good-looking interface. Codex can do that too. What I notice is all the smaller decisions Claude tends to make without me explicitly asking for them.

It looks at the patterns that already exist and tends to reuse them. It makes better use of the existing assets, tokens and styles by default, rather than creating something new simply because it can. The visual hierarchy tends to feel more considered and, when I’m working in Figma, even things like artboard organisation and layer naming often end up closer to how I would want to leave the file myself.

But the part I enjoy most is when it takes something I’ve already designed and adds a little flair that I didn’t quite know I needed.

It might be a small change in composition, a better use of an existing element or simply a slightly different way of presenting something. Nothing that completely changes the direction, but enough that I occasionally look at what it has done and think, yes, that’s better.

That feels much closer to collaborating with another experienced designer than asking a tool to execute instructions.

I bring my own expertise to the conversation, Claude understands enough of that intent to challenge or extend it, and the result can be better than either the initial prompt or the initial design.

Designing with Claude feels more like collaborating with a fellow designer

Then I start coding, and the relationship changes

When I move deeper into implementation, I find myself gravitating towards Codex instead. There’s an important distinction here, though.

I’m not a developer. I can understand enough code to follow what is happening, I can reason about how I want something to behave, and I can certainly evaluate whether the product in front of me does what I intended it to do. But if you gave me an empty React project and asked me to build my website from scratch, I couldn’t do it. Codex can.

So when I say that Codex makes the code cleaner, I don’t mean that I write some React and then hand it over for a nice refactor.

Codex is writing the code.

My role in that collaboration is different. I explain what I’m trying to achieve, Codex works out how to implement it, I test the result and then we iterate. Sometimes that means refining what it has built, sometimes it means discovering that an approach isn’t quite right and exploring another one entirely. And this is where I find Codex particularly strong. I can spend a long session exploring an implementation, changing direction, trying different approaches and gradually getting closer to what I actually want, while Codex continues to manage the technical consequences of those decisions. It organises the code, restructures things when necessary and handles engineering decisions I wouldn’t necessarily even know I needed to make. That changes what AI is doing for me.

With Claude, I’m extending a capability I already have. I’m a designer collaborating with something that often feels like another designer. With Codex, I’m accessing a capability I don’t have. I’m still defining the product, making decisions about what it should do and judging whether the outcome is right, but I no longer need to personally know how to build a React application to make that product exist. Interestingly, that isn't entirely unlike how I would work with a developer anyway.

I wouldn’t need to know how to write every line of a senior developer’s code in order to collaborate effectively with them. I’d need to communicate the intent clearly, understand the important constraints, evaluate the outcome and make decisions with them as the implementation evolves. That’s increasingly what working with Codex feels like.

Working with Codex feels more like having a working session with an experienced developer.

It started to feel less like choosing software and more like choosing a teammate

Once I noticed this difference, the comparison became much easier to understand.

Imagine I were building exactly the same product inside a traditional company. When I’m exploring the experience and designing the interface, I’d probably want to pair with a senior designer. I’d want someone who understands hierarchy, interaction, visual language and design systems, but also someone capable of looking at my work and saying, “Have you considered doing it this way instead?” That person doesn’t replace my thinking. They make my thinking better.

Then we reach implementation. The senior designer is still perfectly capable of contributing to the conversation, but they’re probably no longer the most useful person for me to pair with on every decision. Now I want the senior developer beside me — someone thinking about architecture, maintainability and all the technical decisions required to turn what we designed into a functioning product.

Putting those two people next to each other and asking which one is better would be a fairly meaningless question. Better at what?

Both might understand the entire product. Both might be capable of contributing outside their primary discipline. But the person I want sitting next to me depends on the problem I’m trying to solve at that particular moment. That has become my mental model for Claude and Codex.

Working with both feels like I am working with an end-to-end team.

The difference isn’t necessarily what they can do

This is also why I’m hesitant to say that Claude is better at design and Codex is better at development as if that were some objective ranking. That hasn’t really been my experience. Given the right context and the right prompts, I’ve had both produce good designs and good code. If I really wanted to, I could probably build the entire website using only one of them. The difference is how naturally I get there.

With Claude, I find myself having to explain fewer of the things I care about when I’m designing. Existing patterns, tokens, styles, visual consistency and the overall quality of the design artefact seem more likely to become part of its thinking without me repeatedly bringing them into the conversation.

With Codex, something similar happens during implementation. I can stay focused on what I want the product to do while it handles much more of the question of how that should exist in code.

That difference matters because prompting has a cost too. If two models can ultimately reach the same quality of result, but one of them requires me to constantly remind it about the things I care about, then capability alone isn't a particularly useful way of choosing between them. The more useful question becomes: which one naturally aligns with the work I’m doing right now?

Maybe choosing an AI is becoming a little like hiring

Companies rarely hire someone because they’ve somehow determined that person is objectively better than every other candidate.

Often several people are perfectly capable of doing the job. The decision comes down to fit. Whose strengths align most closely with the role? Who complements the rest of the team? Who understands the kind of problems they’re going to be solving? Whose instincts mean they’ll require less direction in the areas that matter most? I’m beginning to think choosing between capable AI models works in much the same way.

Claude aligns more naturally with how I think when I’m designing. It helps me go deeper into an expertise I already have, and occasionally takes my own thinking somewhere I hadn’t considered. Codex aligns more naturally with what I need when I’m implementing. It gives me access to an expertise I don’t personally have and lets me explore technical solutions that would otherwise be well beyond what I could build on my own. Neither needs to be bad at the other job for that distinction to matter. In fact, that’s precisely the point.

Both can be very good and still be better collaborators for different kinds of work. There’s also something I find quite exciting about that shift. AI is often discussed as if the end goal is to find the single model capable of doing absolutely everything for us, but I'm not sure that's necessarily how I want to work. I don't expect one human colleague to be my designer, developer, researcher, strategist and everything else at exactly the same level. We build teams because different people bring different strengths, perspectives and instincts to the same problem. Perhaps working with AI will increasingly feel the same.

After months of using Claude and Codex on the same website, I don't really have a winner. I've just stopped expecting there to be one. Both can design. Both can code. Given the right guidance, both can produce very good results. The choice, for me, comes down to intent rather than overall capability. Instead of asking “Which AI is better?”, I now find myself asking a much more practical question:

“Which team member do I need for what I’m trying to accomplish today?”

And that makes me curious about how other people are starting to work.

Are you still looking for one AI that can do everything, or are you starting to build your own team of AI collaborators and choosing between them depending on the problem you’re trying to solve?

Keep reading

More articles