AI tools for UI development are everywhere now. Cursor, Claude, v0, Bolt, Fusion - everyone's got an AI coding assistant. But too many people are using them like a drunk person uses a lamp post: for support rather than illumination.
The usual cycle goes like this: throw a half-baked prompt at the AI, get code that doesn't work, curse the AI gods, repeat until you give up and write it yourself anyway.
AI-assisted UI development doesn't have to suck. The difference between AI that helps and AI that wastes your time and money comes down to the context you give it.
I'm not going to bore you with academic stuff like chain-of-thought prompting or multi-shot techniques. The latest agents with reasoning handle that automatically. This is about the practical stuff that actually makes a difference in day-to-day development.
Here are the tricks that I've found actually work.
1. use screenshots
This is one of the biggest things I see people neglecting to do, and it bothers me to no end. You tell an AI tool to "fix the layout" or "make it look better", but it can't see what you're looking at. It's working blind, like a designer trying to fix your website over the phone.
The specific type of screenshot I'm talking about here is screenshotting the UI that the AI just rendered. The AI might think it nailed it, but when you're using a design systems or any custom components, you need to show it what it actually gave you. It might realize "oops, that's not what I was going for"
This is especially helpful if you already have a screenshot of what you wanted (maybe from Figma or another app), so the AI has a clear comparison: what you're going for vs what you've got.
I just use Command+Shift+4 on Mac to quickly grab a screenshot, which puts it in my clipboard, then paste it right into the chat. Super simple workflow, but it makes a huge difference.
2. provide (the right) system instructions
Tell the AI how you want to write code. Most codebases are a mix of styles - some old patterns, some new ones, some random stuff from different developers who apparently learned React from TikTok videos. AI tools don't magically know which approach you prefer.
Here's how to set this up effectively:
- Point to good examples. You probably have a variety of code in your codebase - some newer, more modern stuff that follows practices you like, and some legacy code using older approaches you don't want to replicate (looking at you, jQuery). Point the AI at specific file paths that reflect how you want to code. "Here's a good example of using our React components. Here's how we handle state management. Our accounts page is a really good example of doing everything the modern way."
- Get specific about UI and design systems. Give instructions like "always use our XYZ design system components" or "here's an example of what we did right." You can point it at design system documentation, best practices you've documented, or whatever patterns and examples you want it to follow.
- Create pattern libraries. Some people make a repository or folder that's just good conventional patterns. Like "here's how we do date picker patterns, here's how we do search and filter UIs, here's how we do data grids." These don't have to be actual production code - just good example compositions that the AI can reference when it's trying to build something similar.
We actually have a cool tool within Fusion that indexes your whole repo and automatically generates these kinds of rules. It'll look at your design system and generate "here are the components and here's when you should use each one" to feed to the AI.
Generally speaking, you set these up once and use them forever, but you can tweak them as needed. The goal is to have someone (almost like a "context engineer") set up the right instructions once, then everyone in the company gets better results from prompting.
Then, you basically get a tech lead who never gets tired of explaining the same patterns.
3. give additional context
Connect everything you can: your design system, Storybook, API documentation, and other repos with good patterns.
- Connect your API repo with documentation in Swagger or Markdown format. The AI can use those APIs when building and prototyping instead of making up fake endpoints that return
{ "status": "success", "data": "TODO" }. - Hook up your Storybook. Point the AI at your stories files so it knows how to use your components correctly. I sometimes just list out different components we use and when to use them right in the system instructions.
- Use workspaces. Tools like Cursor and Fusion let you connect additional repositories as context. If you have a separate repo with your design system or documentation, connect it. More context is almost always better.
This is especially important if you're building something new. AI struggles when you have no examples of your coding standards, no component library, and no patterns to follow.
The key is organization - you don't want to overwhelm the AI with too much context without guidance, but you want it to have access to the patterns and components that matter for what you're building.
4. show it the errors
When you get errors in your terminal or browser console, don't try to fix them yourself first. Just feed the errors to the AI like you're feeding a debugging duck.
Whether you're using Claude Code or Cursor, just open up your browser, grab the error from the JavaScript console, and paste it back. Or copy the error from your terminal and paste it in. Usually you can just paste it and hit enter - the AI figures out you want to fix the error rather than frame it on your wall.
Some tools make this even easier. In Fusion, the tool automatically detects errors and lets you hit a button to fix them. It will pass the error and a host of other context from the browser to the AI, like additional console errors, network errors, server errors, plus the currently rendered content on screen with the specific components and their exact file paths.
5. connect your design tools
You really have two main options here: basic Figma MCP or something more advanced like the Builder.io Figma plugin.
For simple cases with tools like Cursor: You can use the Figma MCP - just paste Figma links and get some degree of detail more than screenshots. At least you'll get exact fonts, colors, and spacing instead of the AI guessing your brand colors are "blue-ish".
For better results: Use Builder's Figma plugin if you want something that works right in the browser with a deeper understanding of your design systems and design tokens.
If you want to take things even further, use the bidirectional sync abilities of the Figma plugin. Say you generate a new page from scratch and it looks good, but you want to tweak the design. You can copy the generated UI, paste it into the Builder plugin in Figma, make your edits (change color scheme, remove elements, whatever), then copy it back and say "apply my design changes from Figma."
This is especially powerful because the AI understands your design system context. When you make changes in Figma using your design tokens, they translate to the right tokens in the code. No more "why the ** is this arial" situations.
6. use visual selection
This only works in tools that have a visual layer (so not Cursor, but tools like v0 or Fusion). You can select UI elements directly.
If you want to add a new tab and there are multiple tab components on screen, just select the tabs you're talking about. Select the general area you want to edit. Say "add a tab here" and it knows exactly what you mean.
Way more precise than trying to describe which tabs you're referring to. It's the difference between "add a tab to the navigation at the top" versus just clicking on the nav and saying "add a tab." Like the difference between giving directions over slack versus just pointing.
7. connect your tickets
Hook up Linear, Jira, whatever project management hellscape you use. Paste the ticket into your prompt and say "fix this."
The ticket context helps the AI understand not just what to build, but why you're building it. That leads to better decisions about implementation details. Plus you don't have to re-explain the entire context of why this button needs to be purple and why the stakeholder's opinion about purple buttons matters.
Plus you can preview the changes, mess around with them, and iterate before you actually ship anything. Much better than building something and then realizing it doesn't actually solve the problem described in the ticket (or worse, realizing the ticket made no sense in the first place).
8. prototype in your actual stack
This is a big one for me. It's become popular to do "vibe coding" - just throw designers at a vibe coding tool because it's way more productive than Figma. And honestly, Figma's AI just isn't very good. If you want people to type prompts and generate UIs and ideas and multiple versions, traditional design tools suck at this harder than a broken vacuum cleaner.
So people jump to vibe coding products. The problem is they're not using your tech stack or design system, so they don't follow any of your conventions. You can try to fake it, but its an uphill battle.
First, your prototype won't be accurate. The look, hover states, focus states, components - everything's just a little off because it's not using your actual design system. It's like booking a cover band instead of the actual artist - not going to impress your boss as much.
Second, this doesn't help your development process at all. Everything has to get rebuilt anyway because it's not following any of the standards or conventions you need. All that time you spent polishing pixels? Doesn’t matter, its getting thrown away anyway and getting rebuilt by Bob the aesthetically-impaired developer.
When you build with your actual stack - using something like Fusion or Cursor with your real repository - you're generating code that is actually your code. These tools look at your other files, how you format code, what libraries you use, what components you use and how you use them. So all of that hard work can upgrade to directly to production, and even at the prototype stage things are actually pixel perfect to what end users will ultimately see and get.
Setting up smooth prototyping workflows:
For developers, you can use Cursor connected to your real repository. For non-developers, Fusion runs right in the browser with a visual development environment.
You can also use workspaces to provide a separate repo if you want a sandbox for prototyping. Connect a different repo and give instructions like "write code like we do in this repo, use components like we do in this repo, but save everything in this separate sandbox."
The payoff can be significant**.** We prototype using real data, real user flows, the actual codebase. About 70% of the time we just merge the prototype as-is, maybe behind a feature flag.
9. give feedback constantly
Don't expect perfect results from one prompt. AI works way better when you iterate. Treat it like a really fast intern who doesn't get offended when you tell them their first attempt missed the mark.
Be specific with feedback. Don't just say "this looks bad" or "this doesn't work right." Say exactly what you don't like. If you're using a tool with a visual interface like Fusion, you can point and click on something and say "I don't like how this looks, give me 3 alternative options."
Use screenshots as reminders: "Here's a screenshot of what I'm looking for, here's a screenshot of what you provided." You can link to screenshots from other products too: "I was looking for a table more like this - here's HubSpot's CRM table."
Don't be vague. Instead of "the table grid is not quite right," say "when I click this button, it's supposed to open a modal but instead nothing is happening", or if your tool has a visual editor (e.g. Fusion’s can plug into other tools like Cursor too) you can pick precise values yourself as well.
The single-shot "make it perfect" approach doesn't work. Think of it more like pair programming - you go back and forth until you get what you want. Except your pair programming partner never needs bathroom breaks and thinks you’re always right (even when questionable).
10. ask for multiple variations
I often say "give me three variations" instead of asking for one perfect solution.
Different ways to manage variations:
Sometimes I have the AI add little temporary UI with different tabs so I can flip between options. Sometimes I ask for a debug overlay that lets me toggle between variations - I can switch to variation one, try out the flows, then switch to variation two and test that.
A kewl approach: In tools like Fusion, you can create infinite branches in parallel. Open 10 different browser tabs, create 10 different branches, and give completely different prompts. You have all your versions live, you can send them out for feedback, you can try them in parallel. This can be a lot nicer than trying to manage variations in tools like Cursor where it's difficult to have different versions running in one working tree.
You don't have to be a UX expert to know what feels good versus what doesn't. Let the AI generate options, then pick the one that works. You get your own personal focus group that doesn't eat all your snacks.
11. split the work appropriately
Don't try to make everything pixel-perfect if design isn't your expertise. Get it close, then hand it off to a designer to pick things up from there.
The cool thing about AI making code more accessible is that designers can now jump in and tweak things directly. They can reference the original design, make manual adjustments, and treat code more like Figma.
On the flip side, it can be frustrating as a designer to put extreme detail into a design, only to have a lot of those details get lost in development. It can feel like commissioning a portrait and getting back a stick figure.
But when you're actually editing in code, all that detail work makes it to production users. Unlike tools like Figma, which is at best a set of suggestions, you're editing actual code. Every padding adjustment, every margin tweak becomes part of the production codebase.
Common workflows that work:
- Designer-led implementation: The designer does full end-to-end implementation of new UI (just the UI, not all the functionality). They create a branch in Fusion, create the UX update, test it out, make sure it's perfect, then send a pull request. Developers review, modify, and merge.
- Developer first pass, designer polish: Developer does the first pass getting all the pieces working, creates a pull request, then a designer picks up from there and does fine-tuning. Instead of redlines (which are super annoying and make everyone's life worse), the designer goes in and makes all the detailed tweaks hands-on using the visual editor.
We even have product managers jump in to check things like tracking events. They'll prompt to add missing analytics: "what tracking events should we have here?" and add the ones that are missing.
keep experimenting
AI tools are changing fast. Stuff that didn't work six months ago might work great now. Claude is pretty killer, Cursor keeps getting better, new tools are popping up constantly.
The biggest pitfall I see: Trying to let AI do too much. People get stuck spinning their wheels - "why didn't the AI do what I wanted? I keep telling it to make this better and it's not getting better." It's like expecting your GPS to also fix your car when it breaks down.
Always remember you want an engineer in the process. If you're not an engineer yourself and you're trying to build something, get an engineer involved. They can usually find what's wrong and unblock you. Coding knowledge, whether it's you or someone else on your team, is always valuable.
The trick is finding the right collaboration workflow where designers, developers, and product managers can work in a shared environment and language.
The patterns above are what work for me right now. But the specific tools and techniques will keep evolving. The important thing is giving AI the context it needs to actually help instead of just generating code that looks right but breaks the moment someone clicks a button.
