Designing in the Age of AI: Craft, Systems, and Building

Lately I’ve been trying to understand what being a designer actually means when making things becomes almost free.

I opened Figma recently after barely touching it for two weeks and caught myself thinking, before drawing anything: an LLM could probably do this.

That feeling is exciting, but also a little uncomfortable. I don’t want faster tools to slowly make me forget the craft.

Making became cheap

AI is incredibly good at producing plausible interfaces.

It’s also incredibly good at repeating the average.

I’m seeing more software become very well designed and somehow look exactly the same. The output is cleaner, faster and more competent than ever, but competence alone doesn’t create identity.

So I’ve become less interested in generation itself and more interested in what surrounds it: taste, constraints, systems, evaluation and knowing when to reject what was generated.

If everyone can produce ten versions of a screen in minutes, the valuable part shifts. The question becomes less “can you make this?” and more “why should this be the thing we make?”

Keeping the craft

I don’t think the answer is to protect old workflows just because they’re familiar.

I want AI to remove repetitive work. I want to prototype faster. I want to move from an idea to something real without waiting for every dependency to line up.

But I also don’t want convenience to flatten the parts of design that are worth developing: visual judgment, interaction instincts, typography, composition, motion, product taste and the patience to make something feel intentional.

The challenge for me is figuring out which parts of the craft should be accelerated and which parts should still be practiced.

Using an LLM for a layout isn’t the same as understanding why the layout works. And when the generated thing is wrong, that understanding is what lets you see it.

Systems, not just screens

That’s partly why I’ve been moving deeper into design engineering.

I’m building more of what I design, experimenting with AI-native interfaces, and thinking about design systems less as libraries of components and more as boundaries an agent can safely work within.

SyntariUI has become one experiment around that idea: what happens when a system doesn’t just document how an interface should look, but helps decide what can be rendered in the first place?

A traditional design system answers questions like:

• Which button should I use?
• What spacing token belongs here?
• How should this state look?

An agentic system has to answer a different layer of questions too:

• What should be rendered at all?
• Which information matters right now?
• When should the system act, ask, wait or do nothing?
• How much freedom can generation have before the product stops feeling coherent?

That feels increasingly like design work to me.

AI has a cost model

I’ve also been thinking a lot about the economics behind AI products.

Tokens, context, latency, tool calls, retries and model choice are starting to feel like design materials.

The smartest model shouldn’t necessarily touch every problem.

Sometimes the right answer is a smaller model.
Sometimes it’s deterministic logic.
Sometimes it’s a tool.
Sometimes it’s doing nothing.

A product that sends every interaction to the most capable model might look intelligent from the outside while being slow, expensive and unnecessarily complex underneath.

I’m increasingly interested in designing the routing around intelligence: where reasoning is actually useful, where rules are enough, and how much context a task really deserves.

Building is the learning loop

Then there’s Mentionloom, where I’m learning a different side of the same thing by building an actual product from scratch.

That means product decisions, infrastructure, onboarding, AI behaviour, costs, analytics, distribution and all the less glamorous parts between an idea and something people can really use.

Building has made the relationship between those things much harder to ignore.

A beautiful onboarding flow doesn’t matter if the backend isn’t ready. A clever AI interaction isn’t useful if it costs too much to run. A strong product idea doesn’t go very far if nobody discovers it.

The more I build, the less separate design, engineering and product strategy feel.

Where this is taking me

None of these experiments feel completely separate anymore.

The design system work, the AI routing experiments, building Mentionloom, writing code, thinking about model economics and trying not to lose the visual craft all seem to point in the same direction.

I think I’m trying to become better at designing the whole system around an experience, not only the screen someone eventually sees.

I’m still figuring out what that makes me.

For now, building seems like the best way to find out.

Follow me on X — most of these thoughts usually start there first.