Make AI build frontends that don't look like AI built them

The five tells

None of these are bad on their own. Together they are a signature, and once you can name them you cannot stop seeing them.

1Cream, a serif headline and a terracotta accent: Or its cousin, the dark page with a purple mesh behind a centred hero. Both were good choices once. Now they are the default that arrives whether or not the brief has anything to do with them.
2Three equal cards: Always three, always the same width, always an icon in a rounded square. Real content is rarely three things of identical weight. When it is, the row is fine. It never is.
3An uppercase label above every heading: FEATURES. HOW IT WORKS. WHY US. The section's position on the page already says what it is. The label is decoration pretending to be structure.
4An em-dash in every other line: The punctuation mark of machine prose. One on a page is a choice. Six is a fingerprint, and readers who have been on the internet in the last two years spot it now.
5A fake product screenshot built out of divs: Grey bars standing in for text, a coloured rectangle standing in for a chart, a traffic-light dot row standing in for a window. It reads as a placeholder because it is one.

There are more: Inter over slate-900, a fade-up animation on every section, a “Scroll to explore” cue under the fold, gradient blobs doing the job a real image should be doing. Five is enough to make the point.

Why it happens

The model reaches for a default instead of reading the brief. Ask for “a landing page for my bookkeeping service” and almost nothing in that sentence constrains the design. So it fills the gap with the most likely landing page it has ever seen, which is the average of a few hundred thousand of them. The average is the tells.

This is not a taste problem and you will not prompt your way out of it. Adding make it look premium moves you from one default to a slightly shinier one. The brief still has not been read, the rules are still not written down, and nobody has looked at the result.

So put those three things back in, in that order.

A design read before code. A rules floor while it builds. A screenshot it actually looks at.

The three-step loop

Read

Before any code, make it say one line out loud. Page kind, audience, vibe, and the design family it is leaning toward. That is it. The line is short on purpose: it is the thing you can disagree with in five seconds, which is the whole point of having it.

The line, before a single component

Reading this as: <page kind> for <audience>, with a <vibe>
language, leaning toward <design system or aesthetic family>.

Then three dials, each with a reason. Variance from 1 for perfect symmetry to 10 for artsy. Motion from 1 for static to 10 for cinematic. Density from 1 for a gallery wall to 10 for a cockpit. A trust-first page for sole traders sits around 3 / 2 / 4. A portfolio sits around 9 / 8 / 3. Written down, they stop the next decision being a coin flip.

One more move, and it is the one that does the most work: ask for the plan it would write for a similar but different brief. Every part that matches is a default, not a choice. Make it change those parts and say what changed. That is how cream and terracotta turns into something the brief actually asked for.

Build

Two layers, both written down before the build starts, because rules in a file get followed and rules in a chat message get forgotten by the third component.

The interface floor. Visible focus rings, 44px tap targets, labels tied to inputs, transform and opacity only in animations and never transition: all, explicit width and height on images so nothing jumps, min-w-0 on flex children so long words stop blowing out a row, reduced motion honoured. Vercel publishes this set as the Web Interface Guidelines. It is not taste. It is the difference between a page that works for everyone and one that works on your laptop.

The taste floor. The hero holds at most four text elements and fits the first screen. At most one eyebrow per three sections. One accent colour, one radius system, one theme per page. No row of three equal cards. No fake screenshot made of divs. Zero em-dashes in anything a reader sees. Real copy from the brief, no Acme, no John Doe, no invented statistic.

If the project already has a look, it wins. A brand that is purple stays purple. Writing the palette and the type into a DESIGN.md at the repo root is what stops the next session re-deriving it from scratch.

Look

This is the step everyone skips, and it is the one that catches the problems. Describing what a page “should” look like is not a check. Take the screenshots, open them, compare them to the plan.

Capture the matrix

bash scripts/setup.sh        # once, installs Playwright and Chromium

node scripts/capture.js http://localhost:3000 ./shots \
  --widths 390,768,1440 --full

Three widths, 390 for a phone, 768 for a tablet, 1440 for a laptop, in light and dark, plus a reduced-motion frame. Alongside the images you get a report: console errors, horizontal overflow at each width, tap targets under 44px, images with no dimensions, how many em-dashes are visible, and how many eyebrows there are against how many sections. If you have Playwright installed already, the CLI or the MCP server does the same job.

Then fix in this order, because a spacing fix is wasted when the layout is wrong: structure, then alignment and widths, then spacing, then type size and weight, then colour, then the details. Two or three rounds is normal. Stop when what is left is font rendering.

The gate: no console errors, no sideways scroll at any width, and it looks like the plan in both colour schemes.

Free, and it runs offline

Get the ax-frontend skill

The whole loop as one Claude Code skill: the design read, the rules, the screenshot script, the pre-flight. Sourced from Taste Skill, Vercel's Web Interface Guidelines, awesome-design-md, screenshot-to-code and Playwright, with the licences inside. I email you the zip.

Where this comes from

None of it is mine from scratch. It is five published sets of rules merged into one loop, with the scripts and the pre-flight written around them. Read the originals: they are all worth an hour.

Taste Skill by Leonxlnx, MIT. The design read, the three dials, the hard layout rules and the list of tells.
Web Interface Guidelines by Vercel, MIT. The interface floor, vendored as it is written.
awesome-design-md by VoltAgent, MIT. The DESIGN.md convention and its schema.
screenshot-to-code by OneWave-AI, MIT. Spec before code, then render and compare, and the order to fix things in.
Playwright CLI and MCP by Microsoft, Apache-2.0. The browser that takes the screenshots.
The frontend-design skill by Anthropic, Apache-2.0. The plan-then-self-check pass and the calibration list of current defaults.

The Apache-2.0 ones are used as guidance and command references, no source files copied. The MIT ones are quoted and adapted with attribution. All of it is in SOURCES.md inside the zip.

Skills are level five of the map: the point where you stop re-explaining how you work and the procedure lives in a file. If you are still setting the machine up, start with Claude Code.