---
title: "Working with AI as a Design Engineer: From Ideation to a Real Product"
description: "How my role as a product designer changed when I started working with code and AI agents — no magic, with mistakes, and with a workflow that actually works on commercial projects."
slug: working-with-ai-as-a-design-engineer
publishDate: 2026-09-09
author: Igor Dobzhanskiy
tags: [AI, Design Engineering, Claude Code, Storybook, Workflow]
---
**Author:** Igor Dobzhanskiy
**Co-author:** Daiana — product designer and product manager — [daiana.art](https://daiana.art/)

---

## Instead of an intro

Last week, for the first time as a design engineer, I wrapped up work on a commercial product without a front-end developer on the team. Not a pet project — a real client product. Design, prototype, components, front-end, hooking it up to an existing back-end. All of it.

A year and a half ago I was only starting to work with AI: pet projects, figuring out how to wire up a back-end, payments, auth. Then I started pulling AI into commercial work — but still inside Figma: optimizing design systems, component flows, generating variants. And for the last six months I've moved fully to an AI workflow: clickable prototypes built on finished components that my developers then simply reuse. And it works for both web and mobile.

Yes, I still open Figma. Just a bit less often than the managers do.

I'm not writing this article alone. With me is Daiana — my wife, colleague, and a source of my inspiration. She has her own big product, her own scars, and her own rules that don't always match mine. So where our experience overlaps, we write "we". And where it diverges, or one of us wants to highlight something important — there will be separate tips from Daiana or from me.

I did everything I could to make this article not only informative, but visually varied too. But for the last six months I've worked mostly on commercial products under NDA, so there is a lot I can't show in screenshots. Unfortunately, those are the rules. Still, I'm always open to questions if anything remains unclear.

One more thing. I dictate my articles by voice, and AI transcribes and helps structure them. So what you're reading also started as a voice message. Why that matters — I'll explain a bit further down.

---

## What a design engineer is and why you'd want one

In short: it's the same product designer, just with a different tool stack.

The goal hasn't changed. I still build a product that solves a business problem and a user problem. What changed is what I build it with: instead of thousands of screens in Figma — a prototype in code, a design system in Storybook, and a team of AI agents I hand the routine to.

Why did this become a trend, and why do product companies want it right now? Speed. Especially on the US market. A design engineer is expected to deliver not just a mockup and not just a prototype — but finished components in code and have a basic understanding of the front-end, so they can hand those components to developers properly. The company gets a designer who covers a big chunk of work that used to take two or three people.

### Why this direction

I have experience managing a team — I worked as a team lead. So does Daiana. And it turned out to be the most useful skill for working with AI.

Because agents are, like, middle-level workers. I used to call them juniors; now they've grown up. You hand them part of the tasks, they bring back a result in half an hour instead of a week. But they still need to be managed: set the context, check the work, send it back for rework, remind them about the rules. Team leading didn't go anywhere — the team is just different now.

And just like with a human team: no need to yell at them or swear. If a team lead is rude to a designer, the result gets worse — and it works exactly the same way with agents. Calm, clear feedback gets you more than caps lock.

If you've never managed people — no big deal, you'll learn on agents. They're patient.

### A disclaimer worth reading

Design engineering isn't the only way to grow in this profession.

Designers can just as well go deep into unique, handcrafted UI — and that branch is no less valuable. This article isn't a call for everyone to write code. It's about what it looks like if you've chosen this particular path.

This matters for people who hire, too. You can't hire one person who will do absolutely everything, perfectly, and preferably work for your project for free. The profession is still forming and, most likely, will split into smaller specializations. We're describing a moment, not the final form.

---

## First the goal, then the workflow

The very first question before any project: what exactly are you making?

The workflow for a website isn't the one for a mobile app prototype. An iOS app prototype isn't the same as a web platform where you're also writing the front-end. The basic principles are the same everywhere. But the deeper you understand the tools, the more complex products you can carry. And over time it's no longer one product, but a bundle of products in one system with different stacks that you need to work on and make them consistent.

So from here the article goes from simple to complex: agent setup → website → web platform → mobile app.

---

## Agent setup: where anything should start

I originally wrote this section as part of the websites chapter. Then I realized it applies to everything — and moved it up. Because positioning your agent matters for everyone, with any tool.

### Tell it who you are

Over a year and a half of work, the AI tools have gotten to know me: my patterns, my habits, how I think, what not to do. And so my requests get done without surprises.

Before the first prompt, tell the agent who you are, what your goals are, what you'll be doing with it. If you're building a website — say you're a designer with this much experience, here's the portfolio, here's the CV, here are the achievements. The better it understands you, the better it adapts.

And here's an important point. Any AI, just like us, is fairly lazy and wants to work less. It learns to do things the way you teach it. If you don't let it be lazy — it won't be. If you do — it will.

We'll say this about five more times over the course of the article. Because it really matters.

### References matter more than details

For the agent to make genuinely good UI, it still needs references. And in my experience — on websites and mobile apps alike — **quality matters more than detail or quantity**. A few strong references plus a clear explanation of what you want give a better result than dozens of detailed but mediocre references.

Nobody guarantees it'll work on the first try. But you'll spend far less time on rework.

### Surprise: a super-detailed prompt doesn't work best

You used to need several AI tools so one could edit the prompt for another. Now that works worse.

What works best at the time of writing — your voice messages. With all the "uh", "um", "like, you know" in the middle of a sentence. For Daiana and me this was a real discovery. The agent, it turns out, also has a chance to think when you give it that chance instead of stitching everything into a rigid instruction.

This may change. Not tomorrow, but the day after, Anthropic or OpenAI will release new prompting rules — and it'll be different. So this isn't a law, it's an observation.

### Describe both the idea and the "vibe" of the product you want to create

Describing the end product is mandatory. The agent has to understand what should come out in the end: which screens, which features, for whom. Without that you'll get something pretty, but maybe not something you needed..

But there's a nuance. If you want the agent to not just complete the task but propose something useful — sections, structure, solutions you didn't arrive at yourself — focus on the vibe too. What mood the product should convey, what matters to you, what you definitely don't want. That affects the decisions the agent makes next.

Roughly: if you describe the product, add Figma and references — it'll come out the way you described. But if you also say that your audience is elderly people or children, that you have specific accessibility concerns — then every next decision the agent makes will be aligned with that. And it will understand your edits better, because it has the context for why all this exists.

### Speak the same language as the AI

If you talk to the agent in the language of the interface — it understands you much better.

Learn what things are called: ease-in, ease-out, hover state, scroll state, padding, border radius, spring, stagger. These are keywords, only in the world of prompting. With one precise word you show exactly what you want where you'd otherwise have to write a paragraph — and it would still come out worse.

A good starting point for the vocabulary — [daiana.art/blog/the-words-that-make-ai-build-what-you-meant](https://daiana.art/blog/the-words-that-make-ai-build-what-you-meant), a practical dictionary of interface terms for prompting AI. "Bounce", "Pulse", "Breathing" and "animate this icon for me" give very different results.

> **Technical note.** This works in the other direction too: the more you understand how the front-end is built, the more precisely you explain and the easier it is to hand components to developers later. Front-end skills aren't required, but very much welcome.

---

## Website: where everyone starts

The simplest level, and where every vibe coder starts. I started here too.

As you may have noticed from previous articles — this website is made entirely with AI tools. The case studies are written with the help of AI. The articles, including this one, are dictated by voice and laid out by AI. I'm just too lazy to write by hand. That's the honest truth.

When I [built this site for the first time](/blog/how-i-canceled-framer-and-created-portfolio-with-ai), I used several tools: one for the plan, another for the structure, a third for the code. Now it's simpler. One is enough — Claude Code or Codex. You dictate what you want, give it photos and case images — and it assembles everything needed on its own.

Prompts work even if you write "please make it pretty for me". The only thing — the first results will be very generic. Slop, as it's called now. That's exactly why the entire previous section on agent setup comes before this one.

Anyone can handle a website. There really are no secrets here, apart from context and references.

> **Technical note.** Websites are built on different things: sometimes it's just HTML/CSS/JavaScript, sometimes Next.js with TypeScript. For a simple portfolio you'll barely feel the difference. The difference shows up when you want something more complex — more on that below in the part about prototypes.

---

## Web platforms: commercial work

This is where the reason I'm writing this article begins. Pet projects and full-stack design engineering (when you also build the back-end) are a separate story, and in my life it comes after commercial work. Here I want to focus on real client projects.

### What it used to be

Figma. Design systems. Many pages of documentation. User flows drawn out with arrows. Hundreds of screens, rules, components, tokens.

It overloaded any designer and developer, made our work long, boring, and as complicated as possible. Over almost seven years I honestly got sick of it — as if I weren't a designer but a builder who has to lay every brick by hand.

What does design engineering give you? The ability to put that routine on agents. And spend that time yourself on business processes, product logic, testing, architecture — the things that are actually hard and where you need to use your brain.

### First task: don't lose the source of truth

When we moved to the AI workflow, the first task was to copy, as much as possible, what worked well in Figma:

- a source of truth for tokens and components;
- a source of truth for the prototype;
- a source of truth for screens, edge cases, states.

I'll explain how we handle this on the web now. Mobile — a bit later, because it's more interesting there.

### Step zero: tell the agent what the prototype is for

You literally write: "I'm working on an AI prototype that will later be handed to developers as the source of truth". This changes how the agent works. It understands that:

- data in the prototype must be hardcoded — in other words, mocked inside the prototype so it works without a back-end connection;
- the prototype has to show edge cases, at least most of them;
- everything it creates, someone will reuse.

### Give the agent access to the real product

If you're not working from scratch but with an existing product — redesigning it or adding a new flow — give the agent access to the app itself.

For example, to the staging environment through the built-in browser: you enter the credentials and let the agent click through the app. Or at least the specific flow you're redesigning. You might forget about nested dropdowns, extra fields, the data that's actually there. The agent, having clicked through, will see that context.

Don't expect it to carry everything over perfectly. But its understanding of the product will be far greater than from screenshots.

Next, two different flows: you're building from scratch or porting an existing design. I'll cover both.

---

### Flow 1: from scratch

It's actually simple here.

1. Set up the project.
2. Drop in references — Pinterest, Dribbble, whatever.
3. Give a visual understanding of how it should work. By voice, by documents if documentation already exists.
4. Explain what you'll be working on and on top of what.

For this stage I recommend strong models — Fable or Astra (at least at the time of writing they were the strongest). So the agent understands the context, sets it up in the project and, as they say, catches the vibe.

After that, for implementation, you can take weaker models — Opus, for example. Sonnet I don't recommend. And orchestration works really well: you ask a strong model to orchestrate weaker ones, and each of them handles its own flow.

The first iteration of the prototype most likely won't be what you wanted. But you'll get it in half an hour to an hour of the agents working, not days or weeks in Figma. Then — minor edits until it's the way you like it.

And there are no secret incantations here. You just explain: "add a button here", "account for this case here", "add a back button here, because you'll get lost". The agent makes very funny mistakes — that's normal. You, as a designer entering this field, orchestrate. Over time the agents adapt to how you think and become an extension of you.

I won't lie: 80% of what AI does, I ship to production right away. 20% — I fix. For working with a "middle" — a very decent result.

### Figma didn't go anywhere

One of the use cases where I still use Figma: I take the design the agent made and move it into Figma via the [Figma Chrome extension](https://help.figma.com/hc/en-us/articles/40826832449303-Capture-web-pages-to-layers-with-the-Figma-Chrome-extension). It copies an entire screen or component straight from the browser (even from localhost) into Figma layers.

Then I edit in Figma — and hand it back to the agent either through Figma MCP or just as a screenshot. "Here's how I see it, do it like this". After a few iterations you'll figure out how to explain design decisions in words at all, and Figma will be needed even less often.

This especially helps when the agent produces a "so-so" result on a redesign. A couple of nudges, my ideation in Figma — and it starts producing interesting options.

---

### Consistency: why Storybook

You might ask: okay, a prototype can be made. But how do you keep track of consistency? Constantly reminding the agent which components to use — that's hard.

Fully agree. And that's why design engineering is more than prompt engineering. Here you need to understand which tools to add to the agent so it works better. Some people keep a knowledge base in Obsidian — but that's exactly a knowledge base: text, mental models, links between pages, graphs. For components, tokens, and visual states it doesn't fit. Some people make a separate page in the project where they store all components and edge cases. For small projects or websites this works — a sort of analog of a UI kit in Figma. But in my experience on big projects such a page gets overloaded quickly.

For components, my favorite is Storybook.

**What it is.** Storybook is the code-based equivalent of a design system in Figma. A page that stores all components, their states, documentation, edge cases. You open a component's page and see all its states — exactly like before in a design system.

**Why edge cases live there.** If I have a widget with a hundred edge cases, showing all of them in the prototype is hard and not always necessary. In Storybook I add all the states right on the component's page. The developer opens it and sees them. That's it.

**How developers get it.** Storybook can be published as a separate system with a public link. But my developers usually just pull my Storybook together with the repository — and they have all the updates right away.

I already [wrote about it separately](/blog/i-removed-figma-from-my-design-system-too) and recorded a [YouTube video](https://youtu.be/7zV7lqBH0Fc). There's also a free skill for Claude Code there that sets up Storybook in your project by itself and keeps an eye on tokens: [github.com/dobzha/dobzha-storybook-ds-skill](https://github.com/dobzha/dobzha-storybook-ds-skill). It's specifically a skill, not a plugin — it gets installed into the code, and then the agent uses it.

**But.** This still doesn't guarantee the agent won't make a mistake. Your rules and prompts still need to include phrases like:

- "check against Storybook";
- "make components the way they are in Storybook";
- "treat Storybook as the source of truth";
- "if you create a new component — add it to Storybook".

AI, like a junior-to-mid designer, needs to be constantly reminded not to invent new components and not to hardcode. You're the team lead among AI designers. But in return the developers get a source of truth in components that they can reuse without guessing.

> **Tip from Daiana.** Integrate the design system right away. If you have documents, components, styles, colors — bring them in at the very start. It's much easier to tell the agent "reference the existing components" than to redo things later. I had an unpleasant experience moving a finished prototype onto tokens: it took several iterations, and the prototype still never got to the tokens I'd sent with very clear instructions. Checking this in a big prototype is nearly impossible. Setup at the start gives you far more than you'd imagine.

---

### One prototype or several: Daiana's approach

This is where Daiana and I diverge, so this section is hers.

> **Daiana.** Sometimes you work with one prototype for the whole app. You need to understand: it gets overloaded easily. So sometimes it makes sense to make separate prototypes for big flows — it gives you far more flexibility. I know Igor is somewhat against this approach, but I genuinely use it on my product, which is not small at all, and I can recommend it for really big flows.
>
> How I decide whether a new prototype is needed: I look at how big the flow is. Very roughly — if it has several sub-pages, it stores data, there are another five to ten sub-flows inside — that's a candidate for a separate prototype.
>
> What you need for multi-prototyping:
>
> - a separate design system for shared components;
> - a similar workflow you start every prototype with;
> - shared knowledge — not inside the prototype, but as a separate project knowledge base.
>
> About the knowledge base. I have a separate project with knowledge about the whole product, which gets shared with team members when needed. It doesn't matter which subscription you keep it on — what matters is that it's separate. And what I find funny — this project isn't used for coding at all. Only as a knowledge base: a reference for discussions, for better decisions, for research. It knows the project deeply, understands how decisions get made, what I consider important — and so it usually proposes very interesting ideas.
>
> When I set up a new prototype, I pull the base knowledge from this project (plus knowledge from the latest prototypes), and these documents become the foundation: shell pages, base colors, tokens, the general approach to the product.
>
> But honestly: multi-prototyping introduces an insane amount of extra work. So this decision has to be made consciously.

Why I'm skeptical: a new prototype doesn't have all the context of the old one. And work in the old one can start to "leak" — introducing bugs even into functionality that already worked. And if you hand that prototype to developers, it comes back to bite you.

So I keep one prototype and split the context inside it through markdown files: for each flow — its own .md that describes how that flow works. Roughly, the auth flow has to work according to `docs/flows/auth.md`, and the agent reads it before touching anything there. That way one prototype stays readable and doesn't get overloaded. More on this architecture in the mobile section, because there it's critical.

Both approaches work. Pick the one that fits your product and team size.

---

### Testing plan and retrospective

Two things we both recommend adding to the workflow regardless of the number of prototypes.

**A testing plan for the agent.** Write into the rules: after every new feature, update the testing plan. You'll need to remind AI about this — that's normal. But even an imperfect testing document gives the agent a way to keep context and get back to it faster. Because the agent won't re-read all the documentation — but it does come back to the testing plan.

**Retrospective.** The downside of big prototypes — bugs in old functionality. So run a retrospective at the end of the day. Or, which I highly recommend, when you've finished the work and have a few hours before the client call. Otherwise the prototype may stop working exactly when you're showing it.

---

### Flow 2: when the design already exists

Those who've tried know: moving a design pixel by pixel into a prototype is hard. A few secrets that will help do it better.

**Don't move everything at once.** Some people drop a link to the Figma file and ask the agent to "analyze everything and move it over". That's a losing strategy. It'll do the wrong thing.

**Components first, then screens.** Set up Storybook for your existing design system and move it over component by component: modal, buttons, headers, inputs. Everything step by step. Only after that — screens. Otherwise the agent will create components from scratch or hardcode, and you'll get double work.

**Screens — by flow.** Pick a flow, drop the agent screenshots of that flow's screens. In the prompt, without fail, even if it's already in the rules, repeat: use exactly the components from Storybook. It helps if they're named the same in Figma. But that doesn't always work.

**Figma MCP is optional.** Yes, you can go through the official Figma MCP or the unofficial Figma Bridge MCP. I personally don't use them: eats a lot of tokens and doesn't always give a good result. Screenshots of the flow with a request to implement them on the corresponding components are more than enough for me. Visually the agent understands what my components look like in the screenshot and puts in the right ones.

**Self-check.** Set up a hook or just ask in the prompt: after every screen, check whether components from Storybook were used, whether there are any hardcoded components and colors.

**Big flow.** If it doesn't move over in one go — split it into parts. Or ask the orchestrator to set up sub-agents, each on its own part. If everything is set up right, it'll split it on its own.

And that's honestly all the secrets of working with web prototypes. If new ones show up — I'll add them.

---

### How to show the prototype to a client

The simplest way — Vercel. All you need is to push the prototype to GitHub and import it into Vercel.

A short guide for those who've never done this:

1. Create a GitHub account and a new repository.
2. Drop the repository link to the agent or connect GitHub to Claude Code / Codex.
3. Ask the agent to push the prototype to the repository.
4. Go to Vercel, click Import, choose the repository.
5. Done. You have a link that updates after every push.

Bonus: from the mobile Claude app you can now commit changes to GitHub. Meaning you can go somewhere without a laptop, and if something urgently needs fixing — do it from your phone and check it on staging in Vercel. A bit hacky, but far better than dragging a laptop everywhere.

### Design canvas: how to show screens to managers

A prototype has one problem I put up with for a long time. It shows one state at a time. And a manager or a tester needs to see all of them: empty, with an error, for a new user and for one who's been in the product for a year. Before, I either built a state switcher into the prototype (boring to make, and developers later think it's part of the product), or explained by voice where to click to see the right screen.

Now I have a canvas. Like Figma, only in view mode.

**Design canvas.** It's a skill for Claude Code by [Volodymyr](https://volomydyr.com/), and I want to thank the author separately, because the tool turned out to be very useful and made my work with managers a lot simpler: [github.com/volomydyr/design-canvas](https://github.com/volomydyr/design-canvas). What it does: it puts every screen and every state of the prototype on one canvas, groups them into user flows and connects them with arrows. An important point — there isn't a single mockup on the canvas. Every frame is a real route of the prototype, running with a specific pinned state. So what the manager sees is the prototype, just laid out.

Then — comments. You can leave a comment on any frame, and it flies back to Claude together with the picture. The agent sees which screen it's about and makes the edit. There's also an exploration mode: you ask Claude to sketch several variants of one screen, they appear on the canvas side by side, and you pick the one that works. This replaced part of my ideation in Figma.

That's what I set up my prototype on Next.js for, because the skill works specifically with Next.js, Tailwind, and Playwright. Managers and testers now open one link on staging and see all the flows with all the states, instead of clicking through the prototype and asking where to find this or that screen.

**Comments from people who don't have Claude.** A manager or a tester doesn't need to go into Claude Code to leave feedback. For that I added [CommentLayer](https://github.com/neodisa/CommentLayer): one script per page, and Figma-style comments appear on the prototype or on the canvas. You click an element, leave a pin, and it saves a screenshot of how the element looked at the moment of the comment. All of this lives in my database, so I see every comment on my side. The nicest feature — when the agent regenerates a part of the interface, the comments on that part close by themselves, and on the unchanged parts they carry over to the new version. And open comments can be exported to an md file with the route, the element, and the screenshot, and simply handed to the agent as a list of edits.

> **Technical note.** CommentLayer is a review layer with open write access, so it lives only on staging or behind a flag. Don't put it on public production.

**What I'm still tweaking.** The canvas will get a separate page with components. Not as the source of truth — the source of truth stays in Storybook — but as a view for managers: all the states and edge cases of the components in one place, so I don't have to send them to Storybook, where they have nothing to do.

---

## Mobile apps

It's a lot more interesting here, because there are no ready-made solutions. But it's possible.

### My setup on a real iOS app redesign

I'm currently working on a redesign of a native iOS app. And here's how it's set up.

**The design system lives in a separate Swift app.** Essentially, it's an app with a component library inside it, tokens, and the entire source of truth for our product. Developers have access to this code and can reuse the components directly.

**Logic, prototype, canvas — on the web.** All of the UX, all the triggers, clicks, transitions are stored inside an HTML prototype.

Why this way? Because I first tried to build a full-fledged iOS prototype of a big app — and discovered an unpleasant fact: it's very expensive in tokens and far more complex than the web. So the UX part (flows, use cases) I do in HTML, and the UI of native elements — in SwiftUI. That way I don't burn tokens on a full iOS prototype, but I can show components with all the iOS quirks (glass effects and the like).

The only downside of HTML: you can't replicate iOS design one-to-one. That's what the Swift library is for. The second nuance — HTML sometimes struggles with big prototypes. I know some people build prototypes on TypeScript precisely because it works better. HTML was enough for me, even though the app isn't small.

> **Technical note on Xcode.** For mobile prototypes it's advisable to have Xcode installed. It's not required in the strict sense, but it's needed so Claude can run the app simulator on your computer, click through the real app, and carry the logic over. You, as a designer, won't have to open Xcode and edit anything there. Just let it be there.

### The .md file architecture

Architecture-wise, I strongly recommend setting up a proper structure of markdown files. This works for both web and mobile — and it's what lets me keep one prototype instead of several.

- **The main .md** — explains everything that's in the app and navigates the agent.
- **An .md per flow** — what it is, why, what the rules in this flow are, which states.

And I strongly recommend working on a specific flow rather than giving a task for the whole app at once. Then the agent limits its context to that flow, understanding the big picture but not spending tokens analyzing the flows it doesn't need. This reduces token spend, reduces hallucinations — and the result is much better.

### When HTML stops working

In Daiana's experience, HTML really handles UI very quickly. If you build the same UI as an HTML prototype and as a Next.js prototype — you'll get to a good result in different amounts of time, and HTML will be faster. So it works great when you need to make a small flow, but UI-perfect.

But she ran into a problem when the prototype's logic became overloaded. If you just need to click through a flow — HTML is fine. But if you change something inside the flow and it has to stay in context, show warnings, toasts, appear somewhere else after saving — that complex logic isn't for HTML.

And then she had to rewrite a huge prototype from HTML to Next.js (TypeScript + React). It took more than a week. Just for the rewrite. And it's very blocking, because while you're rewriting — you can't make changes. First you have to estimate, review, document the whole prototype — and only then start.

> **Tip from Daiana.** Estimate the work first. If you understand the prototype will become complex — start with TypeScript right away.

> **Technical note on versions.** I won't name a specific React version, because it'll go stale faster than this article. But what matters: AI often installs an old version by default, and many frameworks no longer support old versions. So write into the rules: use, if not the newest, then one of the newest stable versions. And one more thing — before installing a new version of any package, ask the agent to check the news for whether that version was compromised. Stories about infected npm packages happen regularly, and it's better to spend a minute checking than to deal with it later.

### Rules for the agent: don't let it be lazy

We've been saying this for half the article, but here it's critical.

In the rules for the agent it's worth reminding it of the basics: reuse, inheritance, basic OOP (organizing code into small objects with clear responsibilities that can be reused and extended) — everything that's obvious to developers but the agent needs reminding of so it doesn't get lazy. Say that you understand this — and it won't cut corners either.

And without fail — **a limit on the number of lines per file**. The agent really loves writing everything as one monolith. And a monolith is one big rock: it doesn't scale, and if something breaks — everything breaks. Your agent should write in different files, have limits, and a structured code format.

> **Technical note.** A ready-made set of rules for the agent — file structure, line limits, reuse rules, versions — will be in the context file you can download at the start of the article.

### What else you need for mobile

Design knowledge. Sounds obvious, but that's exactly what you need to explain to the agent what should work natively and how. The workflow for mobile prototypes is very similar to the web — the main difference is where the design system lives. I find it convenient to keep it in a separate Swift app. You may find another solution that's more effective for you. For now there's no universal one — and that's a feature of this approach.

---

## A real product: when the prototype becomes production

I almost forgot to talk about this, and it may be the most important part of the article. That same commercial product from the intro — the one I wrapped up without front-end developers.

### What it was

A platform for one person. The client ran all of his work in an Excel spreadsheet, and the task was to digitize that spreadsheet. His athletes use an iOS app, enter their variables there, and that data flies through the back-end to the platform, where the client can manage all of it and understand what's going on.

I did the design, built the prototype, wired up the back-end endpoints, and the data started flowing. I can't share more details — NDA. But that's enough to talk about the nuances, because they're not about the product, they're about how to work when your prototype is no longer a prototype.

### First, honesty with yourself

I'm a designer, not a developer. And I understand perfectly well that somewhere I may not understand something — especially where it concerns security. So before handing the product to the client, I brought in a front-end developer to analyze the whole scope: security, connections, how everything is displayed. He approved all of it in full.

I recommend doing the same. Not because AI will do a bad job, but because you, as a designer, won't see certain things simply because you don't know where to look. One review session with a developer costs far less than a hole in production.

### Roles: who is responsible for what

On a prototype, it's you and the agent working as a pair. On a real product there are three parties: you, the agent, and the back-end team that owns the API, auth, and the data. My split was simple:

- **Me** — product decisions, priorities, the relationship with the back-end team and the testers, and the go/no-go on every deploy.
- **The agent** — implementation, verification, documentation, memory, the release mechanics after my confirmation.
- **The back-end team** — the API contract, auth, data, infrastructure.

And one rule that matters more than all the others: the agent can prepare anything, but **never pushes to a branch that deploys without my explicit "yes" in that same conversation**. Not per session — per action, each one separately. "Push to staging" doesn't mean production. Because when a push to a branch is a release, that branch is no longer a place for experiments.

### The handoff document: what the agent reads first

The project has a file the agent loads at the start of every session. In Claude Code it's `CLAUDE.md`. It has to be readable by a human from top to bottom, and mine contains:

- what this product is and what it replaces;
- how to run it, which scripts, which environment variables;
- **which branches deploy on push** — in plain words: "a merge into these branches is a deploy";
- the contract with the back-end: a table of endpoints and, separately — the fields the back-end promised but isn't sending yet, with the date we proposed them;
- **decisions and rakes that must not be rolled back without a reason** — every entry: what we decided, why, and what breaks if you revert it.

The last section saves the most time. Because a rule without a "why" is something the agent's next session will calmly cross out.

And one more thing: a stale sentence in this file costs more than a missing one. Because the agent will believe it. So every section that describes state is dated, and when the agent sees that something changed (a branch appeared, a remote moved), it fixes that in the same commit and mentions it in the report.

> **Technical note.** Until the back-end is ready, the platform uses mock data that can be turned on with one setting. Those mocks never reach production and contain no real names, IDs, or links. Client exports never go into git.

### Working with a back-end team

- The API contract lives in the repository and counts as the main document. When documents diverge, `CLAUDE.md` says which one wins.
- I propose new fields in writing, with key names and format. Until the back-end sends them — the interface shows an honest empty state, not made-up data. Plus a dev toggle to show the client what the filled-in state will look like.
- An error in the interface names the cause. "API responded with HTML instead of JSON" is better than "unexpected token", because the fix is on the other side, and that team has to know where to look.

### Checks before every push

Nobody has to ask me to check by hand. The agent checks and shows evidence.

Before any push — a local gate, always in this order:

```bash
npm run typecheck && npm run test && npm run build
```

Then — a check in the browser: run, reload, read the console and the network, click through, screenshot. If a test failed — quote it. If a step was skipped — say which one and why. If the pipeline passed — give the run id. "Pushed" doesn't equal "deployed": the agent watches the pipeline to the end and reports.

When testers report a bug, the agent first tries to reproduce it before changing anything: locally, on the deployed version, and in another browser. If the issue happened on a tablet, it checks touch too. If the bug doesn't appear, the agent records what it checked and what details to ask the tester for.

### Staging and production

Staging is for me and the client. Production — only after both of us have checked staging. After every release the agent writes down in memory which commit is where and whether `main` is behind. It sounds like bureaucracy, until you lose half a day once figuring out which version the client has right now.

### And Storybook?

Here it's optional. A platform for one person with a relatively small number of screens — and I could have done without it. But if your product is going to grow or another team is going to pick it up, Storybook is worth setting up from the very start, as I wrote above. Easier than adding it later.

### What to take from this

A real product differs from a prototype not in the complexity of the code, but in the number of rules around the code. Who can deploy. What the source of truth is. How not to lose the client's data. How to talk to the back-end team. None of that is done by the agent — you do it as the product owner, and the agent executes within the limits you've set.

The full set of these rules, in a form you can drop into a new project and start, will be in the context file at the start of the article.

---

## What actually changed

I'm still a product designer. The goal of my work is the same. The stack changed — and so did what my time goes to: not drawing a hundred states, but product logic, testing, architecture, and conversations with the business.

Design engineering is management, not "one prompt and it's done". You set the context, you check, you send it back for rework, you don't let the agent be lazy. If you can do that with people — you'll manage with agents. If you can't — you'll learn.

But I'll be honest about the downsides too, because there are some.

The cognitive load went up. When you assemble a whole flow in a day, your head holds the design, the logic, the components, the rules for the agent, the state of the prototype, and what the client said on the call, all at the same time. And in that stream it's easier to miss a minor detail or a use case you simply used to have time for. Things I once thought through in detail, because there was no other option, now sometimes get skipped. And then they surface as unfinished work — in testing or, worse, with the developers.

So when we say "you can hand over the whole flow in a day", it doesn't mean it'll be the same quality as after a week or two in Figma. Speed here is bought at the expense of depth, unless you deliberately watch for it. You still have to set aside separate time to sit down and think through all the use cases, go over the edge cases, and pin them down in the prototype. The agent won't do that for you, because it doesn't know what you didn't account for.

And no, not everyone needs to go here. But if you've decided to — now you know where to start and which rakes Daiana and I have already stepped on.

---

## Useful links from this article (not all of them)

- **Download this article's context for AI** — a technical md file with rules, structure, and workflow, without my commentary.
- **Daiana's article** — testing plans, retrospectives, multi-prototypes, project knowledge base. [Daiana's article](https://daiana.art/blog/one-product-four-prototypes)
- **Storybook: skill + video** — [github.com/dobzha/dobzha-storybook-ds-skill](https://github.com/dobzha/dobzha-storybook-ds-skill), [YouTube video](https://youtu.be/7zV7lqBH0Fc), [the Storybook article](/blog/i-removed-figma-from-my-design-system-too)
- **How I built this site** — [the portfolio article](/blog/how-i-canceled-framer-and-created-portfolio-with-ai)
- **Telegram** — that's where I write about this more often and shorter: [t.me/dobzha_pro_design](https://t.me/dobzha_pro_design)