Similar models, different AI products — why?

Building products with AI recently, I’ve started noticing a question I never thought about seriously before.

OpenAI has ChatGPT, Codex and Work; Anthropic has Claude, Claude Code and Claude Design.

These products from the same company don’t necessarily use exactly the same model versions and configurations, but they’re often built on the same or similar model families.

So why are the differences in capability still so obvious in actual use?

ChatGPT itself can write code, for example. But when I really need to go into a codebase, change files, run tests and deal with Git, I still go to Codex.

Claude can discuss code and design too, but Claude Code and Claude Design show stronger execution in engineering and design respectively.

So whether an AI product is ultimately good to use clearly can’t be judged by the underlying model alone.

There’s a very important concept in between: the harness.

Between model and product, there’s a layer called the harness

Roughly speaking:

the model provides the basic capability; the harness organizes that capability into a system that can do a certain kind of work.

A harness usually decides:

• what instructions the model receives;
• which context it can read;
• which tools it can use;
• what runtime it works in;
• whether it can carry out several steps in a row;
• what permissions it has;
• how to verify whether results are correct.

So an AI product’s capability can be roughly seen as:

Model + Harness + Product Design

The model sets the ceiling of understanding, reasoning and generation.

But between “the model knows how to do it” and “the user actually got the result,” there’s a lot of product and engineering design.

1. What can it see?

Say I need to track down a bug.

In an ordinary chat, the model usually only has:

• the code I pasted;
• the error message;
• uploaded files;
• the current conversation;

to judge the problem from.

In Codex or Claude Code, it can also proactively read:

• the repo structure;
• the relevant source code;
• the Git diff;
• the current branch;
• the project rules;
• build and test results;
• the new state produced after the previous step.

Many software problems don’t live in a single file.

An endpoint failing may be caused by the database schema, another service, an old migration, even a change from a few days ago.

So a coding agent seeming to “understand the project better” isn’t necessarily only because the model is stronger.

It has more complete, more up-to-date project context.

2. Does it have tools to actually carry out the task?

The model itself doesn’t actually change files on a computer.

It can judge:

the next step should be running the tests.

But to really run them, the product has to give it the right tools.

A coding agent usually has:

• file reading and writing;
• code search;
• Git;
• a shell;
• build and test tools;
• a browser or other development tools.

The shell here simply means the command-line execution environment.

For example, what we normally run in Terminal:

git status npm test python app.py

With a shell, AI doesn’t just tell me “you could run the tests”; it runs them itself, reads the real results, and then decides the next step.

So:

being able to generate code and being able to change a real software system are two different things.

The former depends mainly on the model.

The latter also needs tools and an execution environment.

3. Can it do “act → look at the result → act again” on its own?

Ordinary chat easily settles into this way of working:

I ask → AI answers → I go and do it → bring back the result → AI answers again

The way an agent works is closer to:

understand the goal → act → look at the result → judge → change → act again

That’s the agent loop.

It matters because real work is rarely completely right the first time.

Code throws errors, tests fail, dependencies conflict, pages may not look as expected.

If a person has to carry the information back every time something new happens, the task is still mainly driven by the person.

An agent can see the failed test itself, then keep looking for the cause and making changes.

Only then does AI move from “answering questions” further toward “completing tasks.”

4. Different products need different working environments and feedback

That’s also why coding agents and design agents are slowly becoming different products.

When writing code, you can rely on very clear feedback:

• test pass / fail;
• whether the build succeeds;
• lint;
• what the program actually does when run;
• the Git diff.

So AI can:

change → test → fail → change again → test again

Design needs completely different feedback.

If the model can only discuss design in a chat box, it can hardly judge directly:

• whether the page’s visual weight feels right;
• whether the spacing is right;
• whether there’s a problem with the type hierarchy;
• what several components actually look like together.

Design products give the model a canvas, rendered results, components, a design system and tools for visual editing.

The models may be similar, but the working environments differ, and so do the feedback loops they can form.

So tools don’t only help AI “carry out the last step.”

Knowing which tools it can use also changes how the model goes about solving the problem.

With a shell and tests, it can run something first and then judge.

With a canvas, it can make something first and then adjust.

5. Once AI starts doing things, permissions become part of product capability too

This is something I only started feeling clearly in real development recently.

When chat mainly outputs text, permissions barely register.

But once AI needs to:

• change files;
• access the network;
• push to Git;
• read credentials;
• operate on a database;
• deploy to production;

it has to answer another question:

how far is it allowed to go?

So a mature agent harness also has to handle:

• the sandbox;
• the scope of file access;
• network permissions;
• approvals;
• identities on external services;
• task state and recovery.

That’s also why, even though I clearly told Codex:

take this task all the way to release.

it could still run into system approvals and external logins along the way.

Business permission to accomplish a goal, system permission to perform an action, and a service like GitHub allowing the current account to operate are different layers of permission to begin with.

These questions only become very concrete once AI really moves from “saying” to “doing.”

So the difference between ChatGPT and Codex isn’t just “who writes code better”

ChatGPT itself can certainly understand code, design solutions and review implementations.

But the work object it faces by default is closer to:

a question, a conversation, a piece of knowledge work.

What Codex faces is:

a real software project, and the changes that need to happen within it.

So it needs a more specialized software-engineering harness:

Model + Repo Context + File / Git + Shell + Tools + Agent Loop + Permissions + Tests / Verification + Persistent Task State

The difference between Claude and Claude Code or Claude Design can be understood from the same angle.

The point isn’t only whether the system prompt says “you’re a programmer” or “you’re a designer.”

The bigger difference is what work objects, tools, environment and feedback each product gives the model.

This has also changed how I judge AI products

Before, when I saw an AI product, I’d easily ask first:

what model does it use?

I still look at the model now, but I go on to ask a few more questions:

What can it see?

Only the prompt, or can it enter the real working context?

What can it do?

Only give suggestions, or modify, run and operate on real objects?

Can it work continuously?

Come back to ask after every step, or keep going on its own based on results?

How does it know it got it right?

By sounding “reasonable,” or through feedback like tests, rendering and real data?

What are its permissions and working environment?

Does it have enough ability to execute, while keeping reasonable safety boundaries?

These questions are often closer than model benchmark comparisons to how much productivity an AI product can actually bring.

The final takeaway

The model still matters a lot.

It decides understanding, reasoning ability, and the ceiling of a product’s capability.

But the final experience also depends on a whole set of things beyond the model:

context, tools, runtime, the agent loop, permissions, verification.

All of these can be counted as part of the harness.

So when I look at an AI product now, I break it into three layers:

Model: how strong its basic capability is. Harness: how that capability is organized to get work done. Product: how users ultimately get to use it.

Knowing only which model sits underneath is no longer enough to judge what an AI product can actually do.