How to make AI models generate beautiful web UIs

Why default AI UI looks mediocre

If you ask a frontier model to "build me a landing page," you will get something centered, safe, and forgettable. That is not because the model lacks taste. It is because the prompt gave it nothing to aim for. Models average over their training data. Without constraints, that average is the median of a million bootstrapped demos.

The fix is almost always the same. Reduce the search space. Give the model a vocabulary, a reference, and a stack. The less you leave to imagination, the more the output looks designed rather than generated.

Step 1: Write a design system spec

A design system spec is a short block of instructions that names the visual vocabulary. It does not need to be elaborate. Ten lines usually does it. A good spec covers:

• Typography (one sans for UI, one display for headings)
• Color tokens (background, surface, text, accent, border)
• Spacing scale (4, 8, 16, 24, 32, 48, 64)
• Border radius (pick one: sharp, medium, pill)
• Shadow style (flat, subtle, layered)
• Density (compact, comfortable, spacious)

Every item removes a decision the model would otherwise guess at. The spec is also reusable. Save it as a snippet and paste it into the top of every UI prompt you write for a given project.

Step 2: Attach a screenshot reference

Text descriptions of layout are lossy. "A clean SaaS dashboard with a sidebar and a main content area" can produce a thousand different outputs. A single screenshot of Linear, Height, or Vercel collapses that space immediately. The model copies the hierarchy, the density, and the proportions that words cannot carry.

When you paste a reference, tell the model what to take and what to ignore. Take: grid, spacing, component types, type scale. Ignore: brand, copy, exact colors. Otherwise the model may try to faithfully reproduce the reference down to the product name, which you do not want.

Multiple references work well too. Feed two or three screenshots and ask the model to blend their layout choices. This is how human designers work, and frontier models handle it fine.

Step 3: Name a component library

Ask for shadcn/ui, Radix primitives, Mantine, or Chakra by name. Do not hand wave about "nicely styled buttons." Models have seen these libraries in training data and know their API surface well. When you name one, the model produces cleaner markup with fewer fabricated props.

shadcn/ui is a particularly good pick right now because it is Tailwind based and component level (copy paste rather than installable), which means Claude and GPT models reproduce it accurately without needing a specific version lock. The combination of Radix behavior with Tailwind tokens gives you accessible components that look consistent by construction.

Pair the library with an iconset. Lucide works well with shadcn. Just asking for "an icon" is underspecified. Asking for "a Lucide LayoutGrid icon at size 16" is not.

Step 4: Constrain the stack

Every degree of freedom is a chance for the model to wander. Pin the framework, the styling system, the typography source, and the router. For a modern web app, a good default is Next or Vite React, Tailwind, shadcn/ui, Lucide icons, and Inter or a similar system font.

Constraints are not a cage. You can always break them for a specific screen. But without a baseline, each generation starts from nothing and the results drift. With a baseline, the model spends its effort on what you actually care about (layout, copy, hierarchy) instead of rehashing stack choices every turn.

Step 5: Iterate on the rendered page, not the code

The single biggest quality lever is this: review the output in a browser, not in a code diff. Take a screenshot of what rendered, paste it back with specific feedback ("the hero feels top heavy, shrink the headline by a step and tighten leading"), and let the model adjust. This matches how design review works with humans. It works with AI for the same reason.

The iteration loop is where builders diverge. If you copy code into your local project, run it, screenshot it, and paste back, each turn costs you minutes. If your builder has a browser attached to the sandbox and screenshots are one click, each turn costs you seconds. That difference compounds across a session.

How mk0r handles this by default

mk0r is one option in the category. Its angle on UI quality is to bake the constraints into the scaffold so the user does not have to write them. Every VM session starts with Tailwind, shadcn components, Lucide icons, and a Vite React layout already wired up. The system prompt names that stack, so the model writes against it instead of choosing one.

The other piece is the render loop. Because each session includes a Chromium instance running through Chrome DevTools Protocol, the agent can render the page, inspect the DOM, and read layout metrics before handing the result back. For a UI prompt, this means obvious problems (overlap, empty states, broken imports) get caught automatically. It does not replace a human design review, but it removes the low hanging failure modes.

A prompt you can steal

Here is a compact prompt pattern that pulls all of the above together. Paste it at the top of your UI prompts and adjust the placeholders.

Adjust the tokens to taste, but keep the structure. The model does not need poetry. It needs a vocabulary.

How to prompt AI for beautiful web UIs