Some of the designers are indeed now skipping Figma, a direct quote from one of them (https://www.linkedin.com/posts/stephenwitmer_you-gotta-love-...):

> "I spend 80-90% less time drawing boxes in Figma - and more time using my insights, creativity, and words to create working prototypes [...] - to shorten feedback loops & better communicate vision."

Other designers will use us purely for brainstorming and then use the Magic Patterns Figma Plugin to export. The way this works behind the scenes is we convert the HTML to Figma nodes (https://www.magicpatterns.com/docs/documentation/get-started...)

We are rolling out a reusable components feature. If you hit us up in our support chat or email me: alex [at] magicpatterns.com I can add you to the feature flag!

At first this many sound like a disadvantage, but it helps us stay very focused on actual product teams and their workflows.

Examples include: 1. we have an infinite, real-time canvas for collaborating, 2. reusable components and leveraging your existing brand, 3. export to Figma, 4. password protection on designs, 5. feedback collection. These are all features that customers have asked for; we haven't found that product teams need to spin up a database or leverage a Stripe integration.

Last note: this space is an absolutely massive and we find all the other tools popping up very motivating. We first launched in October 2023 (before most other tools) when all you could generate with GPT 3.5 was a small React component. Our long-term vision is to be the one-stop shop for frontend.

Yes, it's incredible seeing what you can do with pure code. I think that's a lot of the magic here: with code, you can do anything. This part is super gratifying to work on.

From day 1, we have thought of code as a first-class citizen in Magic Patterns because that's all the LLM sees. So then at the application layer, it becomes our job to best help the user interact the LLM a.k.a feed it the most relevant code. This part is suuuuuper challenging.

It's been pretty cool to see how a tool like Magic Patterns is helpful for software builders to think through the flow for whatever feature their building. This is largely how I use it internally. For example, when I added our deploy feature, I first used Magic Patterns to think through what steps I needed to add: https://www.magicpatterns.com/c/d9sb9eavgnpjv1d5vaw6wa

This is long way of saying that one way I have become a better designer is by using AI as a creative assistant, but then also recognizing when to not reinvent the wheel. You also want to leverage existing patterns as much as possible.

On the other hand, for product teams with mature engineering workflows, it usually goes like this: 1. Designers/PM brainstorms an idea in Magic Patterns 2. They get feedback in a design crit or from their users by sharing the Magic Patterns URL. 3. They iterate on it further and then either export it to figma or hand it off to engineering directly. But! engineering won't use the code because we output React + Tailwind CSS, and they are very likely using custom components or have their own nuances.

I do think as the foundational models get better the dev/design handoff will get smoother, but I don't think we are there yet, especially for existing code bases. For new projects, it's a different story and our two-way Github sync plays a role.

It's pretty interesting because every model seems to introduce a new set of hallucinations, so this is a problem that requires a lot of maintenance. We have this internal mantra to "use AI as little as possible" especially it's a problem that can be solved deterministically.

Also, because we are more focused on PMs, designers, and product leaders the code is largely an implementation detail. What they care about is being able to visually communicate their ideas, and React just happens to be a great way to do that because LLMs are great are outputting it + we have a pipeline to render it. (We are React developers ourselves.)

In this case, it looks like the Gemini output that you linked — as you mentioned — doesn't include the requirement for a scrambler/solver/timer, so it's hard for me to comment directly on the comparison.

I ask because we can totally add Gemini 2.5 pro as one of the models we use under the hood!

p.s. great to see a customer on here. appreciate it.

We're looking into importing from Storybook too, but it can get fairly custom and we want to make sure it scales. It gets tricky because these systems are expecting a certain format - in our case React + Tailwind - and so if the design system isn't that, the LLM won't handle it well.

Video demo of recreating LinkedIn's design system: https://www.linkedin.com/posts/teddy-ni_i-created-a-custom-d...

In the earliest days of the product, we were hyper-focused on custom component libraries. We connected to Github repos and then fetched the relevant components for every prompt. We no longer do that because the models got a lot better and most customers don't care about the code, they care about the visual output. But this lead to us always caring a lot about consistency. Still iterating on that every day.