Aestheria.design . Aestheria.design/docs

Why I started

Every prompt gave me back a different product. The agent would return a screen in seconds and the drift came with it: new spacing, a button that had never existed, a card shaped nothing like the last one. The speed was real, and it went straight back out again. Nine tenths of my day went to holding the work to what I had intended instead of moving it forward.

Slowing the agent down was not the answer, and neither was taking whatever it returned. Agentic work needs its own paradigm: one that keeps the speed, and keeps the quality and integrity of the product with it, instead of paying for one with the other.

It was never that the context did not exist. It was everywhere: a Figma file, a doc, a component library, a decision someone made in Slack six months ago. It was just not something an agent could understand on arrival, because it was written for people to interpret and agents do not interpret. Design context has to be built as a system and arrive inside the work, with no detour to go and find it. Built that way, staying on system and on standard is not a thing anyone has to do by hand. It is the difference between doing it all yourself, every time, and a process that carries it for you.

So I started building what I wanted to hand an agent before it wrote a line.

There was a second reason, and it was closer to a dare. I wanted to find out whether I could work with no Figma file at all. No mockup, no handoff, no redrawing a screen that already existed in code. Just the system, an agent and me, designing and building the product in the same pass. Aestheria is made that way, which means every gap in it turns up in my own work before anyone else can find it.

It started as an experiment and it is a business now, a profitable one. That was not the plan, and it is the clearest sign I have that the problem was never only mine.

What makes it different, and how it works

Aestheria is a design context layer. It sits between a product team and its coding agents, and it gives both the same source of truth.

It is served over MCP, which is how an agent connects to an outside tool. So the agent never has to read the design system and work out what it means. It asks for the piece it is about to build, and the answer comes back the same way every time. Behind that sit over a hundred components, patterns, visualizations and page templates, each with its anatomy, its states and its rules. A theme is one attribute on the page, light or dark, so nothing is tied to a single brand: change that attribute and the whole page re-resolves to the new one. And a set of agent skills tells the agent how to do the work rather than leaving it to browse, so what it gets is a method, not a parts bin.

The part I care about most is that it was built for AI-native products rather than retrofitted to them. The patterns are the ones these products actually need: a response that streams, an insight that carries its own confidence, a surface marked live or generative or explainable, so the interface tells the truth about where its content came from.

Nobody is replaced by it. Designers set the system, builders set the intent, and the agent works inside both. What changes is that all three are finally speaking the same language.

Where it earns its place is the teams that feel that friction most: fast-growing AI-native product teams, and increasingly the enterprise SaaS ones, where the surface area is large enough and moving fast enough that consistency is the first thing to go.

It suits the non-deterministic way these products are made. The next screen is generated rather than drawn, no two runs come back the same, and the idea is what the team is really moving. Consistency is not the thing to chase in that setting. Integrity is, and a system is what holds it while everything above stays free to change.

What I am aiming at is the first prompt already coming back beautifully designed. That makes whoever is doing the prompting — wherever they sit in the product team — worth a great deal, and it puts designers where they are worth most: setting the guardrails, holding the quality bar, and owning the brand and style direction.

Where we are

Aestheria is live, and it is what I build with every day. It is my daily driver, not a deck. The components, patterns, visualizations and templates are shipping, the themes and skills with them, and it runs over MCP inside Claude Code and other agents. It is still early, and it grows every week from whatever I hit while building with it.

The inventory keeps growing, and right now it is aimed at enterprise-grade SaaS interfaces, the kind with a lot of surface and a high bar to hold. Those are drawn in the dark theme, which is the primary case and where the system looks its best, and the light theme is there for the same components whenever a product needs it.

The hosted MCP is free. Point an agent at it and you can build with the whole system today, without installing anything.

There is far more of it than a case study can hold. If you want to see it properly, it is all at aestheria.design, with the documentation at aestheria.design/docs.

And I would like to hear from you. If you are starting something, or trying to turn an existing team AI-native, that is the work I most enjoy talking about, and I take on consulting alongside building this. Write to me at june@aestheria.design.