here's an extract from a discussion i was having in the @elyxdesign's discord with a beta tester. if you've been wondering what elyx is all about, what it does, what it doesn't do, etc. then this might help you too! elyx thrives if you treat your designs a little more like code components. even more so when they share a direct relationship with their code counterparts (e.g. button.elyx vs button.tsx). building a source of truth takes a little bit of discipline. which, let's be honest, for a very long time many of us designers had very little accountability for. we'd work in our corners, name layers however we wanted, break things into pieces based mostly on what made sense visually, often without a very good understanding of how the product was actually being built in code. that was mostly fine when design and implementation were two separate worlds. someone would eventually translate one into the other. but i think that model makes less and less sense now. if design is becoming something that teammates, agents and code all need to understand and operate on, then the structure itself starts to matter a lot more. names matter. boundaries matter. files matter. the relationship between a component in design and a component in code matters. that's a big part of why elyx can sometimes feel a bit more like an ide than a traditional design tool. it's not really trying to make the canvas less free (you can still throw whatever you want in there) but the surrounding structure is nudging you toward making things legible beyond just the canvas itself. the question for us becomes less, "how do we get you to design more before coding?" and more, "how can elyx stay useful while design and code keep feeding into each other?" that's probably the part i'm personally most excited about. not treating elyx as the place where design happens before development, but as something that can live alongside the project while it gets built.