Most designers install Claude Code, open the terminal, and quietly close it. The capability is right there. The setup is the wall, and nobody hands a designer the other side of it.

This is the other side.

First, what this is. This is Claude Code for design knowledge work: research synthesis, competitor analysis, design systems, specs, and prototypes you think with. It is not for shipping a product to production, and you do not need to know how to code. You point it at the thinking.

Out of the box, Claude Code is built for engineers. The defaults assume you live in a repo, you read a terminal, you know what to allow. A designer wants to point it at a screen and get something real back, and the gap between those two is an afternoon of config nobody wrote down.

Here is what the other side looks like. With my setup, a folder of messy research notes becomes a structured synthesis with the real themes pulled out. A rough flow becomes a clickable prototype I can pressure-test before I commit a pixel. Same designer, same taste, one afternoon of work. The only thing that changed is the config underneath.

I design products used by millions at my day job. I also build apps that four people use. Both taught me the same thing.. the tool stopped being the bottleneck, the setup is. Once Claude Code knows your taste and your stack, it stops improvising and starts shipping the thing you would have built yourself.

Four pieces matter, and the order matters:

• The CLI, installed and configured, so the terminal stops being the scary part.

• A CLAUDE.md that holds your taste and conventions, so it builds like you, not like a generic template.

• The right permissions, so it moves fast without doing something you did not ask for.

• The MCPs that connect it to Figma and the rest of your stack.

Get those four right and Claude Code goes from a clever demo to the tool you open every day.

What you’ll run after this

Once it is set up, these are the workflows I run, and none of them require shipping a line of production code. Two are the ones designers feel most:

• Maintain your design system. Audit it against your own rules, catch the drift, and sync tokens between Figma and code without the manual plumbing.

• Prototype to think with. Turn a written flow into something clickable, on-system, in minutes. Not to ship. To feel it before you commit.

And three more:

• Research synthesis. Raw notes in, the themes and contradictions out, every claim cited.

• Competitor analysis in one prompt. Pull real references for a pattern with the Mobbin MCP, instead of an afternoon of screenshots.

• Pressure-test a spec. Write the PRD, then have it hunt the missing states and edge cases before a single screen exists.

The setup is below, then every one of these with the prompt I run. None of it works until the setup does, so we start there.

Note: this is a setup you maintain, not magic. It will confidently build the wrong thing if your CLAUDE.md is vague, so the rules carry the weight. It does not replace your judgment. It clears the distance between your judgment and the screen.

The full setup is below for paid members: the install and the one setting most people miss, a CLAUDE.md and DESIGN.md starter that carry your taste, the permissions, and the MCPs I run. It is the same pattern behind superdesigner.ai, the reviewer used by design teams at OKX and Grab, stripped to what you need for your own work.

Subscribe now

Read more

It started with a real problem at work.

We had a major product change coming. Key UX flows moving, new UI, brand changes. The kind of thing you cannot judge from a Figma canvas. I needed to feel it. Real gestures, real scroll, the way it actually behaves in your hand.

Figma surfing wasn’t going to tell me that. Figma Make is good, and I use it, but it renders the web and I needed to feel native. Xcode would get me there and lose every designer on my team on the way. I’d been dabbling with Expo on personal apps, so I knew native was reachable. It just wasn’t reachable for a designer who didn’t want to live in an engineering setup.

So I asked a simple question. What if I strip Expo down to the basics, point Claude Code at the folder from a terminal, and just let it run?

A couple of hours later, it worked

After an afternoon poking at Expo with Claude, I had it.

One command opens the iOS Simulator with a welcome screen, ready to prototype. Under 60 seconds and you have a live, real, native prototype running in front of you. As far as I can tell, it’s the first tool that does this.

npm create proto@latest myapp

Then the fun part. You open a new terminal, open Claude Code in the project and start prompting. The screens come to life as you type, thanks to Expo’s hot reload. No canvas. No IDE. You describe what you want and it appears in the Simulator.

cd myapp
claude

Then connect the Figma MCP to Claude and you can build your actual designs straight into the prototype. That’s the moment it clicked for me. Within hours, the product we’d designed was running as a live native prototype I could hold and feel.

I sent it to a few friends to see if it would break

That was the real test. Hand it to other designers and watch what happens.

They got hooked. They started sending me videos of their own prototypes running. That’s when I knew it wasn’t just solving my problem.

npmjs now shows around 2,600 weekly downloads. Turns out a lot of folks needed this more than I thought.

Where it sits next to the tools you already use

Every tool here is good at its job. The point is that one specific combination didn’t exist yet: designer-friendly, genuinely native, prompt-only, no IDE, no canvas.

A few comparisons:

Figma Make is designer-friendly and needs no IDE. It renders a webview, so native feel isn’t its job.

ProtoPie is great for rich interaction design, but it isn’t native and isn’t prompt-driven.

Origami Studio can get genuinely native, but it’s a steep canvas-and-patch tool, not a prompt one.

Expo and SwiftUI are as native as it gets. Both are built for engineers, not designers.

Prototo is the one that’s all five at once. That’s the gap it fills, and it’s the only reason it exists.

What’s honest about where it is today

The core works now. One command, the Simulator opening itself, prompting through Claude Code, Figma MCP, hot reload. That’s live today.

It’s a prototyping tool, not a production one. It generates prototypes you test, share, and hand off. Though the handoff is cleaner than usual, since the project itself reads like a spec.

And it’s native only by design. That’s a deliberate constraint, not an oversight.

Try it this week

If you’ve got a flow you can’t judge from the canvas, the kind you need to feel, give it 60 seconds.

npm create proto@latest myapp

Then cd myapp, run claude, and ask for a screen. Watch it come to life.

Learn more at prototo.app, read the docs at docs.prototo.app, and the full demo is on YouTube above.

If you build something with it, send me the video. I’m collecting them now.

Sherizan is Chief of Design at Botim, MENA’s fastest-growing super app. Previously Global Design Leader at TikTok and Senior Principal Designer at Grab, where he led the GrabPay redesign. He writes the Design AI Stack newsletter and builds in public.

This is the mobile version of my prompt library.

The web app playbook covered Next.js. This one covers Expo. Same approach, different output. A real app that runs on iOS and Android.

In case you missed the web app playbook:

Before you start: software you need

Create accounts and install these first. They’re all free to sign up.

• Node.js LTS. The engine that runs your app locally. Without it, nothing works. Download at nodejs.org (choose the Installer for your system, Mac or Windows).

• Expo Go. The app that shows your work on your actual phone while you build. Download it on your iPhone or Android from the App Store or Google Play. Free.

• Firebase. Your database and login system. Create a free account at firebase.google.com. No card required on the free plan.

• Claude. Paid subscription required for Claude Code. Make sure you’re on a paid plan at claude.ai before you start.

A note if you’re on a work laptop: you may need admin rights to install software.

Read more

I run jfbi.ai, an AI Builder Sprint days with designers, founders, builders in a room. We hand everyone a stack and a set of prompts. By end of day, most people have shipped something real.

This is that prompt library I’m sharing with you.

Before you start: software you need

• Node.js LTS. The engine that runs your app locally. Without it, nothing works. Download at nodejs.org (choose the Installer for your system, Mac or Windows).

A note if you’re on a work laptop: you may need admin rights to install software.

The stack

• Cursor. Where you write and see your code. Think of it as a smart text editor, like Figma but for building.

• Claude Code. Your AI building partner. Lives inside Cursor’s terminal. Paid subscription required.

• Next.js. The framework that powers your app.

• Tailwind and Shadcn UI. Handles how everything looks.

• Supabase. Your database, if you need to store data.

• Vercel. Puts your app on the internet in minutes.

• GitHub. Saves your work and tracks every change you make.

Read more

Open Mobbin. Search the flow. Scroll. Screenshot. Drop into Figma. Reorder. Annotate. Repeat for the next competitor.

Hours. Every time. Last week that stopped.

What I tried

Mobbin shipped an official MCP in beta. Included with all paid plans during beta. Feature access and availability may change in future updates.

I hooked it up alongside the Console MCP and pointed Claude Code at both.

Then I prompted:

That’s it. One line.

What actually happened

Claude went to Mobbin. Pulled the screens. Started laying them out in Figma.

Then I noticed something off.

The first screen was Google Pay India. The second was Google Pay US. The third was Google Pay India again. The “onboarding flow” Claude assembled was a Frankenstein three regions stitched together.

Before I could even type a correction, Claude flagged it itself.

“The screens I pulled span multiple regions (US, India). This breaks the flow continuity. Re-pulling — defaulting to US only.”

It re-queried Mobbin. Filtered to one region. Re-laid the screens in Figma in the correct order.

I didn’t touch a thing.

Why this matters

The unlock isn’t that AI can fetch screens. Anyone can fetch screens.

The unlock is that the stitching is gone.

In the old loop, I was the integration layer between Mobbin and Figma. Every screen passed through my hands. Every annotation, every reorder, every “wait, this is the wrong country” check, that was me.

Now the stack does it:

1. Mobbin MCP: the competitor screen library, queryable by intent.

2. Figma Console MCP: Claude can open, place, and arrange frames in your Figma file.

3. Claude CLI: the brain that connects the two and self-corrects when the data is messy.

Three pieces. One prompt. A workflow that used to take an afternoon now takes the length of a coffee.

Where this gets really good

The one-prompt version is the entry point. The real leverage is wrapping it as a Claude skill so you don’t have to remember the prompt every time.

I built one and called it /mobbin. You type the slash command, name the competitor and flow, and the skill handles everything, fetches from Mobbin, self-corrects region mismatches, places frames in Figma in flow order, then runs a structured analysis pass against the screens.

The analysis pass is the part most people miss. Fetching is table stakes now. Auto-analysing, checking entry points, friction moments, KYC placement, empty states, error handling — is where the time actually compounds.

Chef’s kiss when it runs clean.

Want the /mobbin Claude skill?

Below are the exact prompts I use for region filtering and flow assembly, the structured analysis pass Claude runs against the screens, and the Figma layout config so the frames land in the right order every time.

This playbook is constantly being updated as Mobbin’s MCP evolve out of beta.

Read more

Last week, two things shipped four days apart.

Anthropic launched Claude Design on April 17. Google open-sourced DESIGN.md on April 21.

Both touched design systems. Both promised to make AI agents respect your brand. Most coverage I read treated them as competitors.

They’re not.

• “Does this replace DESIGN.md?”

• “Why would I write DESIGN.md if Claude Design extracts my system automatically?”

These are good questions. I had the same ones when the launch landed.

The short answer: DESIGN.md is foundational. Claude Design is a tool that becomes more useful when you have a DESIGN.md to point it at. They’re not the same layer of your stack.

Here’s why.

What Claude Design actually does

Claude Design launched April 17. Research preview. Available on Pro, Max, Team, and Enterprise plans.

You describe what you need. It generates a prototype, a slide deck, a landing page, a one-pager. Live HTML. Clickable. Refineable through chat.

The part that made designers pay attention isn’t the generation.

It’s the onboarding.

During setup, Claude Design reads your codebase and your design files and extracts a design system automatically. Colors, typography, components, spacing. It builds a token library from whatever you give it. A Figma file. A GitHub repo. A brand PDF. Even a live website URL.

From that point, every new project inherits the system.

That’s a real shortcut. Genuinely useful, especially if your team has been pasting hex values into prompts for the last year.

What DESIGN.md actually does

DESIGN.md is a different thing entirely.

It’s not a design system itself. It’s not a token format like Style Dictionary or W3C Design Tokens. It’s not a style guide your team reads.

It’s a plain-text file in your repo. YAML at the top for tokens the agent can parse. Markdown below for the rules a human wrote. Every AI agent reads it before generating anything.

It’s a contract.

Version-controlled. Editable by your team. Cursor reads it. Claude Code reads it. Figma Make reads it. Any agent you adopt next year reads it.

Google Labs shipped the spec. We’ve been building an extended version using Nova, botim’s production system, as the worked example.

Why the question keeps coming up

Both are working on the same upstream problem.

Agents drift.

You prompt them today, they get close to your brand. You prompt them again tomorrow, they drift a little. By session four the corner radius is different. The button weight is off. The neutral is too cool.

Quietly, consistently off.

That drift is the context tax we’ve all been paying. Every prompt. Every session. Every project. Paying it again.

The fix is a system the agent reads every time before it generates. Both DESIGN.md and Claude Design are working on that. They just approach it from different angles.

Three things that are actually different

1. Where it lives, who reads it

Claude Design is a single product. The system you upload lives inside it. If you stop paying, change vendors, or Anthropic deprecates the feature, your work goes with it.

That said, it is still early. Anthropic ships fast, and Claude Design has only been out for a week. My prediction: this gets more interesting. I’d expect them to expose Claude Design through MCP soon, which would open up a real range of use cases. Reading your DESIGN.md from the repo. Generating output that respects it. Sitting alongside the rest of your stack instead of inside its own box. If that lands, the picture changes for the better.

For now, though, the system you build inside Claude Design is scoped to Claude Design.

DESIGN.md lives in your repo. It travels with your code. Cursor reads it. Claude Code reads it. Figma Make reads it. The next agent you adopt next year reads it. It is to design what tsconfig.json is to engineering. A small open file in your repo that every tool in your workflow already knows how to consume.

One is product-level memory. The other is a portable contract.

This is the foundational layer. You write it once and every tool, current and future, benefits from it.

2. The principles layer

This is where the split is clearest.

Claude Design extracts what your system is. Colors. Typography. Components. The structural facts.

DESIGN.md carries why it is the way it is.

“Primary is rationed. Used once per screen for the most important action.” “Motion is reassurance, not entertainment. Never animate error states.” “When in doubt, remove an option. Decision paralysis is the silent UX killer.”

These aren’t tokens. They’re the principles and constraints behind the tokens.

An agent that knows your hex codes will still sometimes put two primary buttons on the same screen. An agent that also knows your principles is more likely to catch itself.

The principles are the part you write yourself, and they’re the part that makes a system feel yours.

3. Extraction is fast. Writing is deliberate.

Claude Design infers your system from what it reads. For clean codebases and well-structured Figma files, the inference is good. For messier source code, nested tokens, brand-specific shadows, multi-brand setups, the model is making educated guesses.

Anthropic’s own documentation is honest about this.

“The design system import works best with a clean codebase. Messy source code produces messy output.”

DESIGN.md is written by a human who knows the system. You write the corner radius value, and the sentence that explains when to break it.

Different inputs. Different outputs. Both useful at different stages.

“But Claude Design has a Claude Code handoff. Doesn’t that solve it?”

Claude Design has an export called “Send to Claude Code.” It packages up the design tokens, the component structure, the layout hierarchy, the assets, and a PROMPT.md for Claude Code to read. Claude Code receives the bundle, loads it into context, and builds the feature. It’s a real workflow. It works today.

But it isn’t the same thing as a portable contract.

Two reasons.

One. The handoff is a snapshot, not a live link.

When you export from Claude Design to Claude Code, you’re shipping the system as it exists right now. If the design system updates inside Claude Design tomorrow, the bundle you handed off yesterday doesn’t update with it. You re-export. You re-hand-off. Per project. Every time.

A DESIGN.md in your repo is a single source of truth. Update the file once. Every agent reading it from the repo gets the new version on its next prompt. No re-export. No re-handoff.

Two. The handoff goes to Claude Code. That’s it.

Cursor doesn’t receive the bundle. Figma Make doesn’t receive the bundle. The next agent your team adopts in a year doesn’t receive the bundle. The handoff is built specifically for the Claude Design → Claude Code loop, which is exactly the loop Anthropic is investing in. That’s a fine bet for them. Less fine if your team uses more than just Anthropic products.

DESIGN.md sits in your repo. Every agent already knows how to read a markdown file in a project root. No bundle. No vendor-specific format.

This is the same reason I think the MCP prediction matters. Once Claude Design exposes itself through MCP, the handoff stops being the only way out. The system can be read from the repo, by Claude Design and by anything else. That changes the loop for the better. But it isn’t there yet.

For now, the handoff is one bridge. DESIGN.md is the road.

Where it all fits

A quick mental model before we go to setup, since this is the part that confuses most readers right now.

A while back I wrote about the two modes of design: divergent (explore fast, generate options, find direction) and convergent (refine, build, ship). AI tools belong in one mode or the other.

Here’s where the new layer of products fits:

The thing to notice: DESIGN.md sits underneath everything else.

Claude Skills are a useful adjacent layer worth a quick word. A Skill is a markdown file in .claude/skills/ that an agent loads when the task matches. Your DESIGN.md can be a Skill the agent picks up automatically when it’s working on UI. Or you can author additional Skills that point at it. Either way, the system is still in your repo. Skills are the loading mechanism, DESIGN.md is the load.

Divergent tools generate ideas. Convergent tools ship them. Capability layers tell the agent how to behave. The foundation is what every layer reads to stay on-brand.

Set the foundation first. Everything else stops drifting.

So where do you start?

Start with DESIGN.md.

It’s the foundation. It’s open. It’s free. It works with every engineer’s preferred IDE. It is editable by your team in the same way every other config file in your repo is editable. It will outlast any single AI product, including the one Anthropic shipped last week.

Drafting it forces you to do work no extraction can do for you. You have to articulate why your system is the way it is. You have to write down the principles, the heuristics, the dark mode handling, the RTL rules, the motion constraints. Those are the parts an agent can’t infer from a Figma file. They are also the parts that make a system feel like yours and not like every other AI-generated UI.

Once you have a DESIGN.md, Claude Design becomes more useful, not less. You can point it at the file as part of your project context. The output gets tighter. The drift goes down.

The reverse is not as true. A Claude Design extraction without a DESIGN.md still leaves you without a portable contract for the rest of your stack.

DESIGN.md is the foundation. Claude Design is one of many tools that become better on top of it.

If you want a head start on extraction, Claude Design can produce a useful first-draft token list from a Figma file or repo. Treat the output as raw material. Move it into a DESIGN.md. Add the prose that makes it yours.

One thing worth flagging

If your codebase is proprietary and you point Claude Design at it, you are sending that code to Anthropic.

Figma files are different. Parsed locally in your browser. Never uploaded.

But codebase ingestion goes server-side.

If you’re on an Enterprise plan, it’s worth checking that your contract covers this before pointing Claude at a production repo. Quick conversation with your team. Easy to do, easy to skip.

How to set up DESIGN.md for your design org

Next week’s playbook walks through the full setup. The version that’s working in production at botim, on Nova, today.

Here’s what’s covered:

• The 9+5 framework. Nine canonical sections every DESIGN.md should have, plus five production extensions (iconography, motion, RTL, voice, heuristics) that the official spec doesn’t cover yet

• The principles layer. The part the spec doesn’t have. The part that makes a system feel like yours

• The 10 heuristics every production system needs. Hick’s Law. Decision paralysis. WCAG minimums. Each cited, each enforceable, each written for the agent to follow

• The dark mode build workflow. One source-of-truth file, two Stitch-compliant outputs, a small build script that prevents drift

• The starter template you can fork in five minutes. Same structure, your tokens, your principles

• The wiring across Cursor, Claude Code, and Figma Make. Same prompt, three setups, side-by-side outputs

Built on a public GitHub repo you can clone, fork, or pull from directly. Apache 2.0, like the upstream spec.

Take what helps. Adapt it to your team. Skip what doesn’t fit. The whole point is to give you a foundation you can start writing this week, not a rulebook you have to follow.

If you’ve been hand-rolling your own context files for Cursor or Claude Code, this is the one to subscribe for.

I remember the exact meeting where everything changed.

It was 2018 at Grab. We were a design team of over a hundred people, all using Sketch, all dropping files into Google Drive, all pretending that was collaboration. It wasn’t. Version conflicts and naming chaos: homepage_final_v3_FINAL_USE-THIS-ONE.sketch. You know the drill.

We tried Abstract. We tried Zeplin. Band-aids on a broken workflow.

Then someone pulled up Figma in our weekly sync. Two cursors on the same canvas. Real time.

We were sold in under five minutes.

Migration took three months. A hundred-plus designers exporting out of Sketch, rebuilding libraries, relearning muscle memory. Painful. But nobody asked why. Collaboration wasn’t a feature of Figma. It was the product.

Fast forward to today, and I’m getting déjà vu.

The canvas is moving again

A new wave of tools is here, and they don’t treat pixels as the canvas anymore.

Google Stitch, Paper and Pencil evolved into an AI-native infinite canvas paired with a design agent that reasons across your entire project. You don’t open a blank file. You describe what you want, drop in a screenshot or a few lines of code, and Stitch generates working UI. They’re calling it “vibe designing.” You can literally talk to it. “This header feels too heavy.” It adjusts.

Then last week, Anthropic launched Claude Design. Different bet, same destination. You point Claude at your codebase, and it builds a design system from what already exists. Your colors, typography, components. All reverse-engineered from your live product. Every prototype after that is automatically on-brand. When you’re ready, it bundles the whole thing for Claude Code, the same AI that writes the production code.

Three days before that launch, Anthropic’s CPO Mike Krieger resigned from Figma’s board.

Make of that what you will.

Figma assumed you start with a blank canvas and place elements on it. These tools assume you start with intent and refine the output.

That’s a category shift.

Design used to happen on the canvas. Now it happens in the conversation.

I write weekly playbooks for designers using AI. If that’s you, subscribe to Design AI Stack.

The wallet screen test

A few weeks ago I posted two screenshots in our design team’s group chat at Botim. One was our Wallet screen, hand-designed by a product designer. The other was the same screen, generated end-to-end by Claude.

That moment told me everything I needed to know. AI tools like Claude Code, Cursor, Claude Design, and Stitch are already remarkably good at production-ready UI. Give them a prompt, a design system, and some context, and they ship something competent, consistent, and on-brand.

Not inspired. But shippable.

And for the vast majority of screens in the vast majority of products, shippable is exactly what you need.

What AI still can’t do

This is where designers push back. “AI can do my job?”

That’s not what’s happening. What’s happening is more interesting.

There are two types of design work: the creative and the mechanical.

The creative is the thinking. Understanding a user’s pain. Reframing a problem. Deciding what not to build.

The mechanical is the execution. Mockups, variations, specs, assets, consistency.

The mechanical part? Give it to the machines. Fully. Without guilt.

The creative part is still ours. And it matters more than ever.

Here’s why. AI works by inference. It’s consumed decades of interface design and is extraordinarily good at recombining what already exists. But recombination is not invention.

Pinterest didn’t redesign the grid. They broke it.

TikTok didn’t redesign the video feed. They eliminated it. Tinder didn’t redesign the dating profile. They turned it into a gesture.

Every one of those came from a human insight about human behavior. Not from analyzing existing patterns and producing a variation. They required someone to look at a problem sideways and have the conviction to ship something that initially seemed too simple or too strange.

Could an AI have proposed that swiping on faces would become a billion-dollar interaction?

I doubt it.

The interview question

I’ve been asking my peers a question lately: “As AI disrupts our industry, how do you plan to pivot your career when the work we do is made obsolete by Gen AI tools?”

Most of them freeze.

The honest answer is: the job is splitting in two.

One path is craft. The pixel-level, implementation-focused work that’s defined the profession for fifteen years. This path is being automated, fast. Fighting that is like my old team fighting to stay on Sketch because they’d customized their toolbars. Nostalgia is not a strategy.

The other path is invention. The messy, ambiguous work of identifying unmet needs and proposing interactions that don’t yet exist. This is where the value is moving. It rewards skills design school barely teaches: ethnographic research, systems thinking, behavioral psychology, the conviction to propose something genuinely new. They ones who can see what AI cannot. The unspoken frustration. The latent desire. The gesture that hasn’t been invented yet.

Figma’s legacy

Figma’s real legacy isn’t the multiplayer cursor or the browser-based editor. It’s the proof that tools shape culture. Figma made design collaborative, and in doing so, it changed what it meant to be a designer.

The tools coming next will change the meaning again. When code is the canvas, when an AI agent is your collaborator, when your design system lives in your codebase, “designer” will mean something closer to “inventor” or “interaction architect” or maybe something we don’t have a word for yet.

I don’t know exactly what that looks like. But it feels familiar. That same electricity I felt watching two cursors move on a canvas in 2018, knowing the old way was already over.

The only question is whether we’ll spend three months migrating, or three years resisting.

Want the actual stack I’m running on production work?

The full breakdown. Which tool I reach for when, the prompts that actually hold up under real workloads, where Claude Design, Stitch, Cursor, and Claude Code each fit (and where each one still breaks), and the file structure I use to keep them from stepping on each other.

This is part of my Design Stack Playbook. Constantly being updated as the tools evolve.

Paid subscribers get it below.

Subscribe now

Sherizan is Chief of Design at Botim, MENA’s fastest-growing super app. Previously Design Leader at TikTok and Senior Principal Designer at Grab. He writes Design AI Stack, where he shares weekly playbooks on AI workflows for designers.

Anthropic has provided us with the complete guide how to get the most out of Claude Code. This is how I interpret it for my smaller projects where you don’t need a full fledge design system.

Read more

I need to be upfront about something before we start.

I’m a designer. I’ve worked on apps serving over 1.9 billion active users at TikTok, 50 million active users at Grab. My coding knowledge stopped at JavaScript. And I’m writing an article about programming languages.

That alone should tell you how much has changed.

Two years ago, I wouldn’t have had an opinion on this. Now I’m deep in Figma MCP, Claude Code, and vibe coding workflows and the question of what language things are built in is suddenly very relevant to my work. Not because I’m writing code. But because the line between designing and coding is dissolving so fast that the distinction might not matter soon.

Whether that’s exciting or terrifying depends on the day.

The mess under the hood

Here’s something most people outside big tech don’t realise. The apps you use every day are not built in one language.

TikTok? Parts Kotlin and Swift for native UI. A custom cross-platform framework called Lynx that ByteDance built internally and open-sourced in 2025 because nothing on the market could handle their complexity. Grab serving 50 million users across Southeast Asia? Similar patchwork. React Native here, native code there, custom bridges connecting everything.

This is not an exception. This is the norm.

A single design system, the one we spend months perfecting in Figma has to translate into multiple codebases, multiple languages, multiple rendering engines. And the translation is lossy. Every time. “Should this spacing be 16px or 20px?” is a Slack message that has been sent a billion times across the industry, and it exists because design files and code are fundamentally different representations of the same thing.

So when people talk about “design to code” or “design in code,” this is the part they’re skipping. It’s not just a handoff problem. It’s a multi-language, multi-platform infrastructure problem that nobody has cleanly solved.

Which got me thinking. If AI is rewriting how we build software… will it also rewrite what we build software with?

Every era invents the language it needs

Quick history, because it matters for what comes next.

The web needed a scripting language for browsers. Brendan Eich built JavaScript in 10 days in 1995. Mobile needed languages that could talk to hardware. Apple created Swift. Google backed Kotlin. Facebook looked at all of this and said “what if we could use JavaScript to build native apps?” and React was born. Machine learning needed something accessible to researchers who aren’t systems programmers. Python became the default, not because it’s fast, but because the ecosystem made it frictionless.

Every time the paradigm shifted, a new language emerged. Facebook invented React. Vercel invented Next.js. The pattern is consistent.

So here’s the question. AI is the biggest paradigm shift since the internet. What language or what thing will it invent next?

The “language doesn’t matter” argument

The numbers are hard to argue with.

AI writes roughly 30% of Microsoft’s code and over a quarter of Google’s, according to their own CEOs. Y Combinator reported that 25% of startups in their Winter 2025 batch had codebases that were 95% AI-generated. Stack Overflow’s 2025 Developer Survey found 80% of developers using AI coding tools weekly.

Andrej Karpathy coined “vibe coding” in early 2025 the idea of describing what you want in plain English and letting AI handle the implementation. Collins Dictionary named it Word of the Year. By early 2026, Karpathy himself said vibe coding is already passé. The new paradigm is “agentic engineering” you’re not writing code at all, you’re supervising agents that write it for you.

Jensen Huang, NVIDIA’s CEO, put it even more bluntly: “It is our job to create computing technology such that nobody has to program and that the programming language is human.”

If AI can translate natural language into Python, Swift, Kotlin, or Javascript equally well, then the programming language becomes an implementation detail. Like assembly language. You don’t think about assembly when you write Python. Maybe soon, you won’t think about Python when you describe an app.

There are still new languages emerging like Mojo, built by Chris Lattner (the creator of Swift), reads like Python but performs like C++, heading to 1.0 in 2026. But the bigger story isn’t any single new language. It’s the possibility that language choice itself becomes invisible.

OK Sherizan. So what does this mean for designers?

This is where I have to be honest about two things that are both true at the same time.

1) The “design is dead” argument is not wrong.

I know designers don’t want to hear this. I don’t particularly want to write it. But let’s look at what’s actually happening.

PMs and designers at Meta have publicly said they now show working products instead of UI prototypes. Designers are shipping MVPs through AI coding tools before developers even get briefed. Figma’s stock dropped roughly 85% from its post-IPO peak. Wall Street is calling it the “SaaSpocalypse” a trillion-dollar selloff in software stocks driven by fears that AI is eating the workflows these companies were built on.

Shadcn happened. A component library so well-designed, well-documented and so easy to prompt with that people started building dashboards, landing pages, and full interfaces directly with shadcn components with no Figma file needed. You describe what you want, AI generates production-ready React with shadcn, Tailwind, and Next.js. It looks good. It works. No designer touched it. I’m a huge fan of v0 and what Vercel has done for vibecoding.

Then frontier models got scary good. You can one-shot a full interactive dashboard with Claude Opus 4.6 or Gemini Pro. Not a mockup. Not a prototype. A working component with real interactions, real state management, real functionality. The kind of thing that used to take a designer days in Figma and a developer weeks to implement done in literally minutes by someone who never opened a design tool.

There are reports that programmer employment in the US fell 27.5% between 2023 and 2025. The squeeze isn’t just on developers. Entry-level design work, the screen-by-screen production that used to be someone’s first job is exactly the kind of task AI automates first.

If you’re a designer and you’re not at least a little nervous, you’re not paying attention.

2) Something interesting is happening at the edges.

At the same time that people are declaring design dead, a new category of tools is emerging that suggests the opposite.

Pencil.dev calls itself “Design Mode for Cursor.” It’s a Figma-like canvas that lives inside your IDE. Your design files sit in your Git repo. You design visually, AI generates the underlying React. Or you prompt AI, and it designs visually on the canvas. The direction goes both ways.

Paper.design renders every element as real HTML and CSS. No conversion step. You design with real flexbox layouts, real CSS properties, real font rendering. Right-click any element → Copy as React. They raised $4.2M from Accel, and their thesis is interesting: the canvas of the future IS code, you just shouldn’t have to know that.

Figma launched “Code to Canvas” with Anthropic that generates an interface in Claude Code, say “Send this to Figma,” and it lands as fully editable design layers. Plus Figma Make, Code Connect linking components to production code, and MCP integrations letting AI agents read and write to Figma files directly.

These tools aren’t treating design as a step before code. They’re treating design as code. Or code as design. The distinction is breaking down.

And Figma’s own State of the Designer 2026 report shows something that complicates the “design is dead” narrative: 89% of designers say they’re working faster with AI. 91% say AI tools actually improve their designs. Designers leaning into AI are 25% more likely to say they’re satisfied at work.

So which is it? Is design dying? Or is it evolving into something more powerful?

I think the honest answer is: both. At the same time. For different people.

A “what-if” I can’t stop thinking about

I want to be careful here. This is not a prediction. This is a thought experiment. Because I think it’s worth exploring even if it turns out to be wrong.

What if the next programming language isn’t a language at all? What if it’s a design file?

A designer izaias described Figma as “logic wearing a canvas costume.” And he’s not wrong. Every design is JSON. Every component is a node. Auto layout is flexbox. Constraints are code. We’ve been programming all along, we just called it designing.

Paper.design’s canvas renders real HTML/CSS. Pencil.dev stores designs as JSON. Figma’s Code Connect links components to production code. Shadcn gives you a component system that AI can compose into anything.

So here’s the what-if.

And AI handles everything underneath like choosing Swift for iOS, Kotlin for Android, React for web, C++ for the performance layer, building the bridges between all of them automatically.

That messy multi-language architecture at TikTok and Grab? It disappears. Not because someone invented a universal language. But because the design file became the universal specification, and AI figures out the compilation.

Design as the last programming language.

Now, hold on. I can already hear the objections. And they’re valid.

This assumes AI gets good enough at the translation. Right now, it isn’t. Vibe-coded apps have 1.7x more major issues than human-written code according to a CodeRabbit analysis. Security vulnerabilities are 2.7x higher. A Lovable analysis found 170 out of 1,645 apps had data exposure issues. The gap between “looks right” and “works at scale” is enormous.

It also assumes design can encode enough information to replace code. Today’s design files don’t capture business logic, state management, error handling or the thousand edge cases that make software actually work. A beautiful Figma file tells you nothing about what happens when the API fails at 3am.

And it assumes the industry will converge on a standard representation. Figma files are proprietary. Paper.design uses its own format. Pencil uses .pen files. We can’t even agree on design tokens, let alone a universal compilation target.

So yeah. Maybe this is naive. Maybe design files as programming languages is a fantasy that ignores how software actually works at scale.

But.

Two years ago, the idea that a designer could one-shot a working dashboard by describing it to an AI was also a fantasy. And here we are.

Where this actually leaves us

I don’t know if design is the last programming language. I don’t know if programming languages will become invisible. Nobody does. Anyone who tells you they know exactly how this plays out is selling you something.

What I do know is this.

The old workflow aka design in Figma, hand off to developers, argue about spacing in Slack, ship something that doesn’t match the mockup is dying. That part isn’t controversial.

What replaces it is up for grabs. Maybe it’s designers coding directly. Maybe it’s AI agents that make the design-to-code gap irrelevant. Maybe it’s new tools like Paper and Pencil that merge the two entirely. Maybe it’s something we haven’t seen yet.

For developers: if programming languages become an implementation detail handled by AI, then the value shifts to systems thinking, architecture, and knowing what to build, not which syntax to build it in. Karpathy’s “agentic engineering” isn’t just a rebrand. It’s a fundamentally different job description.

For designers: if AI can generate any interface from a description, then the differentiator isn’t your ability to push pixels. It’s your ability to understand users, define problems, make intentional decisions, and apply taste that AI can’t replicate. Paper.design’s founders put it well: AI will help turn design into code, but it’s the designer’s role to decide what to build, steer the AI, and make sure it’s cohesive.

The people who thrive in this next era won’t be defined by their tool like Figma, Cursor, Claude, whatever comes next. They’ll be defined by their judgment.

And honestly? As someone whose coding stopped at JavaScript but who’s now deep in Claude Code and Figma MCP workflows, I find that both terrifying and kind of hopeful.

I just don’t think we should pretend we know how this ends.

What’s your take? Is design evolving or dying? Is the programming language question even the right question? I’m genuinely working this out in public . Hit reply, I want to hear what you think.

You’ve spent hours getting the component just right inside Figma. The spacing is tight, the tokens are named correctly (mostly), and the layout actually makes sense. You open up your AI coding tool and then you write a prompt. Something like:

“Build this card component in React Native.”

And what comes back is... close. But not right. The padding is off. The component ignores your design tokens. The variant states are missing. So you iterate. You write a better prompt. You get closer. You iterate again.

What just happened wasn’t a failure of AI. It was a failure of context. The model didn’t know what it didn’t know and neither did you, until you saw what was missing.

I built DesignAgent because I kept living in that gap.

The Real Problem with Prompting from Design

There are a few things that silently break every build:

• Components without auto-layout that confuse the AI’s understanding of spacing relationships

• Design tokens that exist in Figma but never make it into the prompt

• Platform mismatches: a component built for web being prompted for a React Native context without adjustment

• Missing variant states, unnamed layers, and absolute positioning that looks fine visually but generates brittle code

The result? Inconsistency. Every prompt is a guess. Every handoff is a negotiation.

What DesignAgent Actually Does

DesignAgent is a Figma plugin that sits inside your workspace and does something really simple: it reads your current selection, scores it, and writes the prompt for you.

Not a generic prompt. Not a template you fill in. A context-specific, developer-ready prompt built from what’s actually in your design right now, for the platform you’re actually building on.

Select a component. Open the plugin. Choose your target platform. The prompt is ready.

Five platforms, one consistent workflow

DesignAgent supports five presets out of the box:

• Next.js + Tailwind — for web teams building with the modern React stack

• React Native + NativeWind — for mobile teams who want utility-class consistency across platforms

• Web HTML/CSS — for projects that don’t live inside a framework

• SwiftUI — for iOS builders working natively

• Jetpack Compose — for Android developers handling UI in Kotlin

Switch the preset, and the prompt changes. The structure adapts. The warnings update. The guidance reflects what that specific platform needs from your design.

It doesn’t just generate.. it scores.

Here’s the part that surprised even me during development: the scoring system became the most valuable feedback loop.

Before you ever copy a prompt, DesignAgent evaluates your selection across five dimensions:

1. component structure

2. tokenization

3. layout

4. naming

5. variant coverage

And gives you a score. It surfaces warnings where things will likely break in code. It flags absolute positioning. It tells you when you’re missing token references that your prompt will assume exist.

You don’t have to guess why the output isn’t right. The plugin tells you, in plain language, before you ever leave Figma.

What’s Actually Inside a DesignAgent Prompt

This is the part I want to spend some time on, because it’s where the real work happens and it’s what makes DesignAgent different from any other prompt generator I’ve seen.

Most “prompt generators” are wrappers. They take what you tell them and rephrase it. DesignAgent is not that. The prompt it builds is a structured engineering document and it contains things you would never think to write yourself.

1. It knows what you selected

Before a single word of the prompt is written, DesignAgent reads your selection and classifies it. Not just the name and the size, but the intent: is this a screen? A standalone component? A reusable section? A multi-frame flow?

The classification matters because each of these things needs to be built differently. A screen prompt includes rules for a single output file. A flow prompt includes a sequencing spec — screen order, transitions, routes — before any code is written. A component prompt focuses on props and variants. A section prompt includes instructions for how it mounts into a parent screen. The prompt structure changes based on what you actually selected, not what you described.

2. It sets Figma as the only source of truth

One of the hardest problems in AI-assisted UI development isn’t generating code. It’s preventing the AI from making things up. Left to its own devices, an AI coding tool will fill in gaps with reasonable-looking guesses and those guesses are where bugs and inconsistencies are born.

Every DesignAgent prompt includes a set of hard constraints that the AI must follow. The most important: it may not guess any value that can be retrieved directly from your Figma file. Spacing, typography, color, tokens, component bindings all of it must come from the design. If something is ambiguous or missing, the AI is instructed to surface it as an open TODO with the exact node reference, not to make a decision on your behalf.

This is the “no invention” rule, and it’s baked into every prompt DesignAgent generates.

3. It tells the AI how to read your design in the right order

Here’s something that surprised me in development: the sequence in which an AI queries Figma matters enormously for both accuracy and efficiency. Request too much at once and the context overflows. Request in the wrong order and you miss dependencies between tokens, components, and interactions.

DesignAgent builds a specific, ordered reading strategy into every prompt. It tells the AI to start shallow just the root and immediate children and only go deeper where the design requires it. Then variables and tokens. Then component mappings. Then visual reference. Each step has a fallback if the previous one returns incomplete data.

This sequencing is invisible to you as a user. But it’s what separates a prompt that produces consistent, production-ready code from one that produces something close but structurally off.

4. It accounts for your design system

If your components have Code Connect mappings a Figma feature that links design components to their code equivalents DesignAgent’s prompts will instruct the AI to use those mappings. Not as a suggestion. As a requirement.

The prompt also tracks token coverage: which values in your design are backed by a design token versus which ones are raw hardcoded values. This shows up in the scoring panel, and it also shapes the prompt. The AI is told where tokens exist, where they don’t, and how to handle each case. The result is code that references your actual design system rather than inventing a parallel set of magic numbers.

5. The output is structured, not open-ended

Most AI prompts end with something vague like “build this.” DesignAgent prompts end with a precise output contract: a file tree, code blocks labeled by filepath, and an open TODOs list for anything the AI couldn’t resolve from the design. No alternatives. No multiple implementations.

This matters for teams. When every developer is working from the same structured prompt format, the code that comes back follows the same structure too. It’s reviewable. It’s predictable. It fits into your existing codebase rather than arriving as a surprise.

Why Consistency Matters More Than You Think

The dirty secret of AI-assisted development is that the variance in prompt quality creates variance in output quality (garbage in, garbage out) and that variance compounds across a team.

When four engineers on the same project are prompting from the same designs but writing their own prompts, you get four different interpretations of the same component. Over time, that becomes technical debt. Inconsistent spacing. Token values hardcoded in some places, referenced in others. Components that look the same in Figma but behave differently in production.

DesignAgent solves this not by being opinionated about your design but by being precise about what your design already says. The prompt it generates isn’t my interpretation of your component. It’s a structured reading of your Figma node, translated into the language your AI coding tool needs to hear.

Same design, same platform, same prompt. Every time. Whether it’s you or a teammate who just joined the project.

Who This Is For

If you’re a designer who’s tired of being told “the code doesn’t match the design” then DesignAgent is for you. Not because it fixes the code, but because it equips you with the context to communicate your design accurately to AI tools and to the developers working alongside them.

If you’re a developer who spends too much time reverse-engineering Figma files to write a good prompt then DesignAgent is for you. The analysis work is already done. The spec is already extracted. The prompt is already written.

If you’re a team that’s trying to move faster without letting quality slip — DesignAgent gives you a shared language between design and code that doesn’t depend on whoever wrote the prompt that day.

Where We Are Right Now

DesignAgent is currently available in Figma Community. That means the core engine is working: the analysis, scoring, prompt generation and platform presets are all live inside Figma.

I’d love to hear what breaks, what surprises you, and what you wish it did differently.

Read more

I love vibecoding but I need to talk about the part of vibecoding nobody posts screenshots of.

The bill. 🧾

Read more

High-quality prototypes in Figma Make come from one decision:

Use the same component library engineers already ship.

Figma Make can now install npm packages, including yours or ANY component library package, so your prototype uses real production components instead of lookalikes.

What Figma Make expects (so you do not fight the tool)

Your design system package needs to be:

• React 18+

• Published as an npm package (public npm, or your org’s private Figma npm registry)

• Make currently supports React codebases for design system packages.

Path A: Bring your org design system package into Make (the righteous path)

Step 1: Publish your package (public or private)

If your design system is internal, publish it to your org’s private npm registry in Figma Make.

Private registry setup (one-time admin step):

1. Create a new Figma Make file

2. Make settings → Figma npm registry

3. Enter your org scope (example: @exampleco)

4. Generate key (org admin required)

5. Copy the snippet into your .npmrc

6. npm publish your package

Then, inside a Make file:

• Ask chat: “install @mycompany/design-system”

• Or add it to package.json directly

Tip from Figma: after setting up the npm registry, create another new Make file before installing the package.

Step 2: Teach Make how to use your design system (this is where quality comes from)

Make can inspect your package, but it performs much better with explicit guidance files.

Every Make file has a guidelines/ folder.
Make reads guidelines/guidelines.md first.

Recommended Structure

guidelines/
  guidelines.md
  design-tokens.md

Guidelines writing rule
Use direct, deterministic language. “Do not…” beats “use sparingly.”

Copy-paste: a strong guidelines/guidelines.md starter

This Make project uses our production React design system from @mycompany/ui.

Rules:
- Always prefer @mycompany/ui components over plain HTML elements.
- Do not invent new UI patterns or colors.
- If a component exists, use it. If unsure, inspect /node_modules/@mycompany/ui.

Always read first:
- overview-components.md
- all files in design-tokens/

Before writing code:
1) Choose components from @mycompany/ui
2) Read the relevant file in components/ (example: components/button.md)
3) Implement using documented props and variants only

Unfortunately, you can’t copy-paste my design-tokens.md as its specifically made for my design system but I’ll show you how I wrote mine.

# Botim Design Tokens (Make Guidelines)

This project must use Botim tokens consistently.
Do not invent new values.
Do not hardcode arbitrary colors, font sizes, or spacing outside this file.

If you must add a new token:
- Add it here first
- Use the same naming pattern
- Keep values deterministic and reusable

---

## Typography

### Font families
- **Brand / UI:** `Inter`

### Type scale (px)
Use only these sizes.

- `type.display.lg` = `32px` (40px line-height, 700)
- `type.display.md` = `28px` (36px line-height, 700)
- `type.title.lg` = `22px` (28px line-height, 700)
.. and more

### Usage rules
- Screen titles use `type.title.lg` or `type.title.md`
- Primary body text uses `type.body.lg`
- Secondary/metadata uses `type.body.md` or `type.caption`
- Do not use font weights other than 400, 500, 700

---

## Spacing

### Base unit
All spacing is based on **4px**.

### Spacing scale (px)
Use only these values.

- `space.0` = `0px`
- `space.1` = `4px`
- `space.10` = `40px`
.. and more

### Layout rules (mobile)
- Screen horizontal padding: `space.4` (16px)
- Section vertical spacing: `space.6` (24px)
- Card padding: `space.4` (16px)
- Gap between stacked items: `space.3` (12px) or `space.4` (16px)
- Button height target: 48px using padding + line-height, not random height values

---

## Color

### Neutral
- `color.bg` = `#FFFFFF`
- `color.surface` = `#F7F8FA`
- `color.border` = `#E5E9F0`
.. and more

### Brand
- `color.brand.primary` = `#2F6BFF`
- `color.brand.primaryHover` = `#2557D6`
- `color.brand.primaryPressed` = `#1E47B3`
.. and more

### Semantic
- `color.success` = `#16A34A`
- `color.successBg` = `#EAF7EF`
- `color.info` = `#2563EB`
.. and more

### Usage rules
- Default page background: `color.bg`
- Cards/containers: `color.surface`
- Borders: `color.border` (do not invent lighter/darker borders)
- Primary CTA: background `color.brand.primary`, text `color.brand.onPrimary`
- Destructive CTA: background `color.danger`, text `color.text.inverse`
- Links: `color.info`
- Error messages: text `color.danger`, background `color.dangerBg`

---

## Make enforcement rules

- Always reference tokens by name in code (or via your design system theme).
- Do not introduce new hex codes in components.
- Do not introduce spacing values outside the spacing scale.
- Do not introduce font sizes outside the type scale.

I know it’s pretty long, but that’s how I want it to be, detailed and deterministic so the quality of the output is accurate.

Putting it to the test

As you can see from my example below, the prototype on the left is using the new npm registry that fetches my production-quality code components that my devs use, while on the right is using our Figma design screen with design system file attached (the current or maybe now its the traditional way).

From a UI and visual perspective, the version on the left is MILES BETTER as it adheres to the layout, spacing is being picked up by the guidelines.md whereas the “traditional” way of building from Figma design files, the divider breaks, the spacing is not inherited, it looks like that cheap prototype that does not look like it deserves to be published and shared.

But here’s the best part..

The prototype on the left also inherits all the component props and all the state changes so you get the actual code components that your devs are using in production!

Check out this demo video where you can see how it automatically:

• inherits the input field active state with the “clear values” X icon.

• the buttons have the exact implementation of the pressed and hover states.

Final step: Turn it into a template for the whole org

After installing packages and adding guidelines, publish the Make file as a template so everyone starts from the same baseline.

Path B: No internal design system yet? Use an existing one (the fun path)

Maybe you need to move fast as a solo founder or just a team with no designers, this one’s for you!

Read more

As AI becomes faster and more capable at producing UI, some tension is starting to show up:

Our design systems were never built to operate at AI speed.

They were built to be read.
They assume humans will interpret rules, remember conventions, and catch mistakes in review.

AI doesn’t work that way.

This article proposes a shift from Design Systems to what I call a Design Model:
an executable form of design governance that AI tools, agents, and engineers can safely operate inside.

This is still experimental.
But it’s already working.

The problem isn’t generation anymore

AI can generate UI easily now.

Screens. Components. Layouts. Variants.
That part is no longer impressive.

The real problem is something else:

Who decides what is allowed to exist?
Which components are valid?
Which styles are acceptable?
Which combinations should never ship?

When AI can generate anything, what we often get isn’t better UX, it’s AI slop: inconsistent, off-brand, technically valid but unshippable UI.

Design systems were supposed to prevent this.
But they rely on documentation, memory, and human enforcement.

At AI speed, that breaks down.

Going one level up: the Design Model

Instead of asking how AI should generate UI, I started asking a different question:

What should AI be allowed to operate inside of?

That led me to the idea of a Design Model.

A Design Model is an evolution of a design system but expressed as something executable, not just readable.

It has three parts:

• Tokens
  Define what styles are allowed
  (colors, spacing, typography, radius, etc.)

• Contracts
  Define what components exist and what props are valid
  (variants, sizes, defaults)

• Constraints
  Define what decisions are not allowed
  (for example: only one primary action per view)

Together, these don’t describe UI. They govern it.

A brief analogy (LLMs, but lightly)

If the analogy helps:

A Large Language Model is not a collection of sentences.
It’s a system that encodes patterns and rules well enough to produce the next meaningful output.

In a similar way, a Design Model is not a collection of components.
It encodes design decisions: tokens, contracts, constraints so valid UI can be resolved, not guessed.

The goal is not to copy how LLMs work.
It’s to apply the same shift: from static artifacts to an executable model.

Generated vs Resolved

In a Design Model, UI isn’t generated but instead it resolved.

An intent comes in from a developer, an AI agent, or a coding assistant.
That intent is evaluated against the model.

• If it fits → it resolves cleanly

• If it doesn’t → the system explains why and suggests adjustments

No static documentation.
No “please follow the design system 🙏”.
No late-stage reviews trying to catch violations. (My QA team can finally breathe)

Rules are enforced at runtime with guidance, not policing.

A deliberately small demo

To keep this honest, I built a small demo using just one component: a Button.

That’s intentional.

Buttons are:

• universally understood

• easy to misuse

• visually obvious when wrong

• a common source of inconsistency

If a system can’t govern a button, it won’t govern anything more complex.

In the demo:

• You can render one or two primary buttons: it works

• You can then add a constraint (“only one primary button per view”)

• Run the same intent again

• The outcome changes without changing the prompt or the renderer

The only thing that changed was the model.

📹 Watch my Demo video above.

Why this matters for AI-assisted coding

AI tools today can read design documentation (via MCP or similar approaches).
But documentation has no authority.

A Design Model does.

It sits between AI and code and answers one question consistently:

“Is this allowed to exist?”

AI can propose.
The model decides.

That shifts AI-assisted coding from:

“Generate UI and hope it’s right”

to:

“Resolve UI against rules and ship with confidence.”

This is still experimental

This is not:

• a new product announcement

• a framework

• replacing designers or Figma

• a completed standard

It’s a working exploration of an idea that feels increasingly necessary as AI accelerates how UI is built.

The repo is public. You can fork it, add a component, add a constraint, and try to break it.

Repo link: https://github.com/sherizan/design-model

An open invitation

If you’re researching AI and design systems,
or actively trying to adapt design systems for AI workflows,

I’d genuinely love to join forces and work toward a shared standard.

Design systems helped us scale consistency.
Design Models may be how we scale decision-making.

This is early.
But it feels like the right direction.

I vibecoded an app. It worked. Then it didn’t.

About a year ago, I launched Nasma, a daily habit app.
Not after months of planning. Not with a big team.

I tried Cursor for the first time in Jan 2025, wanted to see if I could actually build a native iOS app, and… two weeks later it was live.

I posted it on LinkedIn.
People downloaded it.
Feature requests rolled in.

So I did what every vibecoder does:

• ship fast

• add features

• keep momentum

Today:

• thousands of active users

• users mainly from the US, UK, India, Indonesia

Except retention was bad.

After Day 14, only ~5% of users came back.

That’s when I stopped shipping and started thinking.

The mistake I made (classic vibecoder move)

I assumed:

“If something feels slow or messy, I just need to refactor everything.”

Wrong.

What I actually needed was clarity before code.

That’s where Cursor’s Plan Mode quietly became the most useful feature I wasn’t using properly. (Well it also didn’t exist back in Jan)

How I actually use Plan Mode (not the marketing version)

I don’t use Plan Mode to “build”.

I use it to:

Read more

And the designer?
Manually stitching meaning together before every review.

This article is about what happens when you stop stitching.

The idea behind Superdesigner

Superdesigner is not a design tool.

It’s not a UI generator.
It’s not a Figma replacement.
It’s not another place to write docs.

Superdesigner is a reasoning layer that runs inside Cursor.

It connects to where real work already lives like Confluence, Notion, Figma, analytics and helps AI reason across them.

“But Sherizan, I can paste all this into ChatGPT”

I hear this a lot.

And yes you can paste:

• your PRD

• some research

• screenshots

• analytics summaries

Into ChatGPT and get feedback.

But that’s not the same thing.

The real difference is not intelligence. It’s grounded, live context

ChatGPT sees what you upload or paste.

Superdesigner sees:

• the actual PRD in Confluence

• the latest research in Notion

• the real Figma file

• the real analytics funnel

Not a summary.
Not a screenshot.
The source of truth.

And when scope changes?

You edit the PRD where it already lives, re-run the review and new gaps surface.

No copy-paste.
No drift.
No stale context.

How Superdesigner actually works (honestly)

One important clarification.

Superdesigner does not magically think on its own.

What it does is very deliberate.

It generates a structured, opinionated design-review prompt grounded in your real project context and passes that prompt to the Cursor AI agent.

You never write prompts.
You never tune roles.
You never say “act as a senior designer.”

You just run the workflow.

That consistency is the product.

A real project walkthrough

In my video, I run Superdesigner on a real project.

Here’s the actual flow.

1. Connect the sources of truth

• PRD → Confluence (downloaded as Markdown)

• Research → Google Docs (downloaded as Markdown)

• Designs → Figma (via MCP)

• Analytics → Amplitude (not in demo, via MCP)

Superdesigner pulls snapshots of these into context so Cursor can reason across them.

2. Run the review

npm run review

Superdesigner:

• generates a design-review prompt

• hands it to Cursor’s AI agent

• produces a design-review.md

No prompting.
No guessing.
Same structure every time.

3. Read the output (this is the magic)

The generated design-review.md is not UI.

It’s a design review that calls out:

• missing states (empty, error, recovery)

• gaps between PRD and flows

• risky assumptions

• things that will come up in review

• things that should come up but usually don’t

This is what you read:

• before design review

• before handoff

• before launch

This file is the product.

Why Cursor matters

Cursor isn’t just an editor.

It’s an agent runtime.

Because Superdesigner runs inside Cursor:

• it understands the full project context

• it can re-run reviews as things change

• it can chain tools together via MCP

This is where things get interesting.

MCP is where this becomes powerful

Figma MCP

Superdesigner can:

• read Figma file structure

• understand flow coverage

• write high-confidence comments back to Figma

Not visual critique.
Not opinions.

Comments like:

• “The PRD mentions a retry state here — I don’t see one.”

• “What happens if the user fails eligibility?”

AI that speaks inside the workflow, not next to it.

Analytics MCP (e.g. Amplitude)

Now add reality.

Superdesigner can reason like this:

• “This step is unclear in design”

• and analytics shows drop-off here

This isn’t design advice anymore.
It’s evidence-backed design reasoning.

Why this is not a Figma plugin

Plugins are great for:

• generating UI

• manipulating canvas

• speeding up execution

Superdesigner is about:

• thinking

• seeing blind spots

• preventing design regret

It doesn’t replace Figma.
It makes you better before you open it.

Solving the blank canvas problem (what’s next)

One of the hardest moments in design is the start.

No screens.
No flows.
Just a rough PRD and some research.

Superdesigner will evolve to support this cold start:

• connect to fundamental research

• read a rough PRD

• generate:

  • user flows

  • state outlines

  • screen structure (not UI)

From there, plugins and tools (e.g. Figma outline generators like CTTF-style workflows) can push that structure back into Figma.

Designers don’t start from a blank canvas.
They start from clarity.

What Superdesigner is (and isn’t)

It is:

• a second brain for designers

• a repeatable design review system

• a reasoning layer across tools

It is not:

• a UI generator

• a design replacement

• another dashboard

Why I’m building this in public

Because I’m already using it.

Before reviews.
Before handoff.
Before launch.

And every time, it catches something small that would’ve turned into a big conversation later.

That’s the value.

If you have a design review this week, run this once before it.

You can clone it entirely free and customise it however you want at superdesigner.ai

If you’ve reviewed enough designs, you know the moment. The screens are polished. The flows look reasonable. The prototype “works.” And yet.. during review.. small things begin to surface. An edge case no one considered. A missing empty state. A flow that technically connects but doesn’t quite make sense when you say it out loud. A requirement that everyone thought they understood but didn’t.

The sprint slows down. Conversations stretch. Designers pissed.

This doesn’t happen because we aren’t careful. It happens because design review today is built on a fragile assumption: that looking at screens is enough to understand intent.

It isn’t.

The real failure mode of design review

In most teams, design work is fragmented by default.

Product requirements live in documents or PDFs. Research lives in decks. Designs live in Figma. Feedback lives in comments. Analytics lives somewhere else entirely. And most of the time, decisions were made in meetings that you didn’t attend.

When review time comes, we open Figma and try to reconstruct the story in our heads. We rely what we remembered happen. We rely on trust that nothing important was lost along the way.

I wasn’t reviewing intent. I was reviewing screenshots.

Why AI hasn’t meaningfully helped (yet)

Over the past year, we’ve seen an explosion of “AI for designers” tools. Most of them promise some variation of speed: faster screens, faster layouts, faster execution.

But review isn’t about speed. It’s about completeness.

The hardest part of design review isn’t drawing the UI. It’s answering quieter questions:
Did we design all the states? Did we account for failure? Does this flow actually satisfy the original intent? Did research insights make it into the final decisions?

AI struggles here because it’s usually given only the output aka the screens and without the inputs that shaped them. Without access to intent, AI can only guess.

Context isn’t a nice-to-have for review. It’s the entire job.

A different approach

Instead of building another web app or Figma plugin, I tried something simpler.

I turned Cursor into my design review workspace.

Cursor already has everything review needs: files, folders, long-form context, and agents that can reason across documents. More importantly, it’s already where I think when I’m trying to understand a system.

So I built Superdesigner.ai as a lightweight, local workflow.

Not a product that generates UI. Not a tool that critiques visual style. But a system that reviews design intent by reading the same artifacts my colleagues rely on just more consistently and on-demand.

What Superdesigner actually does

Here’s a demo of how it works:

At its core, Superdesigner reads three things: the PRD, the research, and the Figma link.

From that, it produces a structured design review. It reconstructs the intended user flow. It generates a checklist of expected screens. It highlights missing states like empty, loading, error, recovery. It surfaces edge cases described in the PRD that never made it into design.

It generates calm, specific comments that can be posted directly into Figma, grounded in intent rather than opinion.

And finally, the icing on the cake. It creates a Figma Make prompt to generate a new prototype with the proposed solutions baked in. Almost Black Mirror-ish.

It doesn’t judge aesthetics. It doesn’t argue taste. It answers a simpler question: is this design complete relative to what we said we were building?

The shift this enables

Design review shouldn’t start in Figma.

It should start with intent.

When intent is explicit and traceable, visual critique becomes easier and more productive. Conversations move from “I feel like something’s missing” to “this requirement hasn’t been addressed yet.”

Superdesigner doesn’t replace designers. It reduces design regret, the kind that shows up late, costs time, and erodes trust.

Why this works inside Cursor

Cursor isn’t just an editor. It’s a thinking environment.

By keeping PRDs, research, review prompts, and outputs in one place, designers stay in flow. There are no dashboards to manage, no accounts to create, no abstraction layers to learn. Just files and agents doing their job.

That constraint is intentional. Review works best when it’s quiet, focused, and grounded.

How I’m sharing this

I’m open-sourcing Superdesigner AI as a template repository.

You clone it, star it, run it locally, and test it on a real project. I recommend starting small like one PRD, one flow, one review. Judge the feedback. Test different models.

See what it catches. More importantly, see what it misses.

That feedback is the point.

Got a design review or critique this week? Run this once and you’re set!

👉 https://github.com/sherizan/superdesigner-ai

Who this is for

This is for designers who care about craft, design managers reviewing multiple projects, founding designers balancing strategy and execution, and teams shipping fast with AI in the loop.

If you’ve ever looked at a design and thought, this seems fine, but something feels off, this tool is built for that moment.

What’s next

I’ll follow this up with a live YouTube build, deeper workflows that connect analytics (Amplitude MCP) before it generates the final design report (now that’s some Black Mirror stuff right there), and thoughts on how we can evolve this into a practice for modern design teams.

For now, try it. Break it. Tell me what it gets wrong.

That’s how this becomes useful.

I’ve been genuinely impressed with Google Gemini lately.

I’ve been testing their Deep Research feature for a while, and it’s surprisingly good at understanding context not just keywords. It doesn’t just scrape the web.. it actually knows where to look.

Including Reddit.

And if you want to understand what designers actually complain about, Reddit is where the unfiltered truth lives.

The Goal

I had two goals going into this:

1. Learn how to build a Figma plugin

2. Figure out real pain points Figma users are facing today

Not vibes.
Not Twitter hot takes.
Real frustrations, repeated by real users.

So I decided to put Gemini to work.

The Prompt I Gave Gemini

Here’s the exact prompt I used:

Read more

And the trio that unlocked it for me is:

Design Tokens → Figma MCP → Cursor.

This workflow completely removed the “prototype first” mindset and replaced it with something faster:

Design → Prompt → Build → Test.

No static flows.No endless handoff meetings. And zero guesswork for how something should feel on mobile.

Let’s break down exactly how I do it.

1. Start With a Clean Figma File

Here’s what we are going to build today:

I prepared two screens (one default state & one end state).

Here’s the baseline checklist I follow:

• Auto Layout everywhere

• All colors, spacing, radii, typography = tokens

• Real variants, not duplicates

• Logical naming: Button / Primary / Large

• No ghost frames

• No random 17px text sizes that “felt right at the time”

Because whatever is in Figma… becomes your code.

2. Activate Figma MCP (Your Design System Becomes an API)

This is where things get interesting.

Figma MCP turns your file into something AI tools can query:

• Tokens

• Components

• Variants

• Layer structure

• Metadata

Cursor can literally ask Figma:

“Give me the real Button component with real spacing, real radius, and the Light/Dark tokens.”

It’s API-level access to your design system.

This is the moment your design file stops being “a handoff document” and starts becoming infrastructure.

3. Cursor Generates a Full Design System Folder

Before any UI is built, Cursor does something magical:

It creates a full folder like this:

design-system/
  tokens.json

Clean, typed, structured.

This is the part that feels like cheating:

Your design system is now real JSON.
Not manually written.
Not reinvented.

Generated straight from Figma through MCP.

And Cursor will reference these tokens for every screen you build.

That’s where Cursor Rules come in.

Create a new rule under .cursor/rules

# Theme Rules

You are building a React Native Expo app.

- Always use tokens from `design-system/tokens.json` for colors, spacing, radius, typography.
- Never hardcode hex colors or random spacing if a token exists.

4. Skip Prototyping — Go Straight to Building in Cursor

This is where the workflow becomes addictive.

Traditionally, you’d spend days:

• mapping flows,

• designing static screens,

• prototyping interactions,

• presenting it all,

• revising,

• re-presenting…

But with MCP + Cursor: the build IS the prototype.

You can actually feel the UI on mobile instead of imagining it.

For example:

In my recent speed run, I built:

• Profile → QR Code navigation

• Plus → Close animated button

• 5 mini icons fading in sequentially

• Real touch interactions

• True mobile motion

• Zero manual code from me

Cursor built everything from my prompts + tokens

The results look and behave better than any Figma prototype because… they’re not prototypes.

They’re real mobile interactions.

5. The Prompt That Drives Everything

Because MCP exposes your design system, your prompts don’t need to be verbose. They just need to be structured.

Here’s my prompt:

Read more

Figma Make is great at generating components but terrible at reusing them across projects.

So I flipped the workflow.

Build everything once in Make, push to GitHub, then pull it into every new project with a single prompt.

It works beautifully.

The Actual Workflow (The One You Came Here For)

Step 1: Open new Make file

Prompt:

Create a UI Component Library with reusable components for Make prototypes.

Start with a base layout and we can add 1 component after.

• Design your components.

• Test them.

• Swipe them.

• Break them.

• Fix them.

Reach that moment when they finally feel “keeper” quality.

Step 2: Push them to GitHub

Here’s an example of a ToDo card component that I’d like to reuse.

Yeah. Literally export the component code, drop it into a GitHub repo, and commit. Let’s ensure its fully portable using your own design system CSS variables.

Prompt:

Before pushing to Github, ensure it is reusable and cleaned up for other projects to use

Your folder structure can look like this:

/components
  /cards
    ToDoCard.tsx <-- this is what we will commit to Github

Now you have a real design system.
Version controlled.
Portable.
Future proof.

Step 3: Pull components from GitHub in any new Make file

Go ahead and create a new Make file or go to your existing project.

This is the magic line:

Read more