Summary:
“AI design” is one label but has forked into four different types of work.
What Does “AI Design” Mean?
When someone says “AI design,” everyone in the room pictures something different.
One person is thinking about using AI to generate component variations for a design system. Another is designing a chat interface. A third is structuring data so an AI agent can parse it. A fourth is defining an LLM’s behavior.
They all fall under “AI design” but they are not the same work.
I see this in job postings, LinkedIn posts, and conference talks. Someone says, “We need to figure out our AI design strategy,” and every person at the table nods — while imagining a completely different thing. Six months later, everyone’s frustrated because the “AI-design initiative” was not what they expected.
The conversation around AI and design is forking. What used to be a single (admittedly vague) topic has split into at least four distinct orientations. Each one focuses on a different type of design work, sits in different organizational structures, and uses different definitions of what “good” looks like. Most teams are staffed for only one of these orientations, confused about which one they’re doing, or trying to dance between all of them without realizing it.
So, which of the four AI design orientations are you in?
The Engine and the Car
An AI model is an engine. A powerful, complex piece of technology under the hood. You can buy just the engine (companies like Anthropic and OpenAI sell directly to developers through their APIs). But most people never experience AI that way.
Most people experience AI inside a “car”: the dashboard, the steering wheel, the seatbelt — all the parts that turn raw capability into something a person can actually drive. Most people don’t care how the engine works. They care that it gets them where they’re going.
This metaphor brings us to the four different meanings of “AI design”. Each of these meanings implies a different kinds of work, skills, questions, and success metrics. They’re not mutually exclusive, but they are very different.
The Four Meanings of “AI Design”
Laura Costantino sketched an early version of this framework in a LinkedIn post. I’ve taken it in a different direction by reworking one of the categories and building out the rest.
1. Designing with AI
You’re the driver. You’re the driver behind the wheel.
This is the orientation most people think of first. You use AI in your design process: to ideate, prototype, generate copy, build mood boards, run competitive research/audits, or critique your own work. AI tools are your vehicles, and you use them to get somewhere further, faster.
This is where most designers live right now, and there’s nothing wrong with that. AI-as-tool is transformative for how design work gets done. Entire workflow steps that used to take hours now happen in minutes.
The pitfall is treating this type of work as all there is to “AI design.” Leadership says “we’re incorporating AI into our design practice” and what they mean is “our designers are using Claude Code now.” While this type of AI design is a start, it ignores every other way AI is reshaping design opportunity inside the organization.
2. Designing AI Products
You’re the manufacturer. You’re building the car (or duct-taping AI onto one that’s already moving).
This is where you design the product or interface that delivers AI capabilities to users: the dashboard, the steering wheel, and the seatbelt. Everything that turns a powerful engine into something people can drive without understanding combustion.
This type of work could be delivered in one of two ways:
- AI-native products are where the entire product is the AI experience: Claude, Perplexity, Cursor, ChatGPT, or Midjourney. You’re designing the car from scratch. There is no existing product to integrate into. Every design decision shapes how someone experiences the AI capability itself.
- AI features inside existing products are a different design challenge: Notion AI, Smart Compose in Gmail, or an AI summarizer inside your meeting tool. You’re adding a new component to a car that’s already on the road — one with existing patterns, existing navigation, and existing user expectations. The AI has to fit into something.
These types of work involves different design challenges with different obstacles. For AI-native products, the hard part is that there are no established mental models to lean on: you’re teaching new paradigms to the user. For AI features inside existing products, the challenge is to naturally and meaningfully connect the AI feature to the rest of the experience, even though that nobody asked for it.
3. Designing for AI Agents
You’re the civil engineer. You’re engineering the highways and creating the infrastructure that agents need to operate on.
This one is going to feel like a departure from user experience. Stay with me.
In this type of work, you design content, data, or interactions that AI agents (not humans) will read, parse, or act on. You’re building the infrastructure that autonomous systems navigate. If AI agents are the self-driving cars, you’re designing the roads, the signage, and the lane markings. AI agents are your users.
That might mean structuring product data so a shopping agent can compare options on behalf of a user, writing instructions that an AI assistant will follow, or optimizing content for AI search and discovery instead of (or in addition to) human search and discovery.
Some of this infrastructure won’t even be human-readable. A road sign designed for AI-controlled vehicles might encode information in ways no human driver could parse — data transmitted via radio or embedded in nonvisible parts of the spectrum. The “user” of that sign is an agent, and the design constraints are entirely different.
This is the orientation most design teams are still ignoring, but mostly because many organizations don’t have anyone explicitly responsible for how AI agents experience their product. Which means it’s either not happening, or it’s happening by accident inside an engineering team with no design input.
Designing for AI agents matters because it involves design decisions. What data gets exposed? How is it structured? What can an agent do versus what requires human confirmation? These shape the end-user experience just as much as any interface, they’re just one layer removed.
4. Designing the AI
You’re the mechanic. You’re tuning the engine. You help decide what kind of engine this is and what it’s built to do.
In this type of work, you help shape the model: its behavior, its evaluation criteria, and its principles. You work alongside engineers to define what the AI does, how it responds, and where it draws the line.
For example, you might define evaluation criteria to test whether the model’s outputs meet quality standards, collaborate with engineers on finetuning data, or build the principles that guide adversarial testing — what the model should refuse, where it should express uncertainty, and how it should weigh competing instructions.
So far, the industry has treated these activities as purely engineering work, but they are not. They involve design decisions. Designers are not the only ones who can make these decisions (an ethicist, a copywriter, or a psychologist could each contribute), but designers are trained to integrate them into a coherent experience and test them against user needs. We’re just starting to see job postings that recognize this strength.
Where the Field Is Right Now
These four types of “AI design” work are not mutually exclusive. A single designer might work across two or three of them in a month. Not every organization needs all four, either. A company building on top of an out-of-the-box LLM through an API may only need the first two (designing with AI and designing AI products). The third and fourth orientations become relevant as an organization’s relationship with AI gets more complex –– for example because it’s building agent-facing infrastructure or an in-house LLM.
What makes them distinct is that each one involves designing for a fundamentally different type of behavior — human behavior with tools, human behavior with AI interfaces, agent behavior within infrastructure, and model behavior itself. Different behaviors require different types of expertise.
My point isn’t that you should choose just one path. It’s that each orientation builds a different kind of expertise, and expertise deepens over time. For example, the longer you spend designing AI products, the better you get at that work.
Understanding which type of AI design you’re building expertise in matters because the market is moving fast. Right now, few designers have deep experience across multiple orientations. However, this window won’t stay open for long. Within a year, many more designers will have meaningful AI experience. Those who build depth in a specific direction now will have a significant advantage over those who stay broadly “AI-adjacent.”
Here’s where the field is right now:
Most designers today are using AI as a tool in their workflow. A growing number are designing AI products and features. Very few are designing for AI agents or designing the AI itself.
The demand for those last two is growing. The supply of designers who understand them barely exists. So, if you’re a designer, its an opportunity gap that’s widening.
As agents become more prevalent, someone has to design how they interact with products, content, and data. As models get embedded into more experiences, someone has to define how they behave. Right now, that someone is usually an engineer making those calls by default, when it could (and I argue, should) be a designer.
What Changes when You Understand All Four
Understanding that our discipline is forking when it comes to AI changes how you operate, whether you’re an individual contributor, a leader, or hiring.
If you’re an individual designer, you can stop being vaguely an “AI designer” on LinkedIn and start naming what you’re actually doing. The skills for designing with AI (prompt literacy and workflow integration) are different from the skills for designing the AI (model evaluation, principle setting, and collaboration with ML engineers). Identifying which type of work you’re doing can point you towards which skills matter next. Knowing which work you want to do in tells you where to invest.
If you’re a design leader, you can audit your team against all four types of work and understand where you have gaps and if it makes sense to fill them. Most teams already use AI in their workflow and, may have partial coverage for designing AI-powered features. Fewer have clear coverage for designing agent-facing infrastructure or AI-system behavior — and that may be fine, depending on how your organization builds with AI.
If you’re hiring, you can stop writing job descriptions that are for blanket “AI designers.” Name the specific work, hire for the specific skills, and evaluate against a specific definition of good work.
AI reshaped the design field and created four new lenses that you can look through. Your first step should be recognizing which you want to grow towards.