This is the exact philosophy we have in mind when building @lunagraphHQ. I’m a designer and an engineer, running a startup, and running a design studio, so we’re very much on the same page. Let me explain: "letting AI create the environment for you" What we’re building at Lunagraph is a “programmable design canvas”. Exactly as you said, most of these tools are walled-gardens, if they don’t make a feature, you can’t build the experience. If Figma didn’t build motion, you can’t do motion design. In Lunagraph, you can build any experience that you can build with code, make your own controls, handles, anything you need. You can use any React package, like three.js, or motion dev, and cook without waiting for a feature release. You can make a metallic 3d card with knobs for roughness, metallic-ness, and handles for lighting and for the svg logo. You can literally build Lunagraph inside Lunagraph. We are essentially here so you don’t have to remake these primitives every time. PLUS we’re also building the best UX to work on this programmable canvas with your own agents. And now let’s talk about “source of truth” I think everyone has been wrongly fixated on this. Yes what’s in prod is what ships. But what about the intention? Say you’re redesigning an app, or making a new feature: there’s this point in time where there are 2 truths, by definition: > Your intended design is the intended truth > Your current prod is the current truth Eventually you want both to be the same, the intention implemented in the code. But in this point in time, there are these 2 states. So where should the design intent live, for that period of time when it’s not yet implemented in the code? No, not *always* a PR. If you’re designing a new feature, and make a PR in the codebase, would you also be responsible to wire it up, make it truly work? Or would someone else do that part? If it’s someone else, I promise you as a dev making the implementation, I prefer I make the PR and grab your designs piece by piece instead of getting a huge PR I have to unravel and re-wire. And if it’s yourself, it’s so much nicer and more efficient to iterate on the design without your coding agent trying to make it work before you know how you want it to work. This is where Lunagraph comes in. It’s a place to do the big chunk of the design work, all the way to making a PR. - Explore, drawing board, discuss - Start formulating an intent - Make prototypes, test, refine - Iterate, share, get feedback - Finalize - Then convey your intention = to your coding agents, to devs, or to yourself. And yes it’s made of React, so when you “convey your intention” you can choose to go as precise as you want: - At 50% fidelity: you can share static designs and let your agent or your devs interpret the UX and flow - At 90% fidelity: you can build a component, complete with the UX, interaction, transition, states, and how it takes in data based on Typescript data type. - At 100% fidelity: you can implement it yourself and make a PR. We’re definitely making Lunagraph for design engineers who can utilize AI in designing to the max. Many of us are still exploring designing with code with AI, so me and @Riyvir are working hard on distilling our own workflows and hundreds of user feedback into tools anyone can use right away, and building the best way for teams to add their own tooling on the same canvas.

Example of card design (the handles are not a feature, it's user-made just for the card that's in the design)