Back to Home
AI Development

How to Get AI Coding Tools to Build UI That Doesn't Look AI-Generated

Commit tokens and a component list before you generate, direct by element and property, use reference images and a screenshot loop. The workflow, not prompts.

13Labs Team11 August 202610 min read
UIdesign systemsdesign tokensAI coding toolspromptingshadcn

Contents

What actually stops AI tools producing generic UI?

Commit a theme, a token file and a fixed list of components to the repo before you generate a single screen, then direct changes by named element and named property instead of by adjective. What is already committed in the codebase beats anything you can put in a prompt. This is the most requested topic among builders at 13Labs buildDays in Melbourne. Liz described it precisely: "When I use AI, my designs (UI interfaces) look generic and AI generated. I'd love to know how to improve my workflow or prompting to achieve more human looking designs." Miles wanted the same thing in six words: "UX / UI not looking like slop." Astha named where it costs her time: "I think when I am building software with AI, I always get stuck in making the UI or layout perfect." The gap between speed and confidence is general. Figma's 2025 AI Report found 78% of respondents agree AI significantly enhances the efficiency of their work, while only 32% say they can rely on its output. One boundary before the workflow. Why generated interfaces converge on one look, and what a generated screen is missing underneath the surface, is covered in our guide on what the generated interface is actually missing. This guide is only the way out of it.

Why commit a theme and design tokens before you generate anything?

Because the agent reads your CSS variables and reuses the values it finds there. A committed theme changes every screen generated afterwards. A prompt only changes the screen in front of you. shadcn/ui, the component set most generation tools are trained hardest on, states the mechanism in its theming documentation: "We use and recommend CSS variables for theming." The token names are fixed (background, foreground, primary, muted, border, radius) and the values are yours. Tailwind CSS 4, released by Adam Wathan and Tailwind Labs on 22 January 2025, moved the same idea into CSS with the @theme directive: "Tailwind CSS v4.0 takes all of your design tokens and makes them available as CSS variables by default." Most teams already have tokens and never connect them to the tool doing the generating. zeroheight's Design Systems Report 2026 found 86% of design systems include design tokens, but only 40% have any token automation, leaving 60% manually syncing values between design, documentation and code (zeroheight, sample of 147 practitioners). The Design Tokens Community Group published the first stable version of its interchange format, 2025.10, on 28 October 2025, which is what makes that sync automatable. Where the file sits matters more than people expect. Lovable's design systems documentation only treats src/index.css, src/styles/tokens.css, a Tailwind config or a theme source as the token source, and says plainly that "component-local stylesheets buried deeper in the tree are not treated as the token source". Put your tokens elsewhere and the tool will not read them. One more move separates a themed default from something recognisable. Changing colour values alone leaves the same silhouette behind. shadcn made the point releasing the Luma style on 31 March 2026: "Like the other new styles, Luma goes beyond theming. It changes the geometry, spacing, and feel of the components so your app starts from a different visual baseline." Radius, density and type scale carry more of the recognisable look than the palette does.

How do you stop the agent inventing its own components?

Give it a closed list of components it is allowed to import, and publish that list as something machine-readable rather than a sentence in a prompt. Brad Frost, author of Atomic Design, draws the line here: "This is what distinguishes DS+AI from vibe coding; the AI is deliberately constrained to using the high-quality design system materials to ensure what's being generated adheres to the organization's established standards." - Brad Frost, Agentic Design Systems in 2026, 16 December 2025. The practical mechanism in 2026 is a registry. shadcn's components.json accepts a registries block pointing at your own URL and namespace, so installing a component pulls your button rather than the default one. Will Sather of Vercel described why this beats written instructions: "Registries let you define and share branded components and blocks in a format models can use" (Vercel, 22 August 2025). This is worth doing even if you have never published a package, because the defaults are what everyone else starts from too. The shadcn/ui repository passed 121,000 GitHub stars by 11 August 2026, and its command line tool was pulled 7.8 million times in the week to 9 August 2026. An untouched install is a look you share with a very large number of other products. Tokens on their own do not get you there. Surendar Selvaraj, a senior UI/UX architect writing in Design Systems Collective on 20 May 2026, described the failure exactly: "It saw our tokens. It built components. They looked right. They were wrong." His agent had built a card with a hardcoded action div instead of the ButtonPrimary component, and an input with a raw HTML element instead of FormField. So write the prohibitions down as well as the permissions. No raw hex values, no text-white or bg-black, no one-off spacing values, import only from your own components directory. Lovable's own adherence scanner checks for those same three things, which is a reasonable signal that they are the three that break.

Why does "make it look better" fail, and what works instead?

Because a general instruction returns a general answer, and the general answer is the default. Direction that changes the output names an element, a property and a value. John Phamous of Vercel wrote the most usable version of this rule while describing how Vercel teaches its own agents product design: "Avoid starting with broad adjectives like clear, polished, or intuitive. Agents need observable decisions. Destructive actions use Verb + Noun is usable. Buttons should be clear is not." - John Phamous, Vercel, 25 June 2026. Anthropic's Claude Code memory documentation says the same about anything you commit as a rule: write instructions "concrete enough to verify", preferring "Use 2-space indentation" over "Format code properly". It also carries a warning worth reading before you trust a markdown file to hold the line: those instructions are context, not enforcement, and "there's no guarantee of strict compliance, especially for vague or conflicting instructions". Three levels of direction, in increasing order of reliability: - Named reference plus named dimension. Match the density and hierarchy of a specific product's sidebar, rather than asking for premium. - Named element plus named property plus value. Add 16px of bottom margin to the submit button, rather than asking it to fix the spacing. - Named exclusions. No gradient hero sections, no drop shadows, borders only. The middle one is what Ryan, another buildDay registrant, was asking for when he wrote that he wanted help with "specific ui changes in react native". React Native gives you no browser inspector to point at, so naming the component and the style property is the whole technique rather than a refinement of it.

How much does a reference image actually change the output?

Enough that it is the cheapest single change on this list. A reference image moves the starting point away from the model's defaults in a way that no amount of description manages. Every major tool accepts them. Lovable's documentation is direct about the purpose: "Attachments show Lovable what you mean. Attach a design mockup to match, a screenshot of a bug to fix, or a document to build from." Cursor's prompting documentation lists the same use: "Attach images to your prompt to provide visual context for UI work, debugging, and design implementation." The closest thing to a measurement is Design2Code, by Chenglei Si and colleagues at Stanford's SALT Lab, accepted to NAACL 2025. Across 484 real webpages with human evaluation on 100 of them, 49% of GPT-4V generations were judged able to replace the reference page on visual appearance and content, and 64% were judged better than the original page. The paper's own caveat is the useful half: models "mostly lag in recalling visual elements from the input webpages and generating correct layout designs". Read that as images buying you the feel, not the layout. Two rules follow. First, feed the image rather than your description of the image, because writing a paragraph about a design you like and asking a model to rebuild from the paragraph loses information twice. Second, say which dimension of the reference you want. Match this spacing and colour weight but not the layout is a usable instruction. Make it like this produces a poor tracing. The same paper measured two techniques that beat direct prompting: extracting the text elements first, and self-revision, where the model compares its own output against the reference and iterates. That second one is the next section.

How do you get the agent to check its own work visually?

Give it a way to take a screenshot, then ask it to compare that screenshot against the reference and list the differences before fixing any of them. The listing step is what stops it declaring victory. Anthropic published this loop in Claude Code: Best practices for agentic coding on 18 April 2025. Give Claude a way to take browser screenshots, give it a visual mock, ask it to implement the design, screenshot the result and iterate until the result matches. Its estimate of how long that takes is the only vendor figure on record: "Like humans, Claude's outputs tend to improve significantly with iteration. While the first version might be good, after 2-3 iterations it will typically look much better." The 2026 rewrite of the same documentation reframes the loop as verification, and its before-and-after table is this whole guide in two lines. Before: "make the dashboard look better". After: "[paste screenshot] implement this design. take a screenshot of the result and compare it to the original. list differences and fix them". The tooling caught up during 2025. Cursor gave its agent browser access in version 1.7 on 29 September 2025 and made it generally available in 2.0 on 29 October 2025, noting that screenshots are wired into the file reading tool "so Agent actually sees the browser state as images rather than relying on text descriptions". A Playwright MCP server does the same job for any agent that supports MCP. Luca Becker, writing on 20 October 2025 after wiring one into his own setup, reported that "tasks that used to take 10-15 frustrating iterations now get done in 2-3", though that is one practitioner counting rather than a study.

How do you hand a designer's decisions to an agent?

Through structured design data rather than a picture of the design file. Figma's MCP server and Code Connect exist to pass components, variables and styles to a coding agent as data it can read. Jake Albaugh of Figma described the point when the Dev Mode MCP server entered beta on 4 June 2025: it brings outside context into the workflow "so your code doesn't just match the fingerprint of your codebase, but that of your design, too". The server reached general availability on 28 October 2025. Code Connect, generally available since Config on 26 June 2024, is the part that matters most here, because it maps your real component code to your Figma components so the agent returns your Button rather than a generic div. Whether any of it works depends on the design file, not the agent. Christine Vallaure, founder of moonlearning.io, wrote the test as one line in UX Collective on 31 March 2026: "A frame with auto layout and token-based spacing is a description. A frame with manually placed elements and hardcoded values is a picture." Figma's own analysis, cited by Builder.io on 13 March 2024, found design tokens and components make up on average 85% of a single design file, which is why file hygiene decides how much survives the handoff. The direction of travel is settled enough to plan around. Vercel's v0 changelog on 31 July 2026 replaced its Figma import step outright: connect a file and v0 "reads its structure and styles directly while building, instead of the older import-and-screenshot step". Structured design data going in, screenshots coming back out as the check.

What order should you run this workflow in?

Theme first, components second, written decisions third, references fourth, screenshots last. Running it out of order means regenerating screens you have already reviewed. - 1. Commit the theme. Set colour, radius, spacing and type scale as CSS variables in the file your tool actually reads, and change the geometry, not only the palette. - 2. Fix the component list. Publish or register your components so the agent installs them, and write the prohibitions next to the permissions. - 3. Write down decisions, not preferences. A short file of observable rules beats a long file of adjectives. Anthropic suggests keeping such files under 200 lines, because longer ones "consume more context and reduce adherence". - 4. Generate one component at a time. Ask for structure first and treat the first output as a wireframe rather than a deliverable. - 5. Attach a reference and name the dimension you want from it. - 6. Close the loop with screenshots, and ask for the list of differences before any fix. - 7. Run a separate pass for type scale, spacing rhythm and colour weight. Those three carry most of the default look and they are almost impossible to see while you are still fixing layout. Youyi, at the same Melbourne event, described the underlying question as "the adaptation relationship between functions and UI". The order above is the answer to it: decide the visual system once, then let each new function inherit it, rather than making fresh visual decisions on every screen. Leeling, asked what they wanted to build, answered "Tools to improve my design workflow". That instinct is right. The workflow is the deliverable, and the interface is what falls out of it.

Frequently asked questions

Can I fix a generic-looking interface with a better prompt? Only partly. Prompts change one screen; a committed theme and a fixed component list change every screen generated afterwards. Vercel's John Phamous puts the practical version of the rule as agents needing observable decisions rather than broad adjectives (Vercel, 25 June 2026). Where do design tokens have to live for an AI tool to find them? In a top-level styling file. Lovable's documentation reads src/index.css, src/styles/tokens.css, a Tailwind config or a theme source, and explicitly does not treat component-local stylesheets deeper in the tree as the token source. shadcn/ui uses CSS variables for the same reason. Does changing the colour palette stop the AI look? No. Radius, density and type scale carry more of it than colour does. shadcn's own framing when shipping the Luma style on 31 March 2026 was that a new style has to change "the geometry, spacing, and feel of the components", not just the theme values. How many rounds of screenshot feedback does it usually take? Anthropic's Claude Code guidance says outputs typically look much better after 2 to 3 iterations (18 April 2025), and one practitioner, Luca Becker, reported dropping from 10 to 15 iterations to 2 to 3 after adding a Playwright screenshot loop (20 October 2025). Both are estimates, not measured studies. What is the best way to give an agent a designer's work? Structured design data, not a screenshot of the design file. Figma's MCP server reached general availability on 28 October 2025 and Code Connect maps your real component code to Figma components, so the agent returns your components. It only works if the file uses auto layout and token-based spacing rather than hardcoded values.

Get your own project past the default look

buildAcademy is a small live Melbourne cohort where you set up a theme, a component vocabulary and a screenshot feedback loop on your own build, with someone who has shipped interfaces to real users.

See buildAcademy