cloudflare
Visual Development Tools for Creatives
This project is incredible! Seriously impressive work by the team.
I’m not a dev, but I wanted to share a few ideas from the creative side in case they spark anything for the roadmap. The main thought is to expand beyond chat-based coding and bring in a stronger visual development layer for designers and teams.
-
Visual Editing Add a visual builder layer that supports live CSS updates, similar Builder.io's Fusion. Designers could visually adjust AI-generated output while keeping the underlying code in sync with the sandbox.
-
Figma Import Allow importing Figma designs and mapping components directly to code equivalents for better design fidelity.
-
MCP Server Integration Let users connect MCP servers directly from their workspace. This would let the agent pull in external tools, APIs, or data sources through a standard interface.
-
Restore & Edit Right now the file view is read-only, it’d be great to be able to edit and manage files directly inside the paltform. Also the ability to restore checkpoints would be nice.
Just some ideas from the creative side, mainly around making VibeSDK a place where both designers and developers can build together visually and seamlessly. Most vibe-coding platforms don’t handle this part well and I think VibeSDK is in the perfect position to do it right.
Thank you for this feedback! Yes, we are indeed looking in the direction you pointed out - Visual canvas & live editing, figma import (although a little less priority because we already have image support), mcp server integration (its already present, just no custom MCP support per user yet) are already planned along with many many more things. About restore and edit - the current architecture makes it kind of hard to pull this off nicely. The LLM is always provided with the diff of the last phase, so if a user doesn't like the changes of the last phase, they should be able to ask the chat to revert them. But it relies on the LLM to do it and may be unreliable. I would probably focus here in the upcoming weeks, but being able to revert to any arbitary point in time would be tricky - an app is a single DO, and there is only so much stuff that can be put in that DO. Currently we only maintain the codebase and last diffs there. But there are ideas of getting this to work. Regarding being able to edit the files - That can be allowed in limited form for the user but only after the LLM has finished generating the app and there is nothing more happening. Doing it in tandem with AI can be risky - would have to support some sort of 'merge' capability like that in git, but they will conflict, and so who should resolve it? User or AI? AI may make mistakes but User might not always be a tech savy person. But with time, even these things would be ironed out.
Thank you for your interest in this project btw. And also, do checkout the official deployed version at https://build.cloudflare.dev and provide feedbacks about how the apps perform - I recently made several changes/improvements to the platform. User feedbacks would be invaluable in evaluating those changes.
That’s awesome to hear you’re exploring that creative direction too. The closest thing to this currently is builder.io - there’s a lot of overlap in ideas that could fit really well here. Most AI builders either miss the visual layer completely or only scratch the surface, so I’m excited to see how you approach it.
On the restore and edit side, that all makes sense. I’ve run into similar cases with other builders, sometimes needing to roll back to a specific chat or checkpoint was super useful. Early versions of v0 had version history that made this easy, so maybe there’s a middle ground somewhere in the setup. Having the LLM handle it does sound a bit unreliable long-term, as you said.
For file editing, totally agree with your take. The ideal flow I’ve seen is where files unlock only after the AI finishes generating. Then you can move things around, delete, tweak code, etc. Once the AI starts another generation, it locks again. Bolt.new handles that really nicely. It just keeps things clean and avoids conflicts while still letting users stay hands-on.
I’ve been testing the official deployed version too, it’s running very well! Especially considering it’s only the Gemini model. A model switcher in the chat would be nice too. I know there’s the “bring your own key” option, but native switching would make onboarding and quick testing a lot smoother.
I’ll definitely keep sharing feedback and ideas as I keep exploring!
Thank you for the response!
The closest thing to this currently is builder.io - there’s a lot of overlap in ideas that could fit really well here. Most AI builders either miss the visual layer completely or only scratch the surface, so I’m excited to see how you approach it.
Sure I would check that out!
For file editing, totally agree with your take. The ideal flow I’ve seen is where files unlock only after the AI finishes generating. Then you can move things around, delete, tweak code, etc. Once the AI starts another generation, it locks again. Bolt.new handles that really nicely. It just keeps things clean and avoids conflicts while still letting users stay hands-on.
Yes, was thinking in exactly this direction, at least the early version of it.
I’ve been testing the official deployed version too, it’s running very well! Especially considering it’s only the Gemini model. A model switcher in the chat would be nice too. I know there’s the “bring your own key” option, but native switching would make onboarding and quick testing a lot smoother.
In the chat would be tricky because there isn't enough space there - the actual chat is just an interface to the various sub-agents. The main things to control would be those sub agents. I was thinking of simply allowing the user to edit/change models from the model configurator in the app itself. But can maybe also have several presets of models.
The thing about our official deployment is, we only use gemini models (users are free to use other models in their own deployments though), and for the specific use cases of each sub-agents, they are already well tuned - modifying them might cause either VERY slow code generation/response or sub-par results. True BYOK isn't available yet for the official deployment, but we are working on getting it going in a nice and secure manner. I would update here about any progress on this end.
Ah got it, that makes sense. When I mentioned a model switcher in the chat, I meant it in the same way other AI builders let you pick which model to use for generating code. Sounds like your setup’s a bit different though, with those sub-agents handling specific parts of the workflow. Having a switcher directly in chat can be super useful for quick swaps, like using one model for certain parts of a generation and switching back after, but I get why that’s tricky here.
Some examples:
Appreciate the detailed reply. Looking forward to seeing some more updates roll out.