Table of Contents

I Thought Claude Code Alone Was Enough

Recently, I've been relying on Claude Code for most of my programming work.

Whether I'm building a new feature, fixing a bug, or updating the system behind one of my blogs, Claude Code is usually the tool I use. I've also been using it long enough that I'm comfortable with how to give it instructions.

Until fairly recently, I honestly thought, "Maybe Claude Code is all I really need for development."

That changed a little after I had Codex and Google Antigravity review some of the sites I run. These were sites that Claude Code had already worked on many times, yet Codex and Antigravity still found several problems that I had not noticed before. What was even more interesting was that Codex and Antigravity did not find exactly the same kinds of problems.

At this point, I don't think this is as simple as asking whether Claude Code, Codex, or Antigravity is "the best." They seem to look at projects in different ways.

I've Been Using Claude Code as My Main Development Tool

I normally use Claude Code as the main tool for development. I use it for website development, Cloudflare Workers, D1, and various internal tools.

One of the things I like about Claude Code is how easy it is to let it work directly inside an actual project. If I tell it, "Something is wrong with this feature. Find the cause," it will search for the relevant files, read the code, use curl when necessary to check the live behavior, and often continue all the way through to the fix. It is very good at digging deeply into a specific problem. That is why, for day-to-day development, Claude Code is still the tool I find easiest to use.

But after relying on it for a long time, I've also started to notice one weakness. It is good at investigating the problem you point it toward, but it does not always expand its scope and ask things like:

  • "Is anything else strange here?"
  • "Is there another part of the system that could cause trouble later?"

Of course, I can explicitly tell it to audit the entire site, and it will do that. Even then, though, Claude Code often feels more focused on completing the task in front of it than on scanning the entire project for unrelated inconsistencies. That matched what happened when I tried a code-analysis tool called GitNexus too — it dug deep into whatever I pointed it at, but it did not go looking for unrelated inconsistencies on its own unless I explicitly asked.

I Let Antigravity Audit the Entire Site

I then asked Antigravity to review the source code of one of my blog sites. It came back with quite a few issues. (I have also written before about the API key trap that catches most people doing personal projects in Antigravity.)

For example, there was a bug in the sitemap generation logic that prevented the Japanese and English versions of articles from being matched correctly. The English article slugs ended in -en, but the code was trying to match them against the Japanese slugs as exact strings. As a result, the sitemap was not generating reciprocal hreflang entries between the Japanese and English articles. It also found issues such as:

  • URLs with a trailing slash returning 404
  • the Japanese homepage missing WebSite structured data
  • several static pages being missing from the sitemap
  • different kinds of 404 pages being shown depending on the URL
  • language detection using startsWith('/en'), which could incorrectly classify a future URL such as /entry as an English page

These were things that Claude Code and ChatGPT had both looked at the site multiple times without pointing out. My impression is that Antigravity may be better at broadly scanning a site and looking for inconsistencies across templates, routing, SEO settings, and structure. There was one downside, though.

Antigravity Tended to Exaggerate How Serious the Problems Were

Important: For example, it described the missing hreflang entries in the sitemap as a very serious SEO problem. However, if the hreflang tags in the HTML are already implemented correctly, Google can still understand that the Japanese and English pages are alternate language versions. It also described the lack of breadcrumbs using fairly strong language, saying they would significantly improve CTR and were essential for crawler navigation. The issues it found were real. But the impact was sometimes overstated. That has also matched my general experience with Gemini-based tools — they are often very good at finding things that might be wrong, but they also tend to make those findings sound more serious than they really are.

I Asked Codex to Audit the Same Site

Next, I had Codex review the same site. The results were also interesting. Codex found some of the same issues as Antigravity, including the hreflang problem in the sitemap. But it also found a different set of problems.

For example, Codex actually tested what happened when unusual page values were passed in:

  • ?page=999
  • ?page=abc
  • ?page=0
  • ?page=-1

Some of those URLs returned HTTP 200 even though there were no valid articles, while others displayed an error page that was still indexable. The same thing happened when a non-existent category was specified. These are the kinds of problems you are unlikely to notice just by browsing the site normally.

Example: Codex also found things such as: publisher.logo in the structured data pointing to a non-existent image, external links to services such as AppSheet returning 404, the API returning 500 when given an invalid page, no upper limit on the API limit parameter, bot traffic being counted as normal article views, and parts of the system still referencing the database name from an older project. It also pointed out security-related issues, including the possibility of reflected XSS through the category parameter and weaknesses in the admin authentication design.

Some of the security choices were things I had intentionally simplified because this is not a large enterprise system, so those findings were not all surprises. Still, it was useful to have them pointed out. What impressed me most was that Codex did not only read the code. It also tried unusual inputs to see how the system behaved.

They Look at the Same Source Code in Different Ways

After this test, I started to see fairly clear differences in how each tool approached the project. Claude Code was strongest when I gave it a specific problem to fix. It would read the related code, trace the cause, and carry the change through to implementation. Antigravity was good at looking across the site as a whole and finding issues in shared templates, SEO settings, routing, and structural consistency. Codex went further into things like unusual input values, APIs, databases, stale configuration, and "what happens if I use this in an unexpected way?"

Of course, this was only one project and one set of prompts. I do not think it would be fair to use this test alone to make absolute claims about the ability of each AI. But it did make me think that relying on the same AI for both development and review may not be ideal.

It's Hard to Ask the Same AI That Built Something to Find All of Its Own Mistakes

This is not really unique to AI. The same thing happens with human developers. When you review code you wrote yourself, you naturally miss things. You already know the assumptions you used when you wrote it, so you are less likely to question those assumptions. Something similar may happen when using AI.

You tell Claude Code, "Build this feature like this." Then you ask the same Claude Code, "Now check whether there are any problems." It will certainly perform a review. But if the original assumption was wrong, the same model may be more likely to keep reviewing the system based on that assumption instead of questioning it from scratch. That is why I found it interesting that a different AI could look at a project Claude Code had worked on for a long time and still find new problems.

So Should You Pay for All Three?

If your only goal is maximum quality, then this workflow probably makes sense: Claude Code for development → Codex for review → Antigravity for another review. Because they tend to find different kinds of issues, using all three could reduce the chance of missing something.

But if the conclusion is simply, "You should subscribe to all three," then this becomes a fairly expensive recommendation. Paying for several AI services every month is probably unnecessary for many individual developers and small teams. I also do not plan to use all three at the same level.

For Now, I Plan to Keep Claude Code as My Main Tool

At the moment, the most realistic approach for me is: pay for Claude Code and use it as the main development tool, then use Antigravity, Codex, ChatGPT, or other AIs within their free limits to review the finished result. If I ran a full audit after every small code change, I would quickly burn through the free usage limits. So I think it makes more sense to do this after I feel a feature or project is mostly finished.

There is also value in getting used to one development tool. Constantly switching between Claude Code, Codex, and Antigravity during normal development would make the workflow more complicated. I have been very satisfied with Claude Code for implementation and debugging, so I do not see a reason to replace it as my main development tool right now.

What I want to change is the review process. Until now, my workflow often looked like this: Claude Code builds it → Claude Code reviews it. Going forward, I think this is better: Claude Code builds it → Claude Code performs an initial review → Antigravity, Codex, ChatGPT, or another AI performs a second review. I do not think I need to use every AI every time. But after a large feature addition, before a release, or after a major site-wide change, having another AI audit the result seems worthwhile.

Feed the Review Results Back into Claude Code to Reduce Repeat Mistakes

I am not yet sure how effective this will be, but I also tried feeding the findings from Codex and Antigravity back into Claude Code. I told it, "When you work on similar projects in the future, please pay attention to these kinds of issues too." Claude Code responded that it understood, and the relevant notes were also added to its Memory.

Important: Of course, I do not expect this alone to prevent the same problems from ever happening again. Even if something is written in Memory or CLAUDE.md, there is no guarantee that every future development task will follow those instructions perfectly. Still, if another AI finds a recurring failure pattern, sharing that pattern back with the AI I use for most of my development may at least make it more likely to consider the issue next time.

For now, I plan to use a workflow like this: Claude Code builds it → Codex or Antigravity reviews it → the findings are shared back with Claude Code.

ChatGPT Is Useful for Evaluating the Review Results

Another thing I learned from this test is that you should not automatically trust every warning an AI produces. Antigravity found many legitimate problems, but it often described the SEO impact as much more serious than it probably was. Codex also mixed major issues with things that were simply worth improving.

Tip: So I took the findings and gave them to ChatGPT, then asked questions such as "Is this actually serious?", "How much could this affect SEO?", and "Does this really need to be fixed immediately?" Separating the AI that finds the problem from the AI that evaluates the severity may be a useful workflow in itself.

ChatGPT has weaknesses too. I had previously asked ChatGPT to review these sites, but it had not discovered many of the problems later found by Antigravity and Codex. When auditing websites, ChatGPT often relies more heavily on search results and pages it can retrieve, so it may not explore the local source code as broadly as a development tool that has direct access to the project. On the other hand, once a problem has already been found, ChatGPT is quite useful for evaluating how serious it actually is and for organizing the findings into something understandable.

I Had Actually Tried AI Cross-Review Before

This was not the first time I tried having one AI review the work of another. In the past, I built a system called "Gemini QA" where code developed with Claude Code was reviewed using the Gemini API (related article). Even back then, Gemini sometimes caught problems that Claude Code had missed.

At the time, AI coding agents were much less reliable than they are now, so I considered this kind of external quality check almost essential. As AI agents improved, I gradually stopped doing it as often. I probably became a little too confident in the quality of a single AI. After trying Codex and Antigravity this time, I was reminded that for larger projects, having a different AI review the work is still a useful idea.

We May Still Be in a Period Where AI Cross-Review Is Necessary

AI development tools are evolving extremely quickly. The tool that feels best today may not still be the best tool six months from now. Claude Code has strengths. Codex has strengths. Antigravity has strengths. When I gave them the same project, those differences became much easier to see.

So at least for now, I do not think the most useful question is "Should I choose Claude Code or Codex?" or "Is Antigravity the best?" I think it is more practical to choose one AI as the main development tool and use a different model as a reviewer (I felt something similar when comparing how much work you can actually hand off to Claude Cowork, Genspark Claw, and Gemini Antigravity). For me, Claude Code will remain the main tool for now. But I am going to be much more deliberate about showing finished code and websites to other AIs before I consider the work complete. When I actually tried that, they found several problems I had not noticed before.

You do not necessarily need to pay for multiple AI subscriptions either. If another AI offers enough free usage to perform occasional reviews, that alone may be enough. At this stage of AI-assisted development, finding "the single best AI" may matter less than making sure you do not trust one AI too much.