
Walid Boulanouar on Stitch, Figma, and the UI Loop
Breakdown of Walid Boulanouar's Stitch-to-Figma workflow and how AI prompts plus iterations can produce polished UI fast for teams.
Walid Boulanouar recently shared something that caught my attention: "stitch just added export to figma… now you can use stitch mcp from claude, codex, cursor...." Then he lays out a simple loop: generate an app, export to Figma, refine details, push changes back with Figma MCP, and repeat.
He even captures the emotional truth of UI iteration with a line that every builder recognizes: "iterate again and again ( you know i hate this, i hate this x10 times.... change a small border radius... then wow this is cool)." That combination of frustration and delight is basically product design in one sentence.
What Walid is pointing at is bigger than a new export button. It is a workflow shift: using AI generation for speed, Figma for precision, and an agent-friendly bridge (MCP) to keep the loop tight.
The core idea: prompts get you 80 percent, iteration gets you shipped
When people talk about "AI-generated apps," they often mean a single prompt that spits out a UI and some code. In practice, that is rarely shippable. The real work is in the second and third passes: spacing, typography rhythm, consistent components, states, responsiveness, and all the small things users feel instantly.
Walid's loop acknowledges that reality:
- Use Stitch (via MCP in Claude, Codex, Cursor, and similar tools) to generate a starting point fast.
- Export to Figma because that is where design review and pixel-level refinement actually happen.
- Iterate until it looks like it "took weeks to design," even if it was mostly prompts and cycles.
- Push updates back through Figma MCP and keep moving.
Key insight: the magic is not a single generation. The magic is a tight feedback loop between generation and a professional design surface.
What is MCP and why it matters here
MCP (Model Context Protocol) is basically a standard way for AI tools to connect to external apps and data sources. In this context, it means your AI assistant can interact with Stitch and Figma in a structured way, rather than you copying assets, naming layers manually, or re-implementing design tweaks in code by hand.
You can think of it like this:
- Without MCP: AI generates something, then humans do a lot of manual translation between tools.
- With MCP: AI can move artifacts between tools and operate inside the workflow, which reduces friction and makes iteration cheap.
When iteration becomes cheap, you do more of it. When you do more of it, quality goes up.
Why exporting to Figma changes the game
Walid's point about exporting to Figma is subtle but important. Figma is not just a place to "make it pretty." It is where teams align.
Three practical reasons this matters:
1) Design critique works in Figma
Stakeholders know how to comment, compare options, and discuss UI in Figma. It is the common language. A generated UI that stays inside an AI tool often cannot receive real feedback in a way teams trust.
2) Systems live in Figma
If you have a design system, tokens, components, variants, and interaction patterns are usually defined or at least documented in Figma. Exporting there lets you map generated output onto your system instead of inventing a new one accidentally.
3) Precision is faster in a design surface
This is where Walid's "border radius" example hits. In code, tiny visual tweaks can be slow and annoying. In Figma, you can adjust 8 to 10, see the effect instantly, and keep going. The goal is not to avoid iteration, it is to make iteration painless.
A realistic Stitch-to-Figma-to-code loop (and where people mess it up)
Here is a concrete version of the loop Walid described, expanded into something you can run with a team.
Step 1: Generate a first pass UI with Stitch
Prompt for structure, not perfection. Ask for:
- IA and navigation (screens, routes)
- Component breakdown (cards, tables, forms)
- States (loading, empty, error)
- Accessibility basics (contrast targets, focus states)
If you try to perfect style in prompt one, you will waste time. Get a solid skeleton.
Step 2: Export to Figma and normalize
In Figma, do the unglamorous cleanup that makes later work easier:
- Apply a type scale (for example 12-14-16-20-24)
- Align spacing to an 8-point system
- Replace one-off buttons with components
- Rename frames and components consistently
This is where "weeks to design" starts to look real, because polish is consistency.
Step 3: Iterate like a designer, not like a lottery ticket
Walid calls out the repetitive nature of this: iterate again and again. The trick is to iterate with a checklist so you do not spin:
- Does every screen have a clear primary action?
- Are forms usable on keyboard only?
- Do lists have empty states and pagination behavior?
- Are component variants covered (hover, disabled, selected)?
Small tweaks add up, but only if they are systematic.
Step 4: Push changes back with Figma MCP
This is the part that can compress timelines. Instead of re-coding every visual refinement manually, you use an agent-assisted bridge to translate design changes back into the implementation.
The ideal outcome:
- Figma remains the source of truth for UI intent.
- Code reflects that intent quickly.
- The AI assistant handles the boring translation steps.
Step 5: Repeat until the UI feels inevitable
The best products feel "obvious" when you use them. That feeling comes from a dozen rounds of minor improvements. A tight loop makes those rounds feasible.
The benefits are real, but there are a few traps
Walid is optimistic, and I agree with the direction. But if you are going to adopt this loop, watch for these pitfalls.
Pitfall 1: Drifting away from a design system
If each iteration creates new components, you will end up with UI entropy. Fix by anchoring everything to tokens and component libraries early.
Pitfall 2: Shipping pretty mockups, not usable products
Figma polish can hide missing behaviors. Make sure you validate:
- Responsiveness (multiple breakpoints)
- Real data (long names, zero states, edge cases)
- Performance and accessibility in the actual app
Pitfall 3: Over-iterating the wrong thing
The border radius joke is funny because it is true. But not every tweak matters. Timebox visual iteration and prioritize changes that improve clarity, hierarchy, and task completion.
If iteration is cheap, the new skill is choosing what not to iterate on.
Why this also explains viral AI-builder content
Walid's post works because it compresses a complex idea into a loop you can picture. It is actionable, tool-specific, and emotionally honest about the grind of iteration.
If you create content about AI and product building, this is a strong pattern:
- Show a workflow, not a feature.
- Name the tools people already use.
- Describe the loop in plain language.
- Include a relatable pain point, then the payoff.
That is exactly what Walid did: "then you will get an app that looks like it took weeks to design but it is just prompts and iterations." It is aspirational, but also grounded.
A practical takeaway: design velocity is now an interface problem
The bigger story here is that product speed increasingly depends on how well your tools connect. Stitch exporting to Figma, plus MCP bridges back to implementation, turns design and code into a continuous cycle.
If you are building with AI assistants, the question to ask is not "Can it generate a UI?" The question is "Can I iterate with minimal friction across the tools my team already trusts?" Walid's loop is a clear yes.
This blog post expands on a viral LinkedIn post by Walid Boulanouar, get one engineer with swarm of agents | aiCTO ay automate & humanoidz | building with n8n, a2a, cursor & ☕ | advisor | first ai agents talent recruiter. View the original LinkedIn post →