Why Explain This at All?

I keep noticing that conversations about AI tools are turning into a strange argument over favorite teams. One person says ChatGPT is better at reasoning. Another says Claude writes better code. A third brings up Gemini and explains that everyone else simply does not know how to work with large contexts. Then someone using Codex shows up and says chat is the wrong format entirely: what you need is a proper agent inside the repository.

In a way, all of them may be right. Or all of them may be wrong. The question itself is simply too broad.

I do not really understand why we need to pick one primary AI tool and then defend it. To me, these products increasingly look like a regular toolbox. Sometimes I need an agent that can quickly enter a repository, inspect the neighboring files, and build something in the same style. Sometimes I need an annoying reviewer who will challenge the plan and point out that the conclusions do not follow from the arguments. Sometimes I just need a quick draft that I will still have to turn into something human by hand.

So this is not a guide to choosing the best AI. I mostly want to write down my current approach before it turns into a blur in my head. The setup may change in six months because models and products both evolve quickly. But the main idea seems stable enough: several AI agents can play different roles in one process instead of competing for the title of the only decent assistant.

The “Which One Is Better?” Argument Does Not Work Well

Models have an inconvenient property: they are almost never compared in a vacuum. In one place, people compare ordinary chat interfaces. Somewhere else, they compare coding agents. Then it is image generation, followed by fixing real issues in real repositories. Someone takes one result and turns it into a sweeping conclusion: that is it, this model is now the best at everything.

I have nothing against benchmarks. Quite the opposite: without them, the entire discussion collapses into “I liked it” versus “I did not.”

For example, SWE-bench is useful as a benchmark for software engineering tasks. What matters there is the ability to solve real problems from repositories, pass tests, and avoid breaking the project along the way.

But that still does not mean that the leader in this benchmark will automatically be the best choice for writing, research, document analysis, or reviewing one of my specific Obsidian notes. Or for a personal monolithic website with a large codebase that is already impossible to keep entirely in my head, forcing me to split work into smaller pieces. Those are simply different classes of tasks.

You can see the same thing in LMArena, which has separate arenas and categories. Some compare general chat, some code, some vision, some web development, and some document work. The mere existence of these categories suggests that saying “model X is better than model Y” without naming the task should raise suspicion.

On top of that, we often compare not only the models but also the products built around them. So the argument is not only about the model’s brain. The interface matters. Repository access, working with diffs, permissions, context, integrations, review ergonomics, safety restrictions, and simply how well a particular product fits into your workflow all matter too.

How I Think About It

I think it helps to look at AI agents in roughly the same way we look at people in software development. One person can write the code, but that does not mean they should also merge it into main without an outside perspective. Code review does not exist because the reviewer is always smarter than the author. Sometimes the author is stronger. The other person simply looks at the task from a different angle.

I have a similar feeling about agents. An agent that came up with a plan and implemented the solution is often worse at spotting problems in its own line of thought. It has already committed to a path and will tend to keep extending it rather than honestly examining why that path might have been bad. It is not human pride, but the effect feels similar: the existing context pulls everything along with it.

That is why I like to separate the roles:

• one agent helps formulate the plan;
• the same agent in a different session, or another agent, does the main work;
• a separate agent reviews the result;
• a human makes the final decision.

This may sound slightly formal, but in practice it is a very ordinary setup. One helps get the work done; the other helps you not trust the first one too much. That is all.

It is not a guarantee of quality. The second agent can also be wrong, hallucinate, nitpick irrelevant details, or miss a real problem. But at least it follows a different reasoning path. Sometimes that is enough to surface a strange spot that the first agent and I have already accepted as normal.

My Current Setup

Right now, my approach is fairly simple: Codex for planning and development, Claude for review.

Codex works well for me specifically as an agent inside the repository. It gathers context quickly enough, navigates files well, and does not get lost too often when the task sounds like: “See how this is already done in the project and build the new thing next to it in the same style.” That matters to me because this is what most real software development looks like, rather than writing perfect code on a blank page.

It works best when the task has clear boundaries: here is the file, here is the style, here is what must not be touched, and here is how to verify the result. The better the frame, the less likely it is to invent extra work. In planning mode, it also usually breaks the work down sensibly and does not leave completely bizarre gaps.

Claude plays a different role in my setup. I like using it as an outside reviewer: I can show it a plan, a diff, an article, or an architectural decision and ask it to find the weak spots. Not to praise it. Not to rewrite everything in its own way. Specifically to find problems.

Yes, Claude sometimes has more trouble staying within the boundaries and can hallucinate with more confidence than I would like. But that is not always a downside in review. What I need from it is not obedience but an outside perspective. I would rather have it occasionally nitpick something irrelevant than have both agents stay silent about a place where I am already tired and have stopped noticing the problem myself.

For code, for example, I usually want feedback along these lines:

• where a contract may have been broken;
• which tests are missing;
• where the solution is too complex for the task;
• where the agent reached a conclusion that the code does not support.

The questions are similar for writing:

• where the conclusion is stronger than the original arguments;
• where the text sounds too polished and AI-generated;
• where an example is missing;
• where I accidentally started writing a universal guide instead of stating my own position.

I do not want to claim that Claude is objectively better at review or that Codex is objectively better at writing code. That would be too strong a statement. This setup is simply more convenient for me right now: Codex stays closer to the repository and execution, while Claude stays closer to criticism of the result.

What This Looks Like in Practice

A typical software development scenario looks like this.

First, I give Codex a task and ask it to understand the context. If the task is not completely obvious, it starts with a plan. I check whether it has drifted somewhere else, proposed a strange refactor for the sake of refactoring, or decided to change something that does not need to be touched at all.

Then Codex implements the solution. In a normal case, it reads the relevant files, edits the code, and runs the tests or at least the relevant checks. After that, I inspect the diff. You can catch a lot by hand at this stage because sometimes the problem is not in the tests. The solution simply does not look like the rest of the project.

For example, everything may technically work, but it is obvious that the agent created a beautiful abstraction where the surrounding project has three simple functions. Or the opposite: it added a local patch even though the codebase already has a proper helper for this exact task. Tests do not always catch that. A quick look at the diff sometimes does.

After that, I can give the diff or a short description to Claude and ask for a review. It is important to frame the task explicitly as a review. Otherwise, the agent can easily interpret it as a request to check syntax, tests, and linters. It is better to ask directly for bugs, questionable decisions, missing checks, and conclusions stated with too much confidence.

The same applies to writing. If you ask an agent to “improve the article,” it will almost always start smoothing the edges, adding tidy transitions, and making the text more proper. That is not always what I need. Sometimes I need to ask the opposite questions: where does this sound too AI-generated, where did the personal position disappear, and where did I start writing instructions for everyone instead of honestly describing my own experience?

The most important part begins after the review: do not automatically apply everything the second agent said. Sometimes it is right. Sometimes it did not understand the context. Sometimes it proposes making the project “nicer” while actually pulling it in a different direction. Its comments should be handled the same way as human review comments: accept some, reject some, and clarify the rest.

The final decision still belongs to a human. If two agents disagree, that does not mean you should average their answers. You need to figure out where the argument is and where there is only confidently written text.

This Is Not a Universal Approach

First, this approach is not always necessary. For a small task, it may be pure overhead. If you need to fix a typo, rename a variable, or throw together a one-off script, sending it through several agents is often pointless. You can spend more time moving text between windows than completing the task itself.

Second, there is the question of privacy. The more tools involved in the process, the more places there are to accidentally send unnecessary context. If the task includes personal data, trade secrets, internal documents, or credentials, you need to think first and enjoy the elegant agent workflow later.

Third, agents can argue with each other. One says, “This is fine,” while another says, “Everything here is wrong.” At that point, a human needs to understand the task. Without that understanding, it is easy to fall into a stupid infinite loop: one agent writes, the second criticizes, the first fixes it, the second criticizes the fixes, and somewhere along the way the entire point of automation dies.

Benchmarks also age quickly. Today one model is better on a particular set of tasks. Tomorrow a new version comes out. The day after that, the product changes. A week later, the limits or interface are different. I switched from Claude as my primary tool to Codex because Claude’s limits were too low, and then those limits were raised significantly. So I would not build a process around the belief that “this model will be the best forever.” With AI right now, it is strange to pretend that a habit that worked six months ago is guaranteed to keep working.

And one more important point: if a task can be checked with tests, a linter, types, a running application, or a factual source, then check it. An agent’s opinion is not a substitute for verification. A second agent may be a useful reviewer, but it does not turn an assumption into a fact.

Conclusion

I am increasingly tired of the idea that we need to pick one primary AI tool and defend it like a favorite football club. It is more practical to keep several tools around and understand where each one actually helps.

For me, the current setup is that Codex helps plan and make changes in a project, while Claude helps me look at the result from the outside. The setup may change after a while. Maybe another agent will become better at review. Maybe Codex will become more convenient for that role too. Maybe I will move to automated reviews with Cursor’s BugBot. That is fine.

I do not want model choice to turn into a religion. At work, the logo at the top matters less than whether a particular agent helps complete a particular stage of the task faster, more carefully, and with fewer stupid mistakes.

A Small Update

Writing this article stretched over several months, and, as I said it might, my approach changed. I tested how Codex and Claude Code handle code review and realized that I do not need to pay for Claude separately. I can move entirely to Codex.

In my case, it is enough to start a new session and give it the same code review task. It works like clockwork, and in some situations Codex performs better and finds more bugs, although not always.

Even with this update, I do not think the article has lost its point. In another couple of months, I may return to the Claude ecosystem again without any difficulty because, first and foremost, it is a tool that can be replaced.