AI can now design and build production-ready software. The results reflect your product’s style, features, and the context you provide. This is how we build AI products and work with teams every day. It’s also how we create and maintain the digital products we care about.
In brief
Don’t just prompt AI—give it context. Make sure your tokens, voice, and decisions are encoded in ways the AI can understand.
Your design system should be the single source of truth. It should be live and actionable data, not merely static documentation.
Put the rules into your code so every screen stays consistent, from the first to the hundredth.
AI can make work faster, but human judgment is still needed. Review steps, clear rules, and good taste help keep quality high.
Context is everything
People talk a lot about design.md files, but the format itself isn’t what matters. Markdown is just text. What matters is the context you put in it: design tokens, spacing rules, brand voice, component choices, and the thinking behind those decisions.
Markdown is a format that both people and AI can read and understand easily. This makes it a good place to store context: design principles, engineering rules, tone of voice, things you chose not to build, and the reasons behind those choices.
Context
What the AI knows is important. Give it design tokens, component lists, brand voice, and a record of past decisions and the reasons behind them. The more context you give, the less the AI has to guess and make things up.
Rules
What the AI must follow. Set clear rules in the work: use these tokens, never those values. Extend existing components instead of making new forks.
Skills
What it can do. Set up repeatable workflows for analysis, breaking down stories, and applying the style guide. Write them once, then anyone can use them.
The tools will keep evolving. The principle won’t: the quality of AI output depends on the quality of its context.
Design systems built for AI to understand
An AI-ready style guide isn't only a static PDF. It’s structured, living data that an agent can understand and use. Design tokens set the values, the component library sets the patterns, Storybook shows behavior, and Figma keeps the design intent, now accessible to agents through MCP. When these parts are connected, the style guide becomes more than just documentation that gets outdated. It becomes a living contract that every generated screen can be checked against.
A new generation of tools is making that contract real before anything ships. Pencil.dev treats designs as files in your Git repository, which you can edit directly in the IDE. Agents can read and write them through MCP. Paper takes another approach, showing a free-form canvas in real CSS, so the design is already close to production code.
We test these tools ourselves and look at them critically. Some become permanent parts of our workflow, while others don’t make the cut. Being disciplined about evaluation is just as important as the tools themselves.
The real trick is making the rules part of the codebase
It’s easy to miss context that’s hidden in a wiki. The real breakthrough is putting the rules where the AI actually works: in the repository. Rules files live next to the code. Tokens are imported instead of being recreated. The system enforces component use. Every agent starts with the same guardrails, so the hundredth AI-generated screen is as consistent as the first.
That’s what makes this approach work for more than just the design team. Anyone can direct AI to build a feature and trust that it will look and work as intended. Design is no longer a bottleneck. It becomes the operating system the whole team builds with.
Where human decision remains
None of this removes the need for human assessment. It just makes it more intentional. Taste, product strategy, knowing what not to build, and spotting when AI is confidently wrong are still human responsibilities. We keep clear review steps before anything goes to customers, structured handoffs with acceptance criteria and do-not-build lists, and one simple rule: nothing ships from AI that we wouldn’t put our name on.
Where the approach has been proven
We turn our style guide into rules, use playbooks as reusable skills, and use AI-augmented engineering to help a small team work like a much bigger one. We guide teams through the early shift from static Figma mockups to AI-assisted prototyping. These practices have only gotten stronger as the tools and workflows have improved.
Are you scaling design with AI, or deciding what you can trust it with? Let’s talk.