How I work
Anyone can get a screen out of an agent. Whether the hundredth one still matches the first is a foundation problem, not a prompting problem. I work with teams to find those guardrails and keep them evolving: the product and design system the agents work inside, so product managers can push code and engineers can push design without anything drifting.
01
Foundation first
Tokens, voice, rules and prior decisions, written down where the team and the AI can both read them. Everything else stands on this.
02
Rules every agent can reach
Not a wiki nobody opens. Rules any agent can access, ideally in the codebase itself, so the hundredth screen still matches the first.
03
The system checks itself
Agents surface drift and inconsistency, then name and locate it automatically. People stay in the loop and decide what gets fixed.
04
The brief keeps evolving
How we brief the AI is never finished. Rules, prompts and context get reviewed like any team agreement, so people and agents stay aligned.
05
Build on the real thing
Prototype in the live product, with real data and real interactions, not a static picture of it. Real data starts the useful argument early.
06
Judgement stays human
Review gates, do-not-build lists and taste stay with people. AI speeds the work up, but nothing ships that the team wouldn't sign off.
Design for the AI era
AI raises the ceiling.
People still set the bar.
AI assists. Humans decide.
AI’s job is to elevate the people doing the work — sharper research, faster iteration, more options on the table. The taste, the decisions, and the accountability stay human.
Know when not to use it.
The skill isn’t using AI everywhere — it’s knowing where it pays off and where it degrades the work. Some problems want a model. Some want a customer conversation, a whiteboard, or a hard no.
Built into your team, not around it.
AI lands inside the structure you already have — your engineers, your codebase, your design system, your review process. Briefed against the real infrastructure, shipped through the process your team already trusts.
01
Where this is proven
At Chime Labs, where I lead product and design with the founding team, we build AI with AI — the style guide is encoded as rules, playbooks run as skills, and AI-augmented engineering gives a small team the leverage of a much larger one. At Smokeball and SkillsAware, I helped teams make the early shift from static Figma mockups to AI-assisted prototyping — practices that have compounded as the tools matured.
Day to day that means taking a story through to production. Where the problem is well understood I write it myself — branch, dev, pull request. Where it is ambiguous or large I brief the agent and hold the gates. Either way it ships behind automated tests and reviewed pull requests. And the design system reports its own violations: every primitive in the component library is graded for how far it has drifted from the tokens, named and located, with nobody auditing by hand.
And this site is its own demonstration: designed by me, and restyled and maintained with an AI agent working under exactly the rules and context described above.
02
It’s all about context
Twenty years of working problems out beside engineers taught me that what made a build go well was never the spec. It was shared understanding: the constraints, the decisions already made, and the reasoning behind them. An agent needs the same brief — it just has to be written down.
So the format was never the point. What matters is what you encode — design tokens and spacing logic, brand voice, component decisions, engineering constraints, and the things deliberately not built and why.
Context
What the AI knows. Design tokens, component inventories, brand voice, prior decisions and their rationale. The richer the context, the less the AI invents.
Rules
What it must respect. Hard constraints that live with the work: use these tokens, never these values; extend these components, don’t fork them.
Skills
What it can execute. Codified, repeatable playbooks — analysis, story breakdown, applying the style guide. Written once, run by anyone.
The tools will keep changing. The principle won’t: the quality of AI output is a function of the quality of its context.
03
Design systems the AI can read
An AI-ready style guide isn’t a PDF — it’s data an agent can read. Design tokens define the values; a component library defines the patterns; Storybook documents behaviour; Figma holds design intent, now readable by agents through MCP. Connected, the style guide stops being documentation that drifts out of date and becomes the live contract every generated screen is checked against.
Working on scaling design with AI — or deciding what to trust it with? Talk to me.
Tell me what you’re building. I’ll tell you if I can help.
Email me →