61–70 of 118 posts
My expectation was that I'd iterate on a few UX designs with the LLM and then when I'm happy with what the LLM is suggesting, I'd output to figma, and then maybe move to code.
It's great that you're generating code, but isn't that increasing your cost and processing time to write code for each iteration?
I'm interested in understanding your desire to do design and prototyping as a single shot? My expectation was that I'd iterate on a few UX designs with the LLM and then when I'm happy with what the LLM is suggesting, I'd output to figma, and then maybe move to code. It's great that you're generating code, but isn't that increasing your cost and processing time to write code for each iteration?
We have a fine-tuned fast apply model for applying code diffs, so that helps minimize the processing time. Always trying to make it faster though.
We view code as a way to 1) unlock interactivity, 2) communicate with the LLM.
A question for you: if we weren't asking the LLM to generate code, what would we ask it to generate?
I'm actually pretty impressed. A couple things though:
1. It took a _while_ to give me anything. Not sure if that's related to load, but it was ~17 files, and probably took 5+ minutes. It was not clear what was going on in that time, or what would happen if I left it. I literally left my machine to go something else before coming back.
2. I really hate saying this, but your pricing is probably way too low, especially at the "pro" level from your pricing page. When stepping into team-based config management and pre-sets, you're leaving a ton of money on the table without enterprise-style custom value-based pricing. If you were asking me, I would recommend moving the team based features (shared presets, custom access control, etc) into an "enterprise" level above pro).
I'm not going to comment on any sort of "correctness" as far as any complex UX behaviours or workflows; I'm only considering this from a mockup/design/demo-of-new-ideas perspective.
I've tried some of the same prompts I've done on v0 but didn't notice a lot of difference -- needs a lot of back-and-forth, as with v0. So not sure what would make me switch at this point.
Hi, Thank you for sharing. I tried this prompt. ``` create a Rubik's cube app with all available moves and show the cube and the animations. add a scrambler and a solver. Also add timer to time the moves. ``` I got this. https://www.magicpatterns.com/c/psesccrmk41jibfhwp7wh1 Which looks like a good starting point but doesn't work at all. After this it is daunting to look at code. I still have to figure out how to tel…
I’m constantly intrigued how people are getting funding for entire companies that are essentially going to be a feature of all LLMs pretty soon.
Model providers will be fungible. Applications will capture all the complicated interaction patterns, domain expertise, and distribution.
Apps can route between cheapest/most effective model. And the Chinese and upstart labs will continue dumping open source on the market. To get distribution, to salt the earth, commodify the compliment, etc.
When will an LLM be able to author a directory of GLB files organized into a game, precisely positioned within a world, with a set of user-tweaked PBR textures? Never. And even if it could, could you fathom the pain? The app layer will do that.
2025 is the year of the "App Layer" in AI.
Earlier quoted context omitted.
There's a lot of work around UX and how you interact with the LLM. For example, given an entire React app + a user prompt to update it, which code snippet do you feed to the LLM? The LLM cannot read your mind. In a way it feels like the application layer's job to help it read your mind.
Do you not think that’ll get solved by a future generation of cleverer LLMs though? As someone pointed out in another comment, they get better results with Gemini 2.5 already. People already seem quite annoyed with Cursor based on that thread the other day with the hallucinated customer support. Interested in anyone’s opinion
Okay, I'll bite. My issue w/ statements like "building something an LLM will do in the future" is a constant goal-post moving argument.
It seems to equate to "how is this getting funded when AGI is going to do it eventually anyways". That applies to literally everything. "Why bother building a social media platform, soon an LLM will be able to build an entire one in a day!", "Why bother becoming a plumber, soon an LLM will be able to control manufacturing equipment to build a robot that can do it better than any human", "Who needs architects, LLMs will soon be able to design perfect buildings for whatever use case!".
If your point is only that some companies are currently getting funded that are a weekend-project away from getting Apple-d out of existence, then I would definitely agree that some companies are like that (just like some app companies were like that 6 years ago). Some companies are just super basic wrappers around someone else's LLM, but the expectation (from investors, at least) is that there's a bigger goal and the "easy weekend project" approach is for validation and building some sort of user base now.
However, I also disagree that this is the case here. Building good UX's around LLM usage is not just "using LLMs", and figuring out the use cases people actually want is also not just "using LLMs".
This is something I would definitely use, as my company pays for v0 today for these exact purposes (product design/PM). I've tried some of the same prompts I've done on v0 but didn't notice a lot of difference -- needs a lot of back-and-forth, as with v0. So not sure what would make me switch at this point.
Some differences with v0:
- Magic Patterns has a Figma-style canvas for collaborating with stakeholders. Makes it easy to view all your chats. - Password protection on designs (this is very important for some companies!) - Feedback collection on prototypes - Reusable components, so you can create a component library with us and then reference those components in your design. - We are only focused on frontend, which we think leads to less hallucinations. Also, when there is no database, you can go revert back to a different version of the design at any point.
We have a course for PMs, in case you find it helpful! https://www.magicpatterns.com/docs/documentation/ai-prototyp...
I don't normally comment on these things, but I gave it a quick shot for a project I'm working on (fairly generic dashboard-style prompt, but that's fine). I'm actually pretty impressed. A couple things though: 1. It took a _while_ to give me anything. Not sure if that's related to load, but it was ~17 files, and probably took 5+ minutes. It was not clear what was going on in that time, or what would happen if I left…
2. Re pricing - that's the most important feedback we'll hear all day! We used to have a "contact us for pricing" tier, but have found self-serve a lot more effective and easier to scale.
We actually still only 2 people, just my co-founder and me. When you say "custom value-based" are you referring to a "contact us for pricing" tier?
Earlier quoted context omitted.
Do you not think that’ll get solved by a future generation of cleverer LLMs though? As someone pointed out in another comment, they get better results with Gemini 2.5 already. People already seem quite annoyed with Cursor based on that thread the other day with the hallucinated customer support. Interested in anyone’s opinion
> Interested in anyone’s opinion Okay, I'll bite. My issue w/ statements like "building something an LLM will do in the future" is a constant goal-post moving argument. It seems to equate to "how is this getting funded when AGI is going to do it eventually anyways". That applies to literally everything . "Why bother building a social media platform, soon an LLM will be able to build an entire one in a day!", "Why bot…
In reality, building products is an exploration of a complex state space of _human_ needs and possible solutions. This complexity doesn't go away. The hard part of being an engineer is not writing JavaScript. It is building a solution that addresses the essential complexity of a problem without adding accidental complexity.
The reason this is relevant is that it's just the same for LLMs! They are tripped up just like human engineers into adding accidental complexity when they don't understand the problem well enough and then they don't solve the real problem. So saying "just wait, LLMs will do that in the future" is not much different than saying "just wait, some smarter human engineer might come along and solve that problem better than you". It's possibly true, possibly false. And certainly not helpful.
If you work on a problem over time, sometimes you'll do much better than smarter person who has the wrong tools or doesn't understand the problem. And that's no different for LLMs.