Your AI Can Code. Why Does It Keep Building the Same Landing Page?

L. Roesmann — Fri, 06 Nov 2026 16:49:25 +0000

Ask an AI coding tool for a “modern SaaS landing page.”

You can almost see the result before it finishes generating:

A giant centered headline. One word in a purple gradient. Three feature cards. A glowing button. Something blurry floating in the background for reasons nobody can explain.

The code probably works. The layout is responsive. The button even has a hover state.

Congratulations. You've built a website for a product that could be absolutely anything.

I don't think the solution is to write a 900-word prompt containing the word premium seven times. The problem starts earlier: we're asking AI to make design decisions without giving it anything meaningful to decide from.

Let's fix that with one fictional product, a few concrete constraints, and an example you can steal for your next React project.

The problem isn't the gradient

There's nothing inherently wrong with gradients, centered headlines, or cards. Plenty of excellent websites use them.

The problem is using them before you know what the page needs to communicate.

Imagine two products:

A tool that turns screen recordings into reproducible bug reports.
A portfolio platform for experimental 3D artists.

Both need a landing page. Both could use React and Tailwind. But if both open with the same centered headline and three cards, the layout is doing almost no work.

For the bug-report tool, a real example report is probably more persuasive than a decorative illustration. For the artist platform, a full-bleed visual might be the entire argument.

Same stack. Different story. Different layout.

That's the part the prompt needs to explain.

Start with the thing you're actually selling

Let's use the fictional bug-report product as an example. We'll call it Repro. It turns a screen recording into a bug report with clear reproduction steps.

A vague prompt would be:

Build a clean, modern landing page for Repro. Make it premium and add smooth animations.

There is almost nothing here for an AI editor to make a good design decision with.

This is the version I'd actually hand it:

PRODUCT
Repro turns screen recordings into bug reports with
clear steps to reproduce the issue.

AUDIENCE
Frontend engineers and small product teams.

ONE THING TO UNDERSTAND
A recording goes in. A usable bug report comes out.

PRIMARY ACTION
See a sample bug report.

VISUAL DIRECTION
Technical but approachable. Editorial typography.
Off-white background, dark text, one restrained accent.

HERO COMPOSITION
Left: short headline, explanation, one primary CTA.
Right: a realistic sample bug report, not an abstract graphic.
The preview should be the main visual proof.

AVOID
Generic three-card hero, decorative blobs,
gradient headline, stock illustrations.

RESPONSIVE BEHAVIOR
On mobile, stack copy before the sample report.
Keep the CTA visible without horizontal scrolling.

BEFORE CODING
Propose three clearly different compositions.
Explain the trade-off of each in two sentences.
Wait for a choice before writing JSX.

Notice what's missing: a long list of trendy effects.

Notice what's there: a reason for every major element to exist.

Don't ask for a prettier page. Ask for three different pages.

This is an underrated step.

If you ask for one layout, you get one layout. Then you spend the next ten prompts trying to talk the model out of its first idea.

Instead, ask for three compositions with actual differences:

Direction	What changes	When it makes sense
Product-first	A large sample report takes up most of the hero	The interface explains the value quickly
Editorial	Big typography, narrow copy, small annotated preview	The message needs a strong point of view
Workflow-first	Recording, processing, and output shown in sequence	The transformation is the product's selling point

Then choose one.

Not because the model declared it “the best option,” but because you can explain why it serves the content.

If all three proposals are the same layout with different border radii, send them back. That's not three directions. That's one direction wearing three jackets.

Put proof in the hero, not decoration

Here's a deliberately small React + Tailwind example for Repro. The right side is a sample output, not a glowing mystery object.

export default function Hero() {
  return (
    <section className="bg-[#F7F7F5] px-6 py-20 text-zinc-950 md:py-28">
      <div className="mx-auto grid max-w-6xl items-center gap-14 md:grid-cols-2">
        <div>
          <p className="mb-5 text-sm font-medium text-zinc-500">
            For teams that ship software
          </p>
          <h1 className="max-w-xl text-5xl font-semibold leading-[1.06] tracking-tight md:text-6xl">
            Less explaining bugs. More fixing them.
          </h1>
          <p className="mt-6 max-w-md text-lg leading-8 text-zinc-600">
            Turn a screen recording into a report your teammate
            can actually reproduce.
          </p>
          <a
            href="#sample-report"
            className="mt-8 inline-flex min-h-11 items-center rounded-lg bg-zinc-950 px-5 py-3 text-sm font-medium text-white hover:bg-zinc-800 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-zinc-950"
          >
            See a sample report
          </a>
        </div>

        <article
          id="sample-report"
          aria-label="Example bug report"
          className="rounded-xl border border-zinc-200 bg-white p-6 shadow-sm"
        >
          <div className="flex items-center justify-between gap-3">
            <span className="text-xs font-semibold uppercase tracking-wider text-zinc-400">
              Bug report #142
            </span>
            <span className="rounded-full bg-amber-50 px-3 py-1 text-xs font-medium text-amber-800">
              Needs review
            </span>
          </div>
          <h2 className="mt-6 text-xl font-semibold">
            Save button doesn't respond
          </h2>
          <p className="mt-2 text-sm text-zinc-500">
            Example output from a screen recording
          </p>
          <ol className="mt-6 list-inside list-decimal space-y-3 text-sm text-zinc-700">
            <li>Open account settings</li>
            <li>Change the display name</li>
            <li>Click Save</li>
          </ol>
          <p className="mt-6 border-t border-zinc-100 pt-4 text-sm text-zinc-700">
            <strong>Observed:</strong> No confirmation appears.
          </p>
        </article>
      </div>
    </section>
  );
}

Is this the most visually exciting hero on the internet? No. It isn't supposed to be.

But you can answer three important questions immediately:

What does the product do?
Who is it for?
What will I see if I click?

That's already a stronger starting point than a beautiful layout that explains nothing.

Now comes the actual design work: refine the typography, make the preview look like the real product, tune the spacing, and decide whether anything needs to move at all.

Give the model something better than a blank canvas

Another useful trick is to work from editable components with an intentional composition rather than asking for every section from scratch.

You can use your own design system, a collection of components you've built, or a library you like. The important thing is that the editor can inspect the structure and you can change the code.

This is part of why we're building Systra Tools, a React + Tailwind component library that can also be accessed through MCP in compatible AI editors. The idea is to give the editor actual section implementations to work from, then adapt them to the content instead of hoping a vague prompt produces an interesting composition.

There's a catch, though: a good component doesn't automatically make a good page.

If you drop five spectacular sections onto one page with no shared typography, spacing, or pacing, you haven't created a design system. You've created a very expensive-looking argument between five sections.

Choose fewer things. Make them belong together.

The five-minute test before you ship

Before spending another hour polishing the hover animation, try this:

1. Hide the logo. Could the hero belong to a completely different product? If yes, add something specific: a meaningful preview, real language, or a product-specific interaction.

2. Read only the headline and CTA. Can someone understand the benefit and the next step? “Revolutionize your workflow” and “Get Started” are not doing much work here.

3. Look at the page in grayscale. Can you still see the hierarchy? If everything relies on an accent color, the composition may be weaker than it looks.

4. Open it on your phone. Does the most convincing proof disappear below three screens of decorative spacing? Move it up.

5. Turn the animation off. Does the page still make sense? If not, motion may be hiding a content problem rather than solving one.

One more rule: if the layout looks better after removing an effect, you are allowed to remove it. The CSS will recover.

Good AI-assisted design still needs decisions

AI can generate the first pass faster than most of us can open a new Figma file. That's useful.

But speed doesn't decide what matters on the page. It doesn't know which part of a product deserves the spotlight unless you tell it.

So next time the model gives you the familiar gradient headline and three cards, don't just type “make it more creative.”

Give it a real audience, a real job for the page, and a reason to choose one layout over another. Ask for competing compositions. Put proof where the decoration would normally go.

The goal isn't to make AI produce more UI. It's to make the UI say something.

What's one change you've made to your AI workflow that noticeably improved the design? I'm curious whether it's references, tighter constraints, better components, or something else entirely.

DEV Community: L. Roesmann