Ask a coding agent to "make the UI look premium", and you get whatever it felt like building that day. I give mine constraints instead. I keep a list of sites that generate design markdown files for AI builds. Typography, colours, spacing, radius, shadows, components, states, responsive behaviour. A full design system in a single file. The workflow, before any screen gets built: Pick a visual direction. Generate the .md against what the product actually does and the outcome it needs to hit. Drop it into Claude Code or Codex or Kimi or Cursor. Use /design to fix what stays consistent across every screen. Now the agent follows a spec, not a mood. That file, plus a folder of five or six visual references, is the first thing I prepare before a client build. The sites: https://www.typeui.sh/ https://design-md.hyperbrowser.ai/ https://neuform.ai/ https://www.aura.build/ https://www.designmd.supply/ https://open-design.ai/ https://designmd.me/ Enjoy. Build. Ship. Cheers.

which one do you reach for first?

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.

making docs readable for both humans and ai is the bit most teams skip. do you write the guides before or after the components?