I never got to open it.

By the time I sat down, Fable 5 was gone. Not throttled. Not waitlisted. Gone, for everyone. The message just told me to pick a different model.

What actually happened

Here’s the timeline, because the mechanism matters more than the drama.

About 76 hours after Anthropic shipped Fable 5, the public version of its Mythos model with safeguards bolted on, the U.S. government sent a letter. Friday, 5:21 p.m. Eastern. An export-control directive citing national security.

The key detail is who it covered. The order applied to any foreign national, inside or outside the country, including Anthropic’s own foreign-national employees. There’s no clean way to enforce that selectively, so the practical effect was to switch the model off for everybody. U.S. customers included. No warning, no appeal.

Anthropic complied and then disagreed in public, which is not a common move. Their read: the letter didn’t spell out the actual concern, and their best guess is the government believes someone found a way around Fable’s safeguards. Their position is that blocking a deployment should be transparent and grounded in technical facts, and this wasn’t. They called it a misunderstanding and said they’re working to restore access.

Aaron Levie called it a turning point: a government deciding a model is too powerful to be public. Whatever you think of the call, that’s a precedent now.

Subscribe now

The demos changed my mind

A week ago I’d have told you AI mostly helps us execute faster. Then I watched the weekend’s footage, and the thing that shifted wasn’t speed. It was quality of the first draft.

Start with Gary Simon, who’s been running these model-preview tests for years.

He gave Fable five prompts. One shot each, no back-and-forth.

• An awards-worthy portfolio page. GSAP and 3JS, scroll-based animation, a split-character effect on the headline. His verdict: the best one-shot UI he’s ever pulled from any model. Not “good for AI.” Best.

• A 3JS gallery scene, rebuilt from a screenshot and a URL. The kind where you stand inside a sphere looking at a wall of work. It came back close.

• A better hero section for his own SaaS. Fable spawned a Figma MCP agent and handed back a version worth A/B testing against his live one.

• Craigslist, modernized. Still type-heavy, still dense, just better spacing and a few subtle hovers. Craigslist if it had quietly woken up in 2026.

• An award-winning interactive site, rebuilt from a video. Not a screenshot. A video. It even got the ending sequence right. Not as good as the original, but it followed the brief.

  

The line from Gary that stuck with me: take 100 designers, give them all the same model, and roughly 10% still produce the best 10% of the work. The floor went up. The ceiling is still you.

The build that reframed it

The demo that actually moved me wasn’t a landing page.

Todd Sanders was on a customer call with Claude transcribing in the background. As the customer described features they wished they had, the model built them. By the end of the call he showed a working product matching a workflow the customer had described fifteen minutes earlier. The build was triggered by a sales conversation, not a ticket.

Two more in that vein. Riley Brown rebuilt Lovable, the product, not the marketing page. And Greg Isenberg showed an Anthropic employee editing a full launch video with Fable: transcribe the takes, pick the best ones, cut the filler words, color grade, stitch the final cut. An afternoon of work, mostly gone.

The price

Fable is not cheap, and you should know the numbers before you get excited.

The Lovable rebuild ran around $200 to $300 on nine or ten prompts. Running Mythos hard through the API got put at $300 to $600 an hour. Do the boring math: $600 an hour, a 40-hour week, and you’re at $1.2 million a year in tokens.

Pat Simmons’ smaller builds were saner:

• RollerCoaster Tycoon clone: ~$19

• Full e-commerce site: ~$37

• Interactive 3D museum: ~$64

So the rule writes itself. Don’t redesign a button with this. Use it when it replaces days.

Fable vs Opus 4.8

Pat ran them head to head. Same prompt, one shot, no revisions. Fable won almost every round.

E-commerce was the clearest. Opus built a store that worked. Fable built one that looked like a premium Shopify site, with better hierarchy, stronger visuals, and noticeably better image generation. Same pattern on a 3D museum, an Age of Empires clone, a RollerCoaster Tycoon game.

Working in both. Finished in one.

What designers should actually notice

The interesting part isn’t that AI can generate UI. We’ve had that for a while. It’s what kind of UI it generates now.

Three things showed up in every demo:

• The layouts have stopped looking like generic component libraries.

• The animations are subtle instead of needy.

• The visual hierarchy is often good enough that I wouldn’t tear it down and start over

That last one is the shift. The first version used to cost you hours. Now it’s close to free, and the hours move to where they’re worth more: improving it, validating it, cutting it down. AI isn’t replacing taste. It’s making the rough draft cheap.

The reaction nobody expected

While designers were screenshotting demos, a different crowd got spooked.

One builder spent the entire weekend moving his work to local models, and his takeaway was the opposite of mine: don’t build your business on something a single letter can switch off. Own part of your stack. The generator-in-the-garage argument. He has a point. The same week that made execution feel free also showed how fast access can vanish.

And plenty of people decided the ban was staged. Mythos was too expensive to run for everyone, the theory goes, so Anthropic excited the crowd and yanked it, government as cover. Maybe. But the letter is public and Anthropic is publicly fighting it, which is a strange way to run a marketing stunt.

The honest takeaway

A week ago I thought AI was mostly helping us go faster.

After this weekend I think the real change is somewhere else. Execution is getting cheap. Judgment is getting valuable. And there’s a third thing the ban dragged into view: durability. The best first draft in the world doesn’t help you if you can’t open it on Monday.

And the most honest line I’ve got? I still haven’t touched Fable myself.

If this was worth your time, forward it to one designer who’s still arguing about whether any of this is real.

Not because it was entertaining (though it was). Because buried inside three live demos was something that reframes the entire design workflow.

This wasn’t a feature announcement. It was a new mental model.

▶️ Watch the full demo first: Figma Release Notes 2026: May Edition

What’s in this piece

1. 🔄 How to bring a vibe-coded prototype into Figma as design frames with one prompt

2. 🎨 How to sync your design system between code and Figma automatically

3. 🧠 How an agent explores new design directions using your actual components

4. 🛠️ How to actually set it up, step by step

The big idea first

Figma shipped an MCP server.

MCP stands for model context protocol. It’s how AI agents talk to other software. In this case, how Cursor, Claude Code, or any coding agent talks directly to Figma.

What that means in practice: your agent can now read your Figma layers, write to the canvas, pull your design tokens, and push changes back to code. In both directions. In real time.

Three workflows. All built on this one foundation.

Subscribe now

How to set it up (do this first)

Open Cursor. Go to Settings → Plugins. Search for the Figma plugin. It appears under suggested options. Click Add to Cursor. This installs the MCP server and all the pre-built skills.

One more step. Go to Tools and MCP in Cursor settings. You’ll see the server listed but needing authentication. Click Connect. A browser tab opens asking you to log into your Figma account and allow access. Click Agree.

That’s it. You’re connected.

Two things worth knowing before you move on:

• If you installed the MCP server before March 24th, update it. The new workflows won’t work on the old version.

• If the browser tab doesn’t open automatically, the agent likely failed silently. Check Figma’s help center for detailed installation steps.

Once connected, skills are called by typing /skill-name in your agent prompt. The agent will also use the right skills automatically based on what you ask.

Workflow 1: vibe-coded prototype → Figma canvas

The skill: /prototype-to-figma

A PM builds a fintech onboarding flow using an AI agent. It works. Real interactions, real screens. But it looks AI-generated. Cluttered. No craft.

Old path: rebuild every screen manually in Figma from scratch.

New path: in Cursor, type /prototype-to-figma and point it at your running localhost prototype. The agent reads each unique screen, pulls them onto the Figma canvas as design frames, adds interaction annotations, and generates a flow overview describing what you’re looking at.

Then the designer gets on the canvas, removes the redundant UI, swaps in real design system components, and gets to a version worth sharing in minutes, not hours.

How to run it:

1. Have your prototype running on localhost

2. Open Cursor and type: /prototype-to-figma use this on the prototype running at localhost:3000

3. The agent pulls each screen to canvas with annotations

4. Iterate directly on the canvas from there

The vibe-coded prototype was the starting point. The canvas was where the actual design decisions happened.

Workflow 2: code → design tokens → Figma variables

The skills: figma-generate-design + figma-generate-library

A developer builds a dark mode version of an app entirely in code. Looks solid in localhost. But nobody knows how it holds up across the rest of the product.

These two skills come pre-installed with the MCP server. No manual setup needed.

The agent pulls the dark mode onto the Figma canvas, extracts all tokens, generates a stylesheet, and populates the variables panel. Light mode and dark mode, side by side, fully mapped.

The designer looks at it on canvas and immediately catches two things the code review missed. Brand yellow is too aggressive in dark mode. Tertiary text is failing accessibility contrast.

Opens variables panel. Swaps one colour. Updates one token. Pushes refined variables back to the codebase.

How to run it:

1. In Cursor, prompt: Use figma-generate-design and figma-generate-library to bring my dark mode from localhost onto the Figma canvas and extract all design tokens

2. Review the generated stylesheet and variables panel in Figma

3. Make your design decisions on canvas

4. Push refined variables back to code from the same agent session

Full round trip. Design decision made on canvas. Consistent across the whole product.

Workflow 3: agent explores directions using your real components

The skill: figma-use-scale

A dashboard has a problem. Renewal health status is buried at the end of each row. User research confirms it. Nobody can find it.

The designer could sketch five different solutions. Building each one manually in Figma takes time.

One prompt to the agent, with the research insights pasted in. The figma-use-scale skill reads the production components directly from the canvas and generates rough direction explorations using the actual design system. Not generic AI UI.

The output isn’t finished. But it’s enough to react to. One direction is clearly stronger. The designer refines the header component, adjusts colours, and gets to a shareable direction in a fraction of the time.

How to run it:

1. Have your Figma file open with your production components

2. In Cursor, prompt: Use figma-use-scale on [frame link]. Here's the user research: [paste insights]. Explore ways to make renewal health status more prominent

3. Review the directions on canvas

4. Pick the strongest one and refine by hand

The agent got past the blank canvas. The designer made every call.

The pattern behind all three

Figma said it directly at the end of the demos:

Every workflow followed the same arc. The agent handled the scaffolding. Pulling screens, extracting tokens, generating rough directions. Fast, tedious work that used to eat hours.

Then the designer stepped in. What’s too cluttered. What fails accessibility. Which direction is stronger. Why one colour works and another doesn’t.

The agent got faster. The designer’s judgment got more important. Not less.

What actually changed

• 👉 Setup takes 5 minutes. Cursor → Settings → Plugins → Figma → Connect.

• 👉 /prototype-to-figma pulls a vibe-coded prototype onto canvas as editable frames.

• 👉 figma-generate-design + figma-generate-library sync tokens between code and Figma variables. Both directions.

• 👉 figma-use-scale explores design directions using your real components. Not generic UI.

• 👉 The agent handles scaffolding. The designer still makes every call that matters.

Not because the demos weren’t impressive. They always are.

But demos are picked. Best 1 in 20. The other 19 stay hidden.

So I ran my own test. Three real scenarios. Same prompts, same images, two tools side by side.

I went in expecting “interesting but not useful.”

I came out thinking differently.

What’s in this piece

1. ⚡ How prompt detail changes everything

2. 💀 Where adding objects into a photo quietly breaks

3. 🧭 The most useful test for designers

4. 🛠️ The honest winner after all three rounds

Test 1: prompt detail

A man standing next to a rally car. Nice outfit, real location.

The brief: replace the car with something more premium. Change the background. Adjust the pose.

I ran the same test three times with increasing prompt detail.

The result from both tools was fine. The pose changed. A more premium car appeared. Both did the job.

Then I added specifics. The exact car. The outfit to keep. The new environment. The lighting direction. The photorealistic style requirement.

Both tools handled the pose change naturally. The man’s weight shifted believably. The new car sat correctly. Side by side, the only real difference was taste.

I added even more detail on the third pass. Nano Banana started to look more fake. ChatGPT held up.

Both passed this test. The gap was small.

Test 2: adding objects to a photo

An espresso shot on a dark green surface. Good light, strong shadow.

Harder than it sounds. Objects need to match the light source. Shadows need to go the right direction. The scale needs to feel like everything was shot together.

ChatGPT placed both objects in believable positions. But the espresso shadow was wrong. The can sat at the wrong size.

Nano Banana got the can size and shadow closer to right.

Second round. An image of open hands. Add a Five Guys meal: bag, burger, branded wrapper.

AI is still not friends with hands. Neither version landed. Judge for yourself.

Test 3: UI from the reference

This one mattered most for my work.

I took a profile card UI. Simple layout, clear visual identity. I asked both tools to generate a new screen in the same style.

ChatGPT produced a Loyalty Card. Type hierarchy matched. The card structure felt consistent. The colour logic carried over. Side by side, they looked like the same product.

Nano Banana stayed closer to the original layout but missed the UX. The brief was "loyalty card." What it returned was the profile card with different text.

Test 4: UI from a reference

I gave both tools an existing mockup and asked them to apply Anthropic’s branding.

ChatGPT found the logo and the colour palette on its own. Nano Banana didn’t.

What actually worked

• 👉 ChatGPT and Nano Banana are roughly equal for raw image editing. Pick by taste, not capability.

• 👉 Neither one handles hands. Both fall apart when fingers are in the frame.

• 👉 ChatGPT wins on UI and context. It read the brief, not just the layout.

The honest take

Now I use ChatGPT for two things.

Mockups: I pull a Pinterest reference and drop my work into it.

UI exploration: I take a reference screen and generate new concepts in the same style.

The tool earned its place in the workflow. That’s all the verdict I needed.

This time, it might actually be worth paying attention.

On April 16, Anthropic shipped Claude Design a tool that lets you build prototypes, landing pages, slide decks, and marketing assets through conversation. No canvas. No layers panel. Just prompts. Figma’s stock fell 4.26%the day it launched.

What Claude Design actually is (and what it isn’t)

1. ⚡ Where it genuinely surprised me

2. 💀 Where it completely broke down

3. 🧭 The honest answer to “should designers be worried?”

4. 🛠️ How I’d actually use it in a real workflow

What Claude Design actually is

Let’s get the architecture right before the hot takes.

Claude Design is not a canvas tool. There are no layers, no components, no Booleans, no auto-layout. What it is: a conversation interface on the left, a live preview on the right. You describe what you want, Claude builds it, you iterate in chat.

The output is primarily React + Tailwind code rendered live. Not a .fig file. Not an artboard. Running HTML in a browser window.

The surprise

Once I opened Claude Design it asked me to provide Figma files or a Storybook URL to create a UI library. That’s cool, it means it can save a lot of time.

What Claude Design captured well: logo, colours, input fields, shadows, spacing system. What was completely off or not captured: most UI components, colour variants, icons. I’d score the extraction 4 out of 10.

Something I really liked: the Needs Review section. It lets you quickly flag what’s not working. In the provided example, the navigation bar had the right shape and active state , but all the icons were off.

What’s good: Claude Design works proactively. Once you mark something as “needs work,” it opens a new tab and asks a clarification question. In my case it asked where it could get the correct icons.

This is a really good starting point for defining the foundation. I liked it, but considering my Figma file has all components and all variables set up, it should convert more of it.

The test

I asked Claude Design to do two things using the established design system:

• Design a notification screen for a mobile application

• Design a payment card management journey for a mobile application

New feature, Tweaks: Claude Design offers layout variations. This is a nice feature for exploration because it lets you test several directions quickly. In my case it was redundant, I already have an established UI library.

In both cases it generated ideas that were too complex with information, but I didn't provide any rules, so that's fair.

Speed from zero to something is real. But as a designer or builder, you lose a valuable skill when you skip exploration. When you go to Dribbble, Pinterest, read research, explore products, you learn what's best for you and your product. When you rely only on generative AI, you need to understand what you're using it for: to explore, to save time, to build new concepts quickly.

What is clearly bad: attention to detail. If we're not evaluating content or features but purely UI, the same mistakes as a few months ago with other AI tools. Font weights, spacing, colour and hierarchy. Attention to detail is still missing.

Tool is a tool

Few month ago I wrote article which design tool design the best . And I wrote

AI can speed up design work, but without a designer’s judgment to define, guide, and refine what “good” looks like, it won’t produce great products, so the best approach is using both together.

My current workflow for 2026 looks like this:

1. I generate ideas through Figma manually and AI Claude

2. The best versions I decide add convert them to Components

3. Then I use Figma MCP and Cursor to build prototype

4. Prototype allows experience real product experience and lately has become only how I present my work to clients, what I can see they provide feedback 30x faster then looking in Figma file

5. Then I go back to Figma to prepare all files for Front end handoff using Figma build in features “ready for dev“ to track changes, annotation to explain states, behaviour, exceptions.

While most AI conversations focus on models, a quieter infrastructure shift is happening underneath.

Model context protocol.

MCP.

Developers often describe it as the USB-C of AI.

Before MCP, connecting AI systems to tools required custom integrations. Every database, API, or service needed its own connector.

This created enormous complexity.

MCP introduces a shared protocol allowing AI agents to communicate with multiple systems using a common interface.

An AI system can access documentation, query databases, interact with APIs, or connect to enterprise tools through one standardized structure.

This dramatically simplifies integration.

But the power of MCP also introduces serious risks.

Security researchers have already warned that poorly secured MCP servers could expose credentials or allow remote code execution.

That makes MCP a cross-disciplinary problem.

Developers must build secure servers.

Product managers must decide which integrations provide value.

Designers must ensure AI actions remain visible to users.

If an AI silently reads customer data or sends emails automatically, trust disappears instantly.

Organizations adopting MCP often begin with low-risk scenarios.

For example connecting AI to internal documentation in read-only mode.

Once monitoring and approval flows exist, more powerful integrations can follow.

The future of AI will likely involve networks of agents interacting with many systems simultaneously.

Protocols like MCP make that possible.

But connectivity without governance can quickly become dangerous.

Subscribe now

A tool that claims it can run interviews, screen participants, collect feedback, and generate insights automatically.

The benchmark: real user research.
If it felt like a thoughtful researcher, it passed.
Simple.

Why this matters

User research is expensive.
A researcher can cost $6–15K per month.
AItools? $20–200 per month.

Naturally, people ask:

“Can ai replace researchers?”

Fair question.
So I ran the test.

The setup

The tool was Genway.ai.

I pasted my Snapfast.ai brief into the box.

I’m testing Snapfast.ai, a tool that helps salespeople prep for meetings in minutes.
Paste a url. Get pricing, features, feedback, comparisons.
Looking for honest input from early users.

Genway instantly generated:

• Project objectives

• Topics

• Outcomes

• Interview guidelines

It let me choose the interview mode: voice or typing.
Typing felt smart.

The whole setup felt clean and modern.

So far so good.

The wall

Snapfast is new.
No users yet.
Ideal for cold interviews.

But Genway didn’t make it clear how participants could access the product during the interview.

I tried three setups.
Same issue.
The only option was a screener question.

“Have you used Snapfast.ai?”

Everyone said no.
Useless.

The moment that worried me

I ran a test interview myself.
I told the AI:

“I’ve never used Snapfast.ai.”

It responded:

“I see. Could you share what drew you to consider using it in the first place?”

This was strange.

It sounded thoughtful.
But it wasn’t logical.
It didn’t match the context.

Good enough to feel human.
Not good enough to be human.

That’s the danger zone.

Friends tried it too

I sent the interview to a few friends.

Their reaction:

“Eddy, this is frustrating.”

Example:

Friend: “I like the one click login.”
AI: “What exactly did you like?”
Friend: “The one click.”
AI: “What do you see in the login?”

They felt interrogated.
Not understood.

Conversation loops kill good feedback.
AI couldn’t adapt.

The insight generation problem

The insights looked polished.
But not credible.

Example of an AI-generated summary:

A recurring theme among users is appreciation for Snapfast.ai’s streamlined onboarding, such as one click sign up and intuitive interface, which encourages continued engagement.

No one said that.
It just sounded like something that “should” be in a research report.

Pretty.
But inaccurate.

The results

Content:
AI nailed the basic structure.
Questions. Flow. Notes.

Style:
It sounded confident.
But not grounded in reality.

Usability:
Great if you have real users.
Weak for early-stage testing.
Weak for nuance.
Weak for emotion.
Weak for context.

The verdict

Can AI replace researchers?
Not yet.

AI is great at:

• Setup

• Admin

• Scheduling

• Running the script

• Sorting answers

AI is bad at:

• Detecting frustration

• Understanding product maturity

• Adjusting questions

• Spotting contradictions

• Knowing when something “feels off”

• Producing credible insights

AI replaces mechanics.
Humans handle meaning.

Researchers who only run scripts should worry.
Researchers who think deeply are safe.

What I’d actually do

If you are building a product today, don’t hand everything to AI.
But also don’t ignore it.

Use AI for speed.
Use humans for judgment.

AI can help you:

• run interviews

• get rough insights

• structure feedback

But you still need someone who knows when something feels off.
Who can sense hesitation.
Who can tell the difference between a real insight and ai-generated filler.

That combination, AO for efficiency, humans for meaning, is the sweet spot.

It’s not AI or researchers.
It’s both doing what they are best at.

👉 Subscribe to Practical by AI
Get one practical post each week.
Learn how to build better products in the age of ai.

We rely on AI for fast answers.
But fast answers are not the same as accurate ones.
This becomes obvious the moment you ask AI about something that actually requires precision, like pricing.

That is exactly the test I ran.

The setup

I asked three tools the same thing.

“Cursor pricing.”
“Claude pricing.”

No links.
No screenshots.
Just the names.

Then I checked the real pages myself.

And I extracted the real data with Snapfast.ai.

The difference between “AI confidence” and “actual accuracy” became very clear.

What ChatGPT got wrong

ChatGPT didn’t read. It predicted.

That means it filled the gaps with what pricing pages usually look like.

For Cursor it:

• Invented usage based billing

• Missed the sixty dollar Pro plus tier

• Missed the two hundred dollar Ultra tier

• Flattened everything into “free, pro, higher tiers”

For Claude it:

• Mixed subscription pricing with API tokens

• Renamed the product to “Claude Code pricing”

• Turned real features into vague phrases

• Ignored usage multipliers, team pricing, and real plan details

The response looked polished.
It wasn’t accurate.

What Perplexity got wrong

Perplexity gave more detail.
But it also invented details.

It confidently listed team pricing, token costs, tier ranges, and feature distinctions that weren’t tied to the real subscription pages at all.

It still skipped the sixty dollar tier.
It blended API pricing with subscription pricing.
It mixed annual and monthly numbers inconsistently.

More detail doesn’t mean more truth.

What Snapfast.ai got right

Then I ran the same pages through Snapfast.ai.
This time the output was factual.

Snapfast.ai captured:

• Every Cursor tier exactly as shown

• Hobby, Pro, Pro plus, Ultra

• Real monthly prices

• Team and enterprise details

• Free trials

• Add ons like Bugbot

• Real feature differences

And for Claude it captured:

• Free, Pro, Max exactly as listed

• Seventeen dollar annual billing

• Twenty dollar monthly

• One hundred dollar Max

• Usage multipliers

• Research mode

• Workspace integrations

• Team pricing at thirty dollars per user

• Actual messaging from the real page

No predictions.
No hallucinations.
Just the facts.

You can find the whole analysis here.

What Snapfast.ai is

Snapfast.ai is a competitor research tool built for accuracy.
You paste a URL. It pulls the real page. It shows you what the company actually says, not what AI imagines.

You get side by side comparisons in minutes.
Pitch, pricing, positioning, features.
All based on real screenshots so you never rely on hallucinated data.

It is built for clarity. One dashboard instead of fifteen tabs.
It is built for speed. Paste a URL, get insights, move on with your day.
It is built for proof. Real screenshots, annotated insights, and what companies actually publish.

Sales prep. Vendor comparison. Partner research. Market scan.
Everything in one place.

The lesson

ChatGPT is fast.
Perplexity is confident.
Neither is reliable with real numbers.

Snapfast.ai is built for accuracy, not guesses.

If you want a rough explanation, ask AI.
If you need the real data, use Snapfast.ai.

Because the biggest risk today isn’t slow research.
It is wrong information said with confidence.

Subscribe now

If you are thinking about using Lovable to build your first real product, this is for you.

I built a full app with it. I felt the magic. I felt the pain. And I learned the lessons no onboarding flow tells you.

By the end of this article, you will know what Lovable does well. Where it breaks. How to avoid the biggest mistakes. And how to build something real, even if you have never written a line of code.

Let’s start.

The promise of Lovable

You open Lovable. You type a prompt. And suddenly your idea becomes real.

Pages. Buttons. Database. API. Deployment.

Done in minutes.

It feels unbelievable when you are new. It feels like the future. And it is the future.

I built a full competitor analysis tool this way. Scraping. Enriching. Comparing. Summarizing.

Try it at snapfast.ai. Lovable helped me build something I would not have built alone.

But there is a part no one tells you.

The hidden truth

Lovable gives you exactly what you ask for. But it also does things you did not expect. Sometimes things you did not want.

If you have never used Lovable before, remember this:

The tool is powerful.
But it is unpredictable.
And if you do not guide it well, it will break parts of your app.

Here is what I learned.

Lesson 1. Your first prompt will not get you what you imagine

You may think the AI understands your whole idea. It does not.

It understands your words, not your vision.

Good apps come from clear prompts, small steps, and many iterations.

Lesson 2. Every improvement can break something else

I asked for better analysis quality. Lovable deleted my screenshot logic.

I asked for speed. It added screens that slowed everything down.

Your job is not to fight this. Your job is to expect it.

Lesson 3. Never trust the AI to protect your architecture

Sometimes Lovable rewrites what you have. Sometimes it merges files. Sometimes it removes logic without telling you.

If you are new, this feels confusing. If you expect it, it becomes manageable.

Lesson 4. The bigger your app gets, the more careful you must be

Early changes feel harmless. Later changes can break workflows.

This is where clarity matters most.

Lesson 5. Always save versions

Before each big prompt. Before each refactor. Before each new feature.

Copy the files. Download the repo. Protect the logic you care about.

It will save you hours.

Lesson 6. Keep prompts small

Do not say “Improve everything.”
Do not say “Rewrite the logic.”

Say “Add this step.”
“Fix this specific bug.”
“Update only this function.”

Small prompts. Small surface area. Small risk.

Lesson 7. Treat Lovable like a junior developer

Not a wizard. Not a genius. A junior.

Clear instructions. Clear constraints. Clear role.

And review everything.

Lesson 8. The tool is fast, but debugging is your responsibility

You will fix bugs. You will test flows. You will learn architecture, even if you never planned to.

This is good. It makes you a better builder.

Lesson 9. The AI will always say “yes”

Even when it should say “no.” Even when your request makes no sense.

This means one thing. Your intention must be clear. Your boundaries must be clear.

Lesson 10. Visual changes are painful

Move an icon. Change a background color. Adjust spacing.
Surprisingly difficult to get right.

The shift that changed everything

Things got better when I realized this:

AI builds fast. I build well. Together, we build right.

Once I stopped expecting Lovable to read my mind, everything clicked.

I rebuilt the system with small changes. I used background tasks. I added retries. I added credit refunds. I optimized the database. I cleaned the UI. I gave the AI context.

The app became stable. Reliable. Production-ready.

And I became a better builder.

If you have never used Lovable, read this twice

You will make mistakes. You will break things. You will rewrite things. You will get frustrated.

But you will also build something real. Faster than you ever imagined. Faster than any “learn to code” course. Faster than any startup hackathon.

Lovable gives you speed. You give it direction. That is the real partnership.

Why I still pay for it

I love Lovable. I hate Lovable. I pay too much for Lovable. And I will use it again tomorrow.

Because I built a real app. People use it. It works.

And without Lovable, I would still be stuck at the idea stage.

That alone is worth everything.

What I built

I built Snapfast. A complete AI-powered competitor analysis tool. It turns hours of research into minutes.

The goal is simple. Help product teams, founders, and marketers get instant clarity on any competitor.

Competitor research in five minutes

You paste a URL. Snapfast pulls the data. You get insights on pricing, features, messaging, audience, positioning, and more.

It finishes in about two minutes. You get a clear picture without digging through ten different tools.

Built for clarity

Everything sits in one clean dashboard.

You see real screenshots. Messaging. Pricing. Product structure. Value proposition.

Every insight is backed by proof. Not guesswork.

Designed to finish fast

Paste a URL. Get the insights. Move on with your day.

You get a full breakdown. Hero page comparison. Target audience. Pricing strategy. Product features. Growth signals. Customer evidence. All in one place.

Built for teams

Snapfast works for every role.

• Founders get clarity fast and spot positioning gaps.
• Marketers study competitor messaging to sharpen their own.
• Product teams compare features and find differentiation.
• Agencies walk into client meetings fully prepared.
• Sales teams reduce four hours of research to four minutes.

Flexible pricing

No subscription. No sales calls. Credits never expire.

Pick a plan. Get full access. Start analyzing.

The real takeaway

Building Snapfast taught me something simple. Lovable is not the hero. You are.

The tool gives you speed. It gives you momentum. It gets you from zero to something real in record time.

But you shape the product. You bring the clarity. You fix the breaks. You make the decisions that turn an AI draft into something people actually use.

Snapfast exists because Lovable made the first version possible. It became a real product because I kept iterating, testing, and improving what the AI started.

That is the part no one talks about. The partnership.

Lovable builds fast. You build well. Together, you build right.

So if you are about to create your first product, expect the chaos. Expect the bugs. Expect the rewrites. But also expect the moment when it all clicks.

Because that moment is worth it.

And if you want to see what that looks like in the real world, take a look at Snapfast. It is proof that a clear idea, a fast tool, and a bit of stubbornness can turn anyone into a builder.

One prompt at a time.

The benchmark: Asana’s mobile app.
If it looked like Asana, it passed. Simple.

Why this matters

Designers are expensive.
A senior product designer can cost $8–15K/month.
AI tools? $20–200/month.

So naturally, everyone’s asking:

“Can AI replace product designers?”

Fair question. So I ran the test.

The setup

I tested three tools:

• Loveable (Gemini 2.5 Flash)

• Figma Make (Claude Sonnet)

• V0 (v0-1.0-md)

Each got the same prompt:

Design a modern iOS-style mobile task management dashboard with clean, minimalist aesthetics. Use white background, light gray cards, black text, and blue accents for primary actions.

Layout Structure:

1. Status Bar & Header
iOS-style status bar with time, connectivity, and battery icons
Date display: “Fri, 15 November”
Personalized greeting: “Good morning, Sam”

2. Upcoming Task Card
Label: “A task is due in 3 days”
Rounded card containing: Task name: “Get organized with sections”
Due date badge: “Mon” with circular avatar icon showing “SL”
Blue button: “View task” with eye icon

3. Recents Section
Heading: “Recents”
Vertical list of completed tasks with checkmarks:
Add task 2
Get organized with sections
Task 1
Follow up on “Task 1”
Social Media Teasers

4. Projects Section
Heading: “Projects” with dropdown showing “Recents”

5. Bottom Navigation
Five tabs: Home (highlighted), My tasks, Inbox, Search, Account
Icons above labels

Design Direction:
Rounded corners on all cards and buttons
Soft shadows on cards
Minimalist, flat design
Modern sans-serif typography
Consistent spacing throughout
Clean visual hierarchy

The results

Content:
All three nailed the structure.
Status bar, greeting, task card, recents, projects, navigation. All there.

Style:
Here’s where it got interesting.

I wanted to see if these tools could improvise.
Not just follow instructions.
Because “modern” and “iOS-style” are vague. They leave room for creativity.

The style requirements were simple:

• Modern iOS-style mobile layout

• Light gray cards

• Black text

• Blue accents for primary actions

All three handled the details well.
Things like black text and color balance, nailed.
But when it came to modern feel and iOS polish?
That’s where they stumbled.

You could see the difference right away.
None of them really captured that Apple-level spacing. Those smooth shadows. The finesse in motion.
It felt close, just not quite there.

The verdict

Still, the UIs looked solid.
The main differences showed up in two places:

1. Upcoming task card

2. Vertical list of completed tasks

In Asana’s real app, the upcoming task has a small bullet on the left. A subtle cue that adds balance. All three AI tools missed that.

The order of elements also varied slightly between them.
Some had the button first, others the text.
Tiny things, but that’s design. The tiny things are the difference.

And in the Recents list, the color of completed tasks really stood out.

• Loveable: used a green tone for completed tasks, better icons, and spacing that just felt right.

• V0: nearly identical, but less refined.

• Figma Make: clean, but off on font weights.

Let’s be honest. Figma Make lost by milliseconds.
Most people wouldn’t even notice the font weight difference.
But when you’re testing against Asana, those milliseconds count.

🏆 Winner: Loveable.

It wasn’t just prettier. It understood design choices better.
The icons made sense, the hierarchy felt natural, and the screen looked ready for production.

The $10,000 question

Can AI replace product designers?
Yes... but only if the person prompting has design sense.

You still need to know what “good” looks like.
That green means success.
That spacing changes readability.
That hierarchy drives flow.

My recommendation

Don’t choose between AI and designers.
Use both.

Designer: defines goals and intent
AI: generates options fast
Designer: refines and makes it great

That’s how you build better products faster.

👉 Subscribe to Practical by AI
Get one practical post every week. Learn how to build better products in the age of AI.

Subscribe now

Everyone says “AI can review your design,” but what does that actually mean?
Does it think like a designer? A marketer? A robot?

I ran an experiment to find out.

Results Shortcut

Landing Page

• Claude gave the most structured, agency-style audit.

• ChatGPT was clear and practical.

• Gemini thought like a marketer, focused on conversion.

• Perplexity followed the rules but missed nuance.

• Grok delivered fast, visual hot takes.

Checkout page

• Claude understood systems and user logic best.

• ChatGPT balanced clarity with empathy.

• Gemini focused on task flow and usability.

• Perplexity stayed methodical but mechanical.

• Grok caught quick layout issues at a glance.

The Setup

I used two screenshots:

1. A landing page (a fintech homepage)

2. A billing dashboard

Then I gave the same prompt to:
ChatGPT, Claude, Gemini, Perplexity, and Grok

You are my design auditor to conduct a product audit.

Context:
- Goal: assess the design quality and UX consistency of the provided screenshot
- Audience: non-designers, not deeply technical
- Constraints: audit is based only on one screenshot (no Figma or live prototype)
- Deliverable after we decide: a 1-page audit summary including key issues, quick fixes, and recommendations

Instructions (in order):
1) OPTIONS: Suggest 3 possible audit approaches with brief pros/cons and key risks (≤6 bullets total).
2) RECOMMEND: Choose ONE approach based on clarity and impact; explain your reasoning in 2 lines.
3) DRAFT: Create the 1-page audit summary for the selected approach.

Output rules:
- Start with a 1-line plan (“compare → recommend → draft”).
- Use concise bullets; list any assumptions if context is missing.
- End with the draft and a 3-item verification checklist.

The magic: it forces every AI to think like a UX consultant — compare → recommend → deliver.

Most people ask AI: “What’s wrong with my design?”
That’s too fuzzy. You get surface-level tips.

This version creates a thinking pipeline:
Explore → Decide → Deliver.
It reveals how each model reasons and what it prioritizes.

Landing page audits

ChatGPT.

It chose: “UX Clarity & Information Hierarchy Audit.”

Example Output

“Subheadline lacks contrast; CTAs (‘Get Started’) blend into background.
Fix: Increase text contrast and use one primary CTA color.”

“Stats look secondary despite being strong trust signals.
Fix: Enlarge numbers, add icons, use lighter background separation.”

ChatGPT writes like a senior designer in Slack: direct, actionable, readable.

Verdict: Fastest to implement; great for PMs and non-designers.

Claude.

Claude blended user journey + visual consistency.
It wrote a complete audit with prioritization and hierarchy.

Example Output

“Typography inconsistency [HIGH IMPACT] — multiple font sizes/weights without clear hierarchy.
Fix: Establish 3-tier type scale (H1/H2/Body) and apply consistently.”

“Visual clutter [HIGH] — Core Features list + phone mockup compete for attention.
Fix: Simplify to four items max; unify background colors.”

It even gave a checklist and executive summary.
Structured, credible, professional.

Verdict: Most senior-level; use for strategic UX reviews.

Gemini

Gemini ignored polish and went straight for ROI.

Example Output

“Weak Above-the-Fold Value Proposition.
The headline is descriptive, not benefit-driven.
Replace with: ‘Invoice Globally. Pay Zero Tax Fines.’”

“Scattered CTAs create choice paralysis.
Make ‘Get Started for FREE’ the only high-contrast button.”

Gemini speaks in business KPIs, not pixels.
Sharp and persuasive, but less visual.

Verdict: Ideal for growth teams optimizing landing pages.

Perplexity

It ran a classic Heuristic Evaluation.

Example Output

“Visual hierarchy inconsistencies make it hard to distinguish important elements.
Add visual separators between sections.”

“Accessibility concerns: insufficient contrast in some text/icons.”

Spicy, fast, but shallow.
Good eye, no depth.

Verdict: Great for early creative reviews, not final audits.

Grok

Grok writes like Twitter.

Example Output

“Overloaded hero: four competing messages fight for attention.
Typography chaos: six font weights in hero alone.”

“Simplify hero — one headline + CTA. Unify feature cards with white backgrounds.”

Spicy, fast, but shallow.
Good eye, no depth.

Verdict: Great for early creative reviews, not final audits.

Landing page leaderboard

1. Claude
Best overall. Structured, detailed, and balanced. Thinks like a UX consultant.
If you want an audit that reads like a $10K design report, this is the one.

2. ChatGPT
Most actionable. Clear, concise, and human. Explains issues in simple language.
Perfect for PMs or founders who need quick, practical fixes.

3. Gemini
Best for growth teams. Speaks business and connects design to conversion and performance.
If you care about sign-ups, not pixels, Gemini is your ally.

4. Perplexity
QA baseline. Applies classic usability rules without emotion.
Good for consistency checks, not creativity.

5. Grok
Early feedback tool. Fast, intuitive, and visual. Great for first drafts or mock reviews.
Not deep enough for final design critique.

Dashboard Audits

The billing dashboard was trickier.
Ambiguous “Plan Cancelled.” Confusing bars. Multiple CTAs.
This tested if AIs could handle structure and flow.

ChatGPT

Chose: UX Decision & Flow Audit

Example Output

“‘Builder $828/year’ and ‘Plan Cancelled’ conflict visually.
Fix: Add a clear status label (Active until [date]). Use color coding — green for active, gray for inactive.”

“Invoices link low visibility.
Fix: Make it a button ‘View Billing History’ and align left.”

It spotted logic and clarity issues instantly.
Empathetic and practical.

Verdict: Best for PMs needing clarity fast.

Claude

Claude went full End-to-End Task Analysis.

Example Output

“‘Plan Cancelled’ appears more prominent than active plan — users think they lost access.
Fix: Move cancelled plan to collapsible ‘Previous Plans’ section; add banner with reason + date.”

“Usage table: blurred labels reduce trust.
Fix: Standardize privacy rules; add tooltips explaining hidden data.”

Deep reasoning, prioritized issues, strong empathy.
Feels like a real UX agency report.

Verdict: Best for serious UX audits or design systems.

Gemini

Gemini thought like support ops.

Example Output

“Users need to manage subscriptions without contacting support.
Group ‘Manage Plan’ and ‘Upgrade Now’ actions together.
Add next payment date beside total.”

It reads like UX writing and product ops merged.
Smart on logic, light on visuals.

Verdict: Best for usability flow improvements.

Perplexity

Same heuristics, new context.

Example Output

“Visual hierarchy: secondary sections compete with main ‘Current Plan’.
Fix: Increase contrast for primary CTA ‘Upgrade Now’.”

“Clarify ‘Plan Cancelled’ message and timing of changes.”

Consistent, emotionless, predictable.

Verdict: Use as QA sanity check.

Grok

Example Output

“‘Plan Cancelled’ dominates left panel — visually heavier than current plan.
Upgrade callout too bright — overshadows usage tracking.”

“Merge dropdown + button into one ‘Manage Billing’ CTA.”

Fast and sharp, but limited.
Pure design instinct, minimal reasoning.

Verdict: Quick visual gut check.

Dashboard leaderboard

1. Claude
Best overall. Understands systems, not just screens.
Audits hierarchy, copy, and trust like a design lead would.

2. ChatGPT
Most usable. Balances UX clarity with empathy.
Great for product managers explaining design logic to stakeholders.

3. Gemini
Best for usability. Thinks like a PM and focuses on user tasks and decision flow.
Sharp, procedural, slightly dry but effective.

4. Grok
Early feedback. Blunt, visual, and fast.
Good gut check for readability or layout clarity.

5. Perplexity
QA baseline. Rational, consistent, and predictable.
Useful for testing against heuristics, not for major design decisions.

But it didn’t start that way. Before any of those projects existed, I tried Figma Make once and almost never came back.

The day Figma announced Figma Make, I felt like a kid who’d just been handed the keys to a candy store.
A tool promising effortless interactions, no code required?
I clicked in the second it went live.

But instead of magic… I got silence.
Let’s just say the experience wasn’t quite there yet.
Some things worked, most didn’t. The interface felt clunky. The feedback loop was slow. What started as excitement quickly spiraled into frustration.

I closed the tab.
And with it, I closed the idea that Figma Make could be part of my workflow.

At least, that’s what I thought
until months later, when a few projects forced me to reopen that door.

A reason to return

There’s a never-ending buzz around AI, and Figma Make kept popping up in that noise.
Meanwhile, I was buried in a few projects.

Just getting designs to a “usable” state felt like a grind.
And honestly, I was exhausted.

Every review felt like dragging people through mud.
Static screens. Arrows everywhere.
Stakeholders squinting, trying to imagine how it would work.
Developers nodding politely, then building something completely different.

I was tired of it.
Tired of performing interactions on static screens while everyone tried to keep up.
Tired of writing specs no one read.
Tired of developers missing edge states, even when I’d marked everything in red.
Tired of skipping details myself just to hit deadlines.

It wasn’t just slowing me down,
it was breaking engagement.
Stakeholders stopped asking questions.
Developers stopped looking closely.
And I stopped believing the design would survive the handoff intact.

Every project hit the same wall.
Stakeholders couldn’t feel the product, static screens left too much to imagination.
A modal looked fine on a slide, but no one knew if it blocked the flow or dismissed on click-away.
Reviews ended with nods, but alignment quickly unraveled.

Developers faced the same gap. Even with detailed notes, things slipped: dropdown behaviors, partial validation, hover vs. selection states.
These weren’t edge cases , they were daily friction that slowed everything down.

Deadlines got tighter, priorities kept shifting, and coded prototypes weren’t an option.
Writing longer specs only buried the problem deeper.

What I needed was a way to say:
“Here, click it. This is how it should work.”

That’s why I turned to Figma Make.
Not for shiny demos, but as a bridge:
Interactive enough for stakeholders to experience.
Precise enough for developers to trust.
Lightweight enough to actually fit my schedule.

Getting hands on with Figma Make

I didn’t want to write another “first impressions” post after a weekend of tinkering.
If I was going to talk about Figma Make, I wanted it to be honest.
Not one day of use but months.
So I decided to put it through fire: four real projects.

Project 1 - The Weekend App

The first was a small consultation project I took on for a local startup over a weekend.
They needed help turning a rough idea into something tangible.
The request sounded simple:
“Can you create a mobile app that lets merchants use it as a cashier , no products, just a simple flow to add a sum and take payment?”

Normally, this kind of engagement would mean static screens, arrows, and endless explaining. Instead, I opened Figma Make.

Within hours, I delivered a working prototype:
A barebones mobile UI where you tap “Add amount,” enter a number, and hit “Pay.” It looked real enough to test.

The moment the founder tapped through it on their phone, something shifted. They stopped asking what it would do and started reacting to how it felt to use. It wasn’t code but it felt like a real product.

The wins were huge:

• The founder instantly connected with the idea seeing it as something real, not just another set of screens.

• Instead of designing the profile screen from scratch, Figma Make gave me a solid foundation to build on.

• The prototype made meetings more focused and decisions faster.

• Clicking through flows exposed scenarios that would’ve gone unnoticed in static screens.

Project 2 - Checkout audit tool

For my second project, I decided to test Figma Make on my own idea,
a checkout audit tool where users could paste a URL and instantly get suggestions to improve conversion.

Normally, this kind of idea would never make it past my notes.
I’d start thinking about where I’d find a developer, what tech I’d need to learn, how long it would take and the momentum would die before I even opened Figma.

This time, I opened Figma Make.

Within minutes, I had a working layout.
I wrote a few prompts, defined the rules for reviewing checkout pages, and Figma Make did the rest, a simple screen with a URL input field, a results panel showing audit findings, and a recommendations list with next steps.
It wasn’t pixel-perfect , but it was real enough to click through, validate the idea, and run first tests on the same day.

Wins

• Built a functional layout in minutes without polished designs or heavy prep.

• Could validate the core idea fast and gather feedback while the excitement was fresh.

• Speed turning a vague idea into a tangible product the same day.

• Skipped the usual blocker of “where will I find a developer” and just started building.

Losses

• The technical side hit a wall: API calls never went through despite reconfiguring and swapping providers.

• The interface worked, but the data pipeline didn’t, leaving the prototype half alive.

Project 3: Clunky B2B Tool

This project started with a familiar story: a powerful internal tool built entirely by developers. It did everything it was supposed to, but using it felt like wrestling with an overgrown spreadsheet. Buttons everywhere, no clear hierarchy, and users getting lost in the process. Instead of saving time, it created more work. Feedback was consistently negative.

I decided to rebuild the experience in Figma Make. Not with static mockups, but with a functional prototype that looked and felt real. Rows could be clicked, details slid in from the side, inline edits worked, and validation appeared instantly. Within minutes, people understood how the tool should actually behave.

Wins

• B2B tools don’t need to be flashy. They need to be fast, clear, and predictable. Figma Make turned out to be perfect for that. By using simple styling like Tailwind, I focused entirely on how the interface worked, not how it looked.

• At one point, I was stuck figuring out how to show the “current price” in a table. I tried prompting Figma Make, and it suggested adding a star icon next to the active price with a tooltip explaining it. That small, AI-generated idea solved a real usability problem in seconds.

• When customers saw the interactive table, something clicked. They instantly understood what was editable, how to search, and how to work with data. The prototype didn’t just explain, it demonstrated.

Losses

• Then reality hit. Figma Make isn’t built for complex flows. When I tried to add multiple features or pages, the prototype began to break. Fixing one thing often caused another to fail.

• Heavy prototypes also made minor visual tweaks painful, and z-index issues kept messing up layered elements, especially when columns were frozen.

Project 4: A governance B2B Tool

A complex and outdated governance platform that needed a full structural rethink. The project had already been running for a while, and most designs were in place. However, I noticed the client was struggling to understand the end-to-end experience because there were so many conditional flows that made everything overly complex.

Wins

• Learning from the previous project, instead of building one big prototype, I divided the product into smaller, digestible Figma Make flows. This approach allowed me to show different states, for example, what happens when an order is submitted, declined, or approved.
  It helped the business clearly see what was missing and what worked well.

• Instead of manually designing mobile screens, I asked Figma Make to generate them for me, and it worked surprisingly well.

Loses

• This project used up all of my Figma Make credits, which stopped me from working and taught me a tough lesson: AI prompts aren’t infinite.

• I imported existing designs from Figma, but the results were messy. Auto layout and spacing needed more attention, yet time was limited.
  It worked, but not as smoothly as planned.

What I Learned

Working across four very different projects made one thing clear: Figma Make changed how I design.

Instead of handing off static screens and hoping people imagined the right interactions, I started delivering real experiences that anyone could click, feel, and understand instantly. Reviews turned from explanations into conversations.

It wasn’t perfect. Things broke. Prompts sometimes misfired. Changes didn’t always stick. I hit credit limits and got locked out mid-flow. Some prompts took minutes to process. APIs failed. But even with all that, the trade-off was worth it.

What worked

• I worked up to eight times faster than before

• Developers could experience interactions instead of reading specs

• Missing states surfaced early before handoff

• Startup ideas moved from concept to test in hours, not days

• Stakeholder reviews became shorter and more focused

• Collaboration improved because everyone worked from the same prototype

• Edge cases appeared naturally through interaction, not documentation

What didn’t

• Occasional breakages that forced file duplication

• Limited daily credits and slow execution on complex prompts

• Figma Make sometimes overwriting elements unintentionally

• Unapplied changes that required rework

• API integrations that rarely behaved as expected

Despite the friction, Figma Make changed the rhythm of my work.
I no longer needed to explain everything in words; I could show it.

I believe tools like this will soon be part of every product team’s workflow. Not just for designers, but for anyone shaping a product: PMs, founders, marketers, and engineers. Titles will matter less than the ability to think and test through interaction.

At one point I even skipped designing a profile page entirely. I just wrote a prompt.
It looked great. The time I saved was unbelievable.

For dense, logic-heavy interfaces, that speed and clarity were worth every glitch along the way.