AI Design Battle: Gemini 3 vs. Opus 4.5 vs. Codex 5.1—Which Model Is the Best Web Designer?

I tested three coding models on the same front-end redesign: Gemini 3 Pro, Opus 4.5, and Codex 5.1. The task was not to generate a new landing page from scratch. Each model had to improve an existing ChatPRD blog page with the same code and prompt.

The comparison focused on the result I would actually ship: visual hierarchy, navigation, existing-brand fit, missing-image handling, and basic SEO implementation.

In this episode of How I AI, I run the three models in Cursor with the same input and compare their one-shot redesigns. This is a snapshot of those model versions on one task, not a permanent ranking of every design workload.

The setup

The ChatPRD blog worked, but the listing page needed clearer hierarchy and navigation, making it a useful redesign target.

I ran the comparison in Cursor so each model received the same repository and surrounding context.

The shared prompt

I gave all three models the same outcome-focused prompt rather than a detailed visual specification.

Here's the exact prompt:

Redesign the blog page to improve both the visual appeal and user experience. Add best practices for SEO and navigation.

Then I ran the same request through all three models and compared the results.

Round 1: Gemini 3 Pro

Gemini displayed a planning trace covering visual design, UX, and SEO before editing the code.

The result

Gemini produced a usable redesign with a stronger page hierarchy.

• A hero section gave the newest entry a clear focal point.
• A three-column card grid organized the remaining entries.
• Cards included image hover behavior, tags, and publication dates.

The version also placed a tag too close to the navigation and did not handle entries without featured images cleanly.

Gemini also added several SEO-oriented elements:

• JSON-LD structured data.
• Breadcrumb navigation.
• More semantic HTML structure.
• Page metadata.

Verdict: a fast and functional first pass that still needed visual cleanup.

Round 2: Opus 4.5

Opus began by creating a task list and implementation plan before editing the page.

Its plan covered four areas:

1. Redesign the listing page.
2. Improve the overall layout.
3. Improve how entries are displayed.
4. Add structured data, canonical URLs, and metadata.

That planning was followed by the strongest result in this comparison.

The result

Opus produced the version I preferred visually and functionally.

• It reused existing repository assets, including ChatPRD's rings motif, instead of inventing an unrelated visual language.
• The card interactions added a restrained image zoom and arrow cue.
• Entries without featured images received a consistent book-icon fallback.
• Cards included estimated reading time.

It also redesigned the newsletter form, though the first pass still leaned on a familiar AI-purple treatment.

Verdict: the winner for this prompt and repository because it used existing assets and handled more edge cases.

Round 3: Codex 5.1

Codex also created a task list, but its plan was less specific to the page and repository.

The result

Its redesign contained both visual and functional problems.

• The page used a generic purple gradient that did not match the existing brand.
• It selected a logo asset with a white background that conflicted with the gradient.
• The featured image was not linked, category links did not work in the demo, and the main list omitted existing entries.

Codex added metadata and Schema.org markup, but the broken listing and navigation meant the version was not ready to ship.

Verdict: not the right choice for this specific front-end task, despite my stronger results with GPT models on backend and functional work.

The result of this comparison

The repeatable testing method is captured in the one-shot blog redesign workflow.

Opus 4.5 produced the redesign I preferred among these three runs.

Its plan translated into better use of the existing brand assets, more complete edge-case handling, and stronger interaction details.

The practical lesson is to compare models on the work you need now. My choice from this test was Opus 4.5 for this redesign, Gemini 3 Pro for a fast alternative, and Codex 5.1 for other coding tasks where I had already seen better results.

The three runs took less than 20 minutes and produced options I could compare directly. The Opus version became the implementation candidate from the test.

Model behavior changes quickly, so the useful habit is rerunning a small, representative comparison when the task or model versions change.

I did not score the models from a single screenshot. I looked at how each one interpreted the brief, whether the page had a coherent visual point of view, how well the hierarchy held together, and how much useful iteration it took to reach something I would actually ship. A dramatic first pass is not enough if the system falls apart across the rest of the page.

The comparison also separated taste from obedience. I wanted each model to make choices, but I still expected it to respond when I rejected a direction or pointed to a specific problem. The best design partner is not the model that adds the most decoration. It is the one that can establish a strong idea, explain it through the interface, and then refine it without flattening everything into a template.

My conclusion is a snapshot of these models on this codebase and this brief, not a permanent leaderboard. The practical lesson is to run the same real assignment through the tools you are considering, keep the constraints and source material stable, and compare the complete working result. Model personality becomes much easier to see when the task, repository, and acceptance bar are held constant.

The most revealing failures were not questions of taste. Missing posts, dead links, broken image fallbacks, and brand assets used in the wrong context made a candidate unusable even when the screenshot looked polished. I want the model to treat the existing product as a system, not as raw material for a mood board.

That changes the evaluation order. I first check whether the page still works and contains the right content. Then I check hierarchy, navigation, accessibility, responsive behavior, and SEO. Only after those basics hold do I compare the visual point of view and the amount of iteration required to make it feel like ChatPRD.

A one-shot comparison is best for choosing where to begin, not deciding what can ship untouched. The winning model earns the next iteration. It still has to survive the same browser review, regression checks, and editorial judgment as any other implementation.

Using the same repository mattered as much as using the same prompt. Each model could see the existing components, content model, routes, and brand assets. Opus won partly because it noticed and reused that material. Codex lost ground because several choices ignored what the application already knew about itself.

I would run the test differently for a backend migration, a design-system cleanup, or a bug hunt. This round answered one narrower question: which of these model versions gave me the strongest starting point for a real front-end redesign with minimal direction? On that question, Opus 4.5 was the clear choice.

The speed of the exercise made the comparison cheap enough to repeat. In less than 20 minutes I had three concrete candidates, three sets of mistakes, and a much sharper view of where each model helped or hurt. That evidence was more useful than a general claim about which model is best at design.