If I'm reading this correctly, caching only happens if I give it a stable cache key? If that's true, this just seems like an insanely bad decision. I've seen waaaay to much bad React code to think that that isn't a massive foot-gun.<p>1. That combined with hot reloading just makes me think some jr dev is going to forget to put that there while they're building something locally and burn through their LLM budget without even knowing it.<p>2. What happens if the cache key changes. Is there any way to migrate from one key to another? Let's say I'm using user ids as the cache key and you need to do a migration that changes the format of the key, is the existing design just gone forever?<p>3. Does anyone even want a non-deterministic UI? Don't get me wrong, it's a cool for a demo, but I can't think of anything that would annoy me more than coming back to a website and every week it looks different.<p>Sorry to be a downer, but man, I just really struggle with this. If this is just kind of a cool hobby project then you can ignore #3, but for 1 and 2 I really feel like it'd be a better to do something like have a data attr for the prompt and then have component generation be something a user kicks off through a script or something.
Google has a similar project called A2UI:<p><a href="https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/" rel="nofollow">https://developers.googleblog.com/introducing-a2ui-an-open-p...</a><p>In the real-world, to me it makes the most sense for client and patient onboarding.