Why I build with Claude, Codex and Gemini

I do not have a single favourite AI model for building products.

I use Claude, Codex and Gemini, often on the same project. I also move between models within those families. A quick Sonnet task and a difficult Opus task do not need the same amount of reasoning, time or money.

This can look inefficient from the outside. Why not choose the "best" model and keep everything in one conversation?

Because the best model depends on the work in front of me. I get better results when I treat models as specialists rather than interchangeable chat boxes.

Claude helps me think before I build

Claude is usually where I start when the problem is still messy.

It is good at taking a loose idea and turning it into something I can work with: a plan, a product requirement, a user journey, a clear explanation or a set of decisions that still need to be made. It is also the model I tend to trust most with longer writing because it can hold a narrative together without every section feeling disconnected.

That matters more than it sounds. A lot of bad builds begin with code before the product has been thought through. The result can be technically competent and still solve the wrong problem.

Claude also builds good prototypes. If I give it a clear brief, screenshots, a design direction and the right constraints, it can turn the plan into a working first version quickly. That prototype gives me something concrete to react to. I can see which assumptions were wrong instead of debating them in a document.

I use different Claude models for different levels of work. Sonnet is often enough for everyday planning, drafting and iteration. I reach for Opus when the problem has more ambiguity, a longer chain of decisions or a higher cost if the reasoning is weak. Using the biggest model for every task would be expensive and slow. Using a smaller model for every task would create a different cost: more corrections later.

Codex is where I want precision

Once a prototype becomes a real codebase, Codex becomes especially useful.

Codex is very good at coding inside an existing repository. It can trace how a feature works across files, make a narrow change and avoid rewriting parts of the system that did not need touching. That precision is useful when the instruction is not "build me an app" but "change this behaviour, preserve the existing design and do not break these tests."

I also use it for exact editing. A broad model may decide to tidy the surrounding code, rename things or improve a component while making the requested change. Sometimes that is helpful. Sometimes it creates a review problem. Codex tends to do well when the boundary needs to stay tight.

It is also strong at the less glamorous work that makes a prototype dependable: tests, error handling, migrations, refactors and debugging across a real project structure.

This is why I do not judge a coding model only by whether it can generate an impressive demo from a prompt. The harder test is whether it can enter a codebase that already has history, make the correct edit and leave the rest alone.

Gemini gives me a stronger visual starting point

Gemini is the model I reach for when the work needs a better design eye.

It is particularly useful for exploring layouts, interface direction and wireframes. With Stitch, I can describe the product, generate visual options and get to a credible screen structure much faster than starting with blank frames. It helps me see the product before I commit to a build direction.

This does not mean I accept the first design it produces. Generated interfaces can still be generic, overfilled or inconsistent. The value is that Gemini gives me visual material worth reacting to. I can compare layouts, remove what does not belong and turn the strongest direction into a clearer design brief.

That visual work then improves the other models. Claude produces a better prototype when it has a strong wireframe and visual rules. Codex makes more accurate frontend edits when the intended layout is visible rather than described through a long paragraph.

Model choice also happens within a model family

The choice is not only Claude versus Codex versus Gemini. I also choose the level of model based on the job.

For a contained task with clear acceptance criteria, a faster model is often the sensible choice. It can draft copy, update a component, summarise research or make a routine edit without turning every action into a major reasoning exercise.

I move up to a stronger model when the task involves ambiguity, architecture, several competing constraints or a decision that will shape everything after it. This is where a model such as Opus can earn its extra cost. I am paying for fewer shallow assumptions and a better chance of catching the difficult part early.

I do not always get the routing right. Sometimes a task that looked simple exposes a deeper problem. When that happens, I escalate it. The useful habit is not perfect prediction. It is noticing when the current model is producing churn rather than progress.

I use models to review other models

One of the most useful parts of this workflow is cross-review.

A model is often bad at spotting the assumptions hidden inside its own answer. If I ask the same model to review its work in the same conversation, it may defend the structure it already created. A fresh model sees different things.

I might ask Claude to review whether a feature plan makes sense for the user, then ask Codex to inspect whether the implementation matches that plan. Gemini can judge the visual hierarchy and point out where the interface is confusing. Codex can find an incorrect state transition or a fragile edit that looked fine in a browser. Claude can notice that the product is technically complete but badly explained.

The disagreements are useful. When two models reach different conclusions, I have found a part of the work that deserves my attention.

Cross-review catches straightforward errors too. Missing requirements, broken links, inconsistent labels, code that handles the happy path but not failure, or a wireframe that looks polished while hiding the main action. No model catches everything, but their blind spots do not always overlap.

A typical multi-model build

My workflow changes by project, but it often looks like this:

1. I use Claude to turn the idea into a plan, define the user journey and expose unanswered questions.
2. I use Gemini and Stitch to explore the interface and create wireframes.
3. I give the plan and visual direction back to Claude for a working prototype.
4. I use Codex to inspect the repository, tighten the implementation and make precise changes.
5. I ask the models to review the parts that suit their strengths: Claude for clarity and product logic, Gemini for visual design, and Codex for the code.
6. I make the final decisions and test the product myself.

The handoff matters. If every model receives a different version of the brief, the project drifts. I keep one source of truth for the requirements, decisions and visual references, then give each model the material it needs.

The model is part of the tool choice

I used to think model selection was mostly about finding the strongest general model. Building this way changed my view.

The useful question is much narrower: which model is strongest at this part of the job, and what should check its work?

Claude helps me shape the thinking and communicate it. Gemini helps me see the product. Codex helps me change the code without losing control of the details. Faster models handle routine work, while stronger models take the ambiguous decisions.

That division is not permanent. The models keep changing, and their strengths overlap. I adjust the workflow when the results tell me to.

The benefit comes from giving each model a clear role, preserving the same source material between them, and refusing to treat the first plausible output as finished.