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.

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

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

There was a time when every new idea started in Figma.

Open a frame.
Drop a layout grid.
Throw rectangles everywhere.
Try a font.
Undo. Redo. Undo again.

This week, I tried something different. I started with ChatGPT first then moving to Midjourney, a UI web library and putting it together with Cursor.

No Figma. No traditional design file.

Just prompts, components, and a browser tab.

The workflow felt natural. Faster. Lighter. Closer to how we think than how we design.

Here’s the full breakdown of how the website came together.

1. Planning with ChatGPT

Instead of wireframing, I started with a conversation.

“What’s the simplest way to build a clean landing page for my idea?”

Within seconds, I had:

• A rough site structure

• A narrative flow

• Suggested sections

• A content outline

• A quick list of supporting assets

This is where designers forget the real shift: AI is not replacing creativity, it’s removing the friction between the idea and the first draft.

Skipping Figma at this stage made everything faster. No frames. No rulers. No component hunting.

Just intent.

2. Generating the hero visuals with Midjourney

Next step: the aesthetic.

I asked Midjourney for a photorealistic vibe that matches the product.

Something that would make sense as a hero background.

Here’s the prompt:

Read more

Note: This reflection is mainly about how I prompt when I am prototyping or exploring ideas as a designer. It is not meant for full stack apps, BMAD methods, or agentic workflows. This is just what worked for me when I wanted to move fast, get something on screen, and iterate without overthinking architecture.

When I decided to build my Make prototype, I did the most natural thing any designer-turned-builder would do. I reached for a PRD. I wrote one that looked suspiciously similar to what PMs hand over in big teams, the kind filled with motivations, user stories, goals, expected outcomes, and a slightly dramatic paragraph about why this work matters. It felt right. Familiar. Safe.

Then I dropped it into Make (even with Gemini 3 Pro).

Make did not agree.

It read my PRD like a loose set of vibes and decided to assemble something completely different, the digital equivalent of a crooked IKEA shelf someone forced together at 3AM. At one point it built screens I never asked for, skipped things I did ask for, and even invented a “coach dashboard” that came out of nowhere. It was impressive in a slightly concerning way.

It was pure HALLÜCIN energy. A piece of furniture that technically stands, if you squint.

That was the moment I accepted the obvious truth. The PRD was not helping. It was too narrative. Too broad. Too philosophical. It was trying to describe the world instead of what needed to exist in the next 30 minutes.

So I deleted the whole thing.

I started over with the smallest possible description I could get away with. Something so simple it almost felt like cheating. This is exactly what I wrote:

Product description:
A Content Writer web app that helps you write customer responses, marketing copy for social media using botim's Tone of Voice.

Core feature:
- Show AI chat with 3 shortcut prompts
- Left panel navigation to show history of chats
- Header with botim logo

Requirements:
- Do not explain code
- Use latest Gemini 3 Pro model
- Keep it minimal, one page only for now

That was it.

And suddenly everything made sense.

Make behaved like a completely different person. It built exactly what I pictured, no more and no less. The hallucinations disappeared. The phantom features stopped. The imaginary architecture decisions went silent. I finally got the small thing I actually wanted, the version I could iterate on instead of the version I had to escape from.

Looking back, I am not sure why I expected a PRD to be a good starting point. It is something I am used to reading as a designer, not something I ever build from directly. A PRD is meant for alignment, justification, and context, not construction. I do not build Figma screens from PRDs either. I always start with one screen, one action, one thing the user sees. So why was I trying to make AI start from a complete narrative?

It makes more sense now. I work better when I collapse the problem into one step. Apparently AI works the same way.

There is something oddly comforting about that. Instead of trying to architect the universe in one prompt, I just let myself build the tiny version first and worry about the rest once something exists. It is the closest thing to flow I have had while building.

And honestly, the moment I stopped trying to make AI understand my entire thought process, everything became calmer. Simpler. Less dramatic.

No more HALLÜCIN shelves.

Just a small working app.

And a small win to build from.

If this is the new way I make things, I am fine with it.