So I had this idea that kept nagging at me.
Every AI chat app works the same way. You type something, the model returns text or markdown, the UI r...
For further actions, you may consider blocking this person and/or reporting abuse
You're not the only one who's done this; Microsoft has already beaten you to it with VibeOS, an operating system where AI decides how to draw the interface. It's very close to your concept.
So, we're waiting for you to create a VibeOS clone! 🤗
Ohh , yeah it is just small project I thought is cool 😅. Thanks 🙌
Self-rewriting UIs are a powerful demo but I'd be cautious about production use. The key challenge isn't technical — it's predictability. When the UI can change based on LLM output, you lose deterministic testing, accessibility compliance becomes a moving target, and debugability drops significantly. That said, for internal tools and admin dashboards where the user is technical, this pattern could be a game-changer. I've seen similar approaches work well in data exploration tools where the AI generates filter components on the fly. The sweet spot seems to be "AI-suggested, human-approved" UI mutations rather than fully autonomous rewrites.
Trueee agreed . The problem is having context and accuracy . I think that can be improved with giving guidance and strict prompts or something.
thanks for insight
DPU is really interesting, and I’m excited to see where it goes from here!
This is a great chat app and a nice example of what frontend development could look like in the future. Great work! 😸⭐
Thank You 🙌
This is a really impressive project! The idea of transforming AI from a simple text generator into a real-time UI builder is a very exciting direction for web development.
The ability to create interactive games, dynamic themes, and live interface changes through AI responses shows how the future of applications may look. The combination of WebSockets, Cloudflare Durable Objects, and AI agents is a great example of modern development techniques.
Projects like this are inspiring for developers and platforms like CodeCan.net, where sharing innovative code ideas and developer resources can help the community learn and build better applications.
Great work, and I would love to see how this concept evolves in the future!
Thank you🙌🙌
This is a really cool concept! Streaming raw HTML directly into the DOM looks super interactive, but how do you handle CSS scoping and prevent generated styles from leaking or breaking the existing UI layout?
Great question! A few layers working together:
Design tokens: The AI is given the full CSS variable system in its system prompt (
--accent,--surface-1, etc.) so it builds on the existing tokens rather than inventing random values.Scoped styles: For scoped styles, it wraps them inside the message ID —
#msg-agent-42 button { ... }— so nothing leaks out.Full themes: For full themes, it targets style markers like
/style/chat-overrides, which replace a specific<?start>block rather than appending to the<head>freely.Structural isolation: The shell elements (sidebar, topbar, prompt bar) are structurally separate from the chat viewport, so even if the AI goes rogue with a
background: url(...), it can only affect the chat area, not the navigation.It still breaks occasionally when the model ignores the rules, and I fix it by adding a better example to the system prompt. The prompt engineering is honestly half the project at this point 😄
The marker placement bug is the one that got me, a bug that's invisible on the first message and only shows up on the second is exactly the kind of thing that eats two days, because your instinct is to assume the first working case proves the logic is sound. It doesn't; it just proves the happy path works once.
The structural containment fix (moving the background layer inside the chat viewport instead of fighting it with !important and a MutationObserver) is a good lesson on its own, separate from the AI angle — "make the wrong state physically impossible" beats "detect and correct the wrong state" almost every time, and it's easy to reach for the detection approach first because it feels like less upfront work.
Genuinely curious about the routing mechanism for the multi-user secret-word example, if the model itself decides what's public vs. private per client, what stops it from ever leaking the secret to the wrong client in the content of a "public" message, even if the SERVER_PROPS routing correctly restricts the message envelope? That seems like the one place where trusting the model's judgment (not just its formatting) becomes load-bearing.
the part that's gnarly to get right at scale: injecting model returned HTML into the DOM is fun until the model starts writing script tags that reference each other across turns. you end up with execution order nondeterminism and event listener leaks that accumulate across the conversation.
we explored a similar pattern for a dynamic report builder — ended up sandboxing each bubble in an iframe with a message API so the host document stayed clean. adds a little overhead but the isolation is worth it.
are you scoping each bubble's JS execution to its own context, or is there global state the model can accidentally write to across turns?
Thank you for sharing. Interesting stuff.
🙌🙌