On pretty much every introductory call where I show my design systems work in Figma and Claude, people get fascinated by my Figma/Claude files, Storybook setup, docs and guides—and how I make decisions so both humans and AI can pick these systems up. I build these to help products scale at the pace they want, in the way they want, without having to fit everything around how the packaged or templatized headless libraries behave and function. We also cover what both humans + agents absolutely must do when working together to ship: avoid long-term technical debt, save tokens as we ship fast, and keep production code as lean as possible. One thing people really, really like is how I define and deal with what I call anti-patterns, account for edge cases, and put together a handoff-ready checklist for both design and engineering before shipping to production code. Which combinations of components shouldn’t we use in bigger molecular patterns? What can’t we do? Can we define the edge cases and use cases where we shouldn’t use this component and should use another one instead? This is so much more UX-led and rooted in systems thinking than UI-led. If engineers are going to work with LLMs to churn out screens for you or your clients at speed, these rules and scenarios need to be part of the system. You need to run them through the LLMs too. And here’s one very funny thing: this is extremely domain-led. You need to understand what to build, how to build it, and where it could go wrong. Claude or Astra can help you think through it, but you still have to test it with users. Not synthetic users, but real humans. And you better build the system in a way your design and engineering teams will actually use. I think this is where so much of the edge lies: knowing what shouldn’t work, finding out what actually doesn’t, and making those decisions part of the system.