The future of AI, and the design industry.

Every AI product sits somewhere on a spectrum of autonomy. At one end, a person does the work and AI assists. At the other, the system runs itself and the person governs. Where a product sits now decides how much room it has to grow.

General-purpose models — Claude, ChatGPT, Gemini and their peers — keep getting better at the low-autonomy end. Anything that is “assist me” or “draft this for me” is being commoditised, handed out for free by the labs. As they expand, they compress the moat beneath every AI product built on those same capabilities — and the defensible market gets squeezed up to L3–L4: products that act on their own, safely, at scale.

The products that last won’t do it with a nicer chat box. They’ll do it with governance — being able to run fleets of agents safely. That is the capability the labs can’t commoditise, because it lives in a company’s own rules, data and risk tolerance.

Think of the gap between letting a new hire draft an email and letting them move money out of the company account unsupervised. Governance is everything that makes the second one safe to allow — the permissions, the checks, the audit trail. That’s the hard part, and it’s where the value now sits.

Two things define that defensible end of the market:

That’s the shift at the industry level. Here’s where it lands for the people who design and build — and it starts with a whole new surface to get right.

Governance, version control, monitoring, approval loops — none of these are new. But autonomous agents will need far more sophisticated versions of them: systems that can supervise thousands of actions safely, at scale. That depth is almost a new product specialty in itself — and it opens fresh ground for product designers. You don’t own all of it; you own a slice, and you own it deeply. Each of these is a real design problem waiting for someone who understands both the craft and the machinery.

To design for AI products, you have to understand the tech underneath. Not to write the model — to know what it can and can’t do, where it breaks, and what the moving parts are called. Here is the vocabulary every AI-native designer should be able to hold.

The walls between Product, Engineering and Design are thinning. With AI translating between them, a designer can draw on far more context — the product strategy, the codebase, the systems around a feature — and weigh in with real substance across all three. You don’t become a PM or an engineer; you make better design decisions, faster and with more confidence — and you can step in to fill a gap when the team needs it.

The reach runs across the process too, not just the roles. With more context, a designer can weigh in further along the whole arc — scope, UX, UI, and the code underneath.

I believe this because I’ve lived it — four teams, fourteen months, one role that kept flexing to cover whatever the team was missing.

Fluency compounds into something bigger: every IC ends up running their own operating system — a personal stack of connected tools and automations that makes AI feel native to their work. Context is king, and whoever wires theirs up best gets the most out of AI.

Every designer will talk with the codebase — scoping, brainstorming and prototyping grounded in the real product instead of a static mock. You connect your stack over MCP, ask how things actually work, and design against real constraints.

And it doesn’t stop at code. Models read the world through text — so the plain file becomes the interface to everything. A Notion spec, a call transcript, a Figma flow, a PostHog metric: flatten each one into markdown and they stop being scattered documents in ten different tools and start being a single database your agents can query.

That’s where the leverage moves — to whoever curates their context best. The designer who keeps a searchable second brain (decisions, research, guardrails, all in files) hands every agent the same grounding a senior teammate would have. Context stops being something you have and becomes something you ship: the better-organised your files, the sharper everything built on top of them.

AI smooths the hand-offs between specialists. A designer can carry an idea further — turning scattered context into a clear, well-scoped brief — so engineering starts from something sharp instead of a vague mock. The work still flows to the right people; there’s just less lost in translation.

And when engineering is stretched, a designer with this fluency can pick up a small, well-scoped change to unblock the team — filling the gap instead of waiting on the queue.

None of this is theory. It comes from doing the work — embedding as a designer inside an AI startup, in the codebase, shipping on an AI product like an engineer. These insights come from pushing past where the design role usually stops: a year of my own contributions across the RelevanceAI repos.

I don’t want to watch this shift from the sidelines — I want to help shape it. This is one of the biggest changes our field has faced, and how we move through it matters as much as where we land.

My work is helping designers and teams navigate it with clarity instead of fear — and come out more capable than before.