Operating as an AI-native product designer in 2026
With Vitor Amaral, Designer/Builder at Intercom.
Dear readers,
The role of Product Designers is changing incredibly fast; it can feel hard to keep up at times, so I wanted to collaborate with someone who I know is constantly evolving his workflows and in a company ahead of the game, in Vitor.
Last year we collaborated on “The Future of Product Design.” The themes were clear: AI literacy was becoming baseline, design and product roles were merging, and hands-on builders were pulling away from everyone else. AI-native companies do not want to hire designers in the old sense. They are hiring people who can think in systems, ship to production, and use AI as leverage, not decoration.
In this article, I sit down with Vitor to go deeper - to give you insight on how he works, how that has changed, and what it actually means to operate as an AI-native designer in 2026 inside a company ahead of most.
TL;DR of my learnings from this article:
1. The role shift: from making to deciding, AI now produces solid starting points and, in some cases, final outputs. That moves the designer’s attention away from production and toward evaluation: what’s worth building, what direction is strong, what should be refined versus discarded.
2. The quality bar is rising faster than most realise. What counted as good UI a year ago can now be generated instantly by a model. The designer’s value is shifting to what AI still can’t do - motion, micro-interactions, taste and turning something functional into something intentional.
3. Discovering what to build is now more valuable than building itself. Because AI is rapidly reducing the cost of production, the premium skill is framing the right problem and choosing the right direction, not execution.
1. What does “AI-native” actually mean now?
To excel as an AI-native designer, it is not about collecting tools or writing better prompts. It is about knowing where AI should replace your effort and where your judgment is irreplaceable.
AI is now good enough to produce solid starting points and, in some cases, final outputs. That shifts your attention away from production and toward evaluation. You spend less time making and more time deciding: what is worth building, what direction is actually strong, and what should be refined versus discarded. This is the real shift in practice.
Last year, only a small group of designers were deeply exploring AI. Now it is becoming a baseline expectation inside companies. It is always easier to explore before something becomes mandatory. Once it is a baseline, you are adapting under pressure instead of learning at your own pace.
A good way to move from curiosity to real capability is to build something functional from scratch — not just prompts or experiments, but a real project. Use tools like Cursor with Claude Code. Think about logic, data sets, projects that feel real.
2. What does an AI-native design workflow look like?
For years, design followed the discover–define–deliver logic, often visualized through the double diamond. It shaped how teams planned, researched, and validated ideas. But foundations are not fixed. They evolve.
AI is changing the cost and speed of building, which means the sequence of how we design can also change. Exploration, definition, ideation, and testing no longer need to happen strictly in order. With AI, teams can move from an idea to a coded prototype in days instead of months. That shifts where time and effort should be spent.
When the problem space is well understood, it can be more effective to start from the solution and learn through building. Instead of spending months only investigating, you can create a directional prototype, test it in reality, and use that to discover new aspects of the problem you would not have seen on paper.
This is where vibecoding becomes valuable. It is not about skipping thinking or ignoring research. It is about using building as a way to think and validate faster. The question becomes: are you designing to explain, or designing to ship?
At the same time, this approach only works when there is strong upfront clarity. Before using AI to vibecode, I need to deeply understand what I am trying to solve, what outcome I am aiming for, and what technical capabilities are available to reach that outcome. AI can also help in this planning phase by helping map options, constraints, and possible architectures.
Once you start building, you enter a different phase. Vibecoding is not passive generation. You need to stay aware of what the AI is producing, how the system is structured, and what trade-offs are being made. You are constantly testing, criticizing, and steering the output to reach the level of quality you expect.
This is where technical awareness becomes important. Understanding the structure of your project, the components involved, and how changes propagate gives you a clear sense of where to intervene when something is not working. Without that understanding, you risk accepting outputs you cannot properly evaluate or improve.
In this new dynamic, discovering what to build becomes more valuable than the act of building itself, because AI is rapidly reducing the cost of production. The designer’s role shifts toward framing the right problem, choosing the right direction, and maintaining quality while the system accelerates execution.
3. Do you still need to invest in craft?
The main challenge is that the quality bar is rising extremely fast. What was considered good UI, not great, a year ago can now be generated instantly by a model. That forces designers to push beyond the basics and focus on what AI still cannot do well.
If AI can produce the UI base in minutes, the designer’s value shifts to how you elevate that base working motion and micro-interactions, turning something functional into something intentional. AI gives you the starting point. Your taste is what takes it further.
Developing a sense of quality only comes from exposure and practice: building many interfaces across different contexts, analysing strong products and understanding why they work, and building a mental library of patterns, mistakes, and trade-offs. This experience helps you recognise when something generated by AI is merely acceptable versus when it is truly well designed.
AI generates based on patterns and parameters. It does not understand whether the result is appropriate, coherent, or aligned with a product’s long-term direction. That is where designers act as gatekeepers. Even now, every AI-generated interface still needs a human to review and shape it to validate the structure and interaction patterns, check semantic clarity and copy, and ensure the result fits the product, not just the prompt. The tools can generate quickly, but judgment, taste, and accountability remain human responsibilities.
4. How do you set up your environment?
For a long time, the design workflow ended with a Figma handoff. Designers produced specs; engineers translated them into code. AI changes the equation but not by removing engineers from the picture.
Frontend involves state, data flows, accessibility, and architectural decisions that require real technical depth. That work still belongs to engineering. What AI enables is a new division of labour: designers own the experience layer, engineers take on the deeper structure and logic. Instead of handing off static files, you deliver functional frontends they can extend.
To make this work, you need five things in place: an AI-first editor like Cursor or VS Code, an AI coding agent like Claude Code, a coded design system, Figma Code Connect mapping Figma components to their code counterparts, and a GitHub review workflow with engineering.
Ask engineering for a single startup command that gets you running locally:
nvm use && npm install && npm run dev
More importantly, ask them to set up a protected /design-space/ route inside the real app. This is the key infrastructure investment. Your prototypes render with real navigation, real design tokens, real components — not in an isolated sandbox. When you share a URL with stakeholders, they are in the actual product. One-time engineering setup, permanent payoff.
Your design system is your vocabulary. You do not write components — you describe them. When you want a slide-over panel, you say “sheet panel.” When you want a data table, you say “table with search and filters.” The AI translates your words into the right component imports from your design system. With Figma Code Connect configured, you can hand the AI a Figma URL and it will identify which design system components to use. Without it, the AI guesses. With it, it knows.
Creating a prototype page. Open your editor, start the AI, and describe what you want:
“Create a new prototype page for a notification preferences feature. It should have a page header, a list of toggle settings grouped by category, and a save button. Use our design system components. Connect it to the /design/space/notification-preferences route.”
The AI creates the file and wires up the routing. You see it live in the browser immediately. From there, iteration is conversational — reference Figma directly, describe behaviour not implementation, one change at a time.
Sharing and review. When the prototype is ready:
git checkout -b yourname/feature-prototype
git add . && git commit -m "prototype: notification preferences"
git push
Open a draft PR on GitHub. Your CI system builds an experimental version from your branch and posts a shareable link in the PR comments. Stakeholders click it they are in the real app, on your branch, interacting with your prototype. Engineers then review what is worth promoting to a real feature. The prototype stays in the branch and never merges unless intentionally promoted.
5. How should someone build toward this in the next three months?
Building now matters more than theory. Prototypes carry more weight than decks, and designers need to get comfortable with being uncomfortable while learning.
That does not mean skipping planning. Having a clear intent before you start building is still essential. What changes is that planning and execution are now much closer. You define a direction, start building, and refine your thinking as you go instead of waiting for a perfect plan before touching anything.
One of the best ways to learn is to start a personal project, something you care about, and use it to explore AI without pressure or constraints. We are in a moment where one person can build things that previously required a full team. Taking advantage of that is one of the fastest ways to grow.
A common mistake is giving AI too much control and letting it decide everything. That is not how it should work. You still need to understand what is being built, what decisions the AI is making, and what technologies and frameworks are behind your project. Otherwise you risk shipping things you do not fully understand.
That is why it is important to build some technical awareness alongside your design work. You should know, at least at a basic level, how models differ, what a context window is, how files are structured, and how your stack is put together. This knowledge directly affects the quality of what you produce and helps you extract better results from AI.
6. The shift from designer to builder
AI is evolving at an incredible pace. The latest models are not only more capable — they are making the building part faster and more accurate. That changes what it means to be a designer.
Designers need to stay hands-on. When you build, your thinking changes. You stop focusing only on how something looks and start understanding how it behaves, how it connects, and what it takes to ship. Becoming a builder means expanding beyond traditional design responsibilities instead of only proposing solutions, you explore feasibility upfront and understand the technical space around your ideas.
In practice, this means asking how something could actually be built, what technologies or models are available, and what constraints or pipelines shape the final experience. In the past, designers would present concepts and wait for developers to confirm what was possible. That dynamic is fading.
Over time, I have become more technical not to replace engineers, but to collaborate with them at a deeper level. I can discuss trade-offs, understand constraints, and help guide direction. Combined with product thinking, this shifts my role from design execution toward strategy and decision-making.
Building early also improves the work itself. Creating something functional exposes flaws that static designs hide, helps teams align faster, and makes ideas easier to evaluate and discuss.
This shift is also changing team dynamics. On my team, developers often define the problem space themselves. They outline the problem, propose solution paths, and evaluate trade-offs. This is necessary because teams move too fast for one designer to control every detail. In that context, my role becomes more curatorial protecting overall quality and coherence, guiding key experience decisions, and stepping in where design judgment matters most.
Many designers are still resistant to this shift. A common reason is strong attachment to familiar tools, especially Figma. But tools are changing quickly, and staying inside one environment while the rest of the stack evolves is risky. The discomfort is understandable — this transition challenges identity, workflows, and long-standing boundaries between roles. But avoiding it does not stop the change. It only means you are less prepared for it.
Thanks to Vitor for this collab. I hope it’s been helpful.
To check out more of Vitor's thoughts, here is an article he wrote on vibecoding for Designers.
 | A guest post by
|
wowww this is so helpful
Such a great article, thanks