[sumitkumar]

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 tell the chatbox to fix it.

Gemini 2.5 pro did much better in one shot. (the prompt was different and without the scrambler/solver/timer)

https://sumitkumar.github.io/llmgenerated-static/

[alexdanilowicz]

Do you have the prompt you used for Gemini 2.5 pro? I think it would be interesting comparing prompt for prompt!

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!

[sumitkumar]

Here is the conversation link with gemini. https://g.co/gemini/share/d253e2ef286c

Well, I was not comparing but it was just an observation.

I understand Magic has more constraints on which libraries it can use and probably is for forms-flow kind of workflows and not for managing complex states of games.

[alexdanilowicz]

That's pretty cool! Thanks for sharing. I like how Gemini used pure HTML/CSS to start.

While we certainly do constraint it, it still should be able to manage creating a Rubik cube solver (even though that is definitely not the intended use case).

There's a lot of "AI tourism" in the space and so never want to constraint it too much + random use cases like this always excite us: https://news.ycombinator.com/item?id=43752176#43752637

I created a basic flight simulator a while back in Magic Patterns in 3 prompts: https://www.magicpatterns.com/c/xensje9nkf48syshrkcmsc

Your Rubik's cube prompt I'm going to add to our eval set :)

[jonplackett]

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.

[alexdanilowicz]

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.

[zalzal]

You probably know this, but just want to say, founder to founder: don't listen to this argument at all.

People are so fond of saying "just wait and the new model will do this." And very smart people I know say it (especially when they work for OpenAI or Anthropic!).

It might be partly true (of course it's situational). But it's a glib and irrelevant thing to say. Model capabilities do not advance like some continuous exponential across all domains and skills. Not even close.

Product design is exploring the solution to human problems in a way that you can bundle and sell. Novel solutions to human problems tend to come from humans, applying effort over time (with the help of models of course) to understand the problem and separate out what's essential and what's irrelevant to the solution.

(A related comment on the adjacent thread.)

[alexdanilowicz]

I love what you wrote in the other thread too:

> "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."

I have been oversimplifying it as "LLMs cannot read you mind."

[jonplackett]

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

[nrmitchi]

> 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".

[zalzal]

100% agree. There is a bigger point too: People assume LLM capabilities are like FLOPs or something, as if they are a single number.

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.

[alexdanilowicz]

> Do you not think that’ll get solved by a future generation of cleverer LLMs though?

I don't. But obviously I'm biased + have spent perhaps too much time at application layer. I think there will still be a large amount of tooling + feeding of context to get the best result and I don't see a world in which we let LLMs run hog wild on our computers any time soon, especially for prototyping workflows at the enterprise level.

And for the sake of discussion: let's say these cleverer, future generation LLMs do exist... then I think the entire workflow will be very different. Hard to say how. Perhaps knowledge work as we know it will be unrecognizable.

Re: the Gemini 2.5 comment, I would love to compare it prompt for prompt. Looks like the prompt they are comparing it to didn't include the requirements for the Rubik's cubes scrambler/timer/solver. That said, I wouldn't be surprised if one LLM — Gemini 2.5 in this case — is better at creating a Rubik's cube compared to Sonnet 3.7/3.5 with our system prompt. (Not a lot of product teams are prompting our platform to build Rubik's cube in three.js lol). But if it is better, what's great is we can easily swap it out and start using Gemini.

[jonplackett]

Cool. Thanks for the insight. Good luck with it all! It seems like lots of people DO see the value in it!

[throwaway7783]

Claude Code?

[echelon]

The value is in the application, not the model.

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.

[tibbar]

If the company can build a big user base first, then they become a possible acquisition target in the future by the LLM company for their distribution, ala Windsurf selling itself to OpenAI.