Cerebras：如何用 AI 生成漂亮的 UI

May 08 2026

With contributions from Sherif Cherfa and Halley Chang

There’s an intuitive skepticism we have toward AI-generated work. We see it clearly in writing, where the patterns have gotten familiar and punctuation (the em dash — ) has become a universal signal that AI has been used. Design has lagged behind writing, but it’s catching up. Recent models can produce better UIs, yet it still requires heavy hand-holding and prompt “band-aids.” Overall, AI-generated designs often lack that feeling of deep satisfaction, joy, or whimsy that human designers create.

Media theorist Marshall McLuhan is often credited for his beliefs on the co-evolution of humans and tools: “we shape our tools, and thereafter our tools shape us.” Although AI can create superficially “beautiful” designs, they’re often shallow. When you give a model a generic prompt, you get a generic output. When your intentions lack direction, so will the result.

For example, here’s a basic prompt we used: "Hello! I want you to build me a website for my computer parts recommendation business, it should look nice, use dark mode."

What we get is boring and predictable:

We see patterns in AI outputs much like we see patterns in writing. There are even guides, Signs of AI Writing that flag it. While testing generic prompts, we similarly developed a checklist of common AI-design “tells”:

Despite these issues, meaningful advancements make AI-generated UI feel less like a gimmick and more like a viable starting point.

Faster generation means faster iteration. When a round-trip prompt to result takes 30 seconds instead of 3 minutes, you committed too early and corrected too late. Now, with systems like Codex-Spark running at ~1,200 tokens/sec on Cerebras, the loop tightens. You can probe, discard, and refine in quick succession.

Vision models let you show, not just describe. Now your model can actually see what it's building and can use that updated information to self-iterate and better understand its progress.

Better tooling around design systems. Tools like shadcn/ui, Figma MCP integrations, and standardized design tokens give models constraints to operate within. There's now actual infrastructure for giving AI something to work with rather than making it invent a design from scratch.

Whether you’re in a creative role or not, intention-setting matters when using AI tools to generate visuals. The most meaningful AI-assisted designs use AI to fill gaps in your skills and weaknesses and develop the projects that you want to create.

We learned that rather than treating AI as a replacement for a designer or the entire design workflow (which creates regurgitated, devoid designs), AI’s full potential pops off when it’s used as an intermediary tool that elevates, reinterprets, and broadens the creative perspective . After all, design at the end of the day is another visual form of problem-solving .

Here are some of the ways we’ve used AI to solve common design problems:

A few years ago we were delighted to code a Snake game or use AI to clone a design. Now with the increasing complexity of what AI models are able to achieve, we’re open to endless possibilities on AI generated designs. Here are our 3 buckets (and 8 practical ways) to generate a beautiful UI.

Run a shadcn preset first.

This sets up the component library with actual source code in the project. Then, the AI can read those components before writing anything, instead of inventing its own.

Most component libraries are a black box. You import them and the AI guesses at the API from training data, which might be stale. shadcn/ui is different: you own the source code, the components live in your project, and the AI can read them before writing anything.

The MCP integration makes this better again. With the shadcn MCP server connected, the model queries the live component registry during your conversation. Ask "add sorting to the data table" and it pulls current docs instead of hallucinating props from six months ago.

Teams using this report components that compile on the first attempt. If you've ever watched an AI spend four iterations fighting its own import paths, you'll care about that.

The worst time to make design decisions is mid-generation. The AI will make them for you and it'll pick whatever is most common in its training data. It could be Inter, sky-blue buttons or rounded cards.

Before you prompt anything, decide: exact hex codes, font stack, spacing scale, general layout logic. Then, encode it somewhere the AI can read like a Tailwind config, a design tokens file, CSS custom properties. designtoken.md has a good format for this.

In terms of naming, it’s also helpful to use intent-based names, not primitive ones. --color-primary beats --color-blue because the model knows what context it belongs in. --color-error stops it from accidentally using your success green on an error state.

Figma's MCP goes further. If you've been designing in Figma with defined components, the AI reads those directly resulting in less guessing.

Create multiple mockups with GPT-Image-2 and provide them as a hint to Codex for higher-quality output. This workflow is extremely effective to prevent wasted tokens and unsatisfactory slop apps, highly recommend!

Tailwind's config file is an enforcement mechanism. If you only define the colors you want, arbitrary hex values get caught by linting. The AI has to use your system, not invent a parallel one. Semantic naming matters:

When the color is called destructive, the AI won't reach for it on a success button. Context encoded in the name. Add a lint rule that forbids arbitrary Tailwind values ( text-[17px] , bg-[#4a9f8c] ) and you've made it structurally hard to go off-script.

"I want it to be dark mode please... and less card/boxes" is a reasonable ask, but it's too vague. The AI removed two cards and called it done.

The better workflow: one small change, open the site in the browser, look at it, say what's specifically off.

"The button needs 4px more padding." "This heading is too light." "The gap between these two sections feels cramped." These are fixable instructions. "Make it look better" is not.

GPT-5.4's vision capabilities make this loop tighter. Take a screenshot, hand it to the model, describe what's wrong visually, get a fix. The render-screenshot-describe-refine loop gets you somewhere faster than any amount of upfront spec writing.

One of the best ways I’ve found to build a style guide is to stop trying to write the whole thing myself. I usually start by giving the model a few anchors: colors I like, screenshots that feel close, maybe a couple of components or websites that have the right texture. But instead of immediately asking it to turn that into a design system, I ask it to interview me first. Especially with fast models, this type of back-and-forth iteration and conversation can be done in seconds. It can also be helpful to leverage the grill-me skill.

This works well because the model is often better at noticing what’s missing than I am. It will ask things like:

Thomas Wiegold’s writeup on frontend-design plugin makes a similar point when it comes to comprehensive style guides: instead of relying on magic tooling, it’s better to force the model to declare purpose, tone, constraints, and differentiation before producing CSS. He also notes that rigid pixel-level specs can make the output technically obedient but visually dead.

One of the most ‘free’ ways to get better design, it to ask for several directions of the graphics before committing to one. Generating five rough variants takes minutes, especially with faster models like Codex Spark. Then, cherry pick the design you like the best, and continue iterating on that version.

For example, you can prompt for distinct approaches with different vibes, layouts, or color palettes. Pick the closest one. Then: "Keep the color palette and typography from that, but try an asymmetric layout." OpenAI calls this out explicitly in their frontend generation guide : generate a mood board first, then commit.

GPT-5.5 can take a screenshot of your rendered UI to double check the results. Or, you can point at the problem instead of describing it in words. For example, instead of "The padding on this button looks wrong" you can feed a screenshot with a circle around it.

Most AI-generated UI looks better than it is because the data is fake. The names are short, the prices line up or the descriptions are all the same length. The empty states never happen and the error states are decorative.

Before asking for polish, give the model hostile data. For example:

This is especially important for AI-generated design because models are very good at making a static screenshot look plausible. They are much worse at designing the weird middle states where real products live.

Left alone, the model will default to the most statistically common version of “nice UI”: dark background, rounded cards, gradient headline, three-column feature grid, Inter, footer.

The best workflows treat the model like a fast, overconfident junior designer you art-direct: choose intent, notice when it’s wrong, and push toward deliberate delight and weirdness. Models are faster, more visual, and better at working inside existing systems. That makes the ceiling much higher than it was a few years ago. But humans still choose what matters most: the feeling and direction. :)

Try Codex-Spark for yourself and share your creations with us on X .

Thank you to Jen Boscacci, Swyx, and Joyce Er for their feedback. Designs by Halley Chang.

Performance comparisons are based on third-party benchmarking or internal testing. Observed inference speed improvements versus GPU-based systems may vary depending on workload, configuration, date and models being tested.

1237 E. Arques Ave Sunnyvale, CA 94085