People hear "AI-assisted design" and picture an autopilot: you describe a screen, the machine builds it, you ship it. That is not what this is, and after a year of building real products this way, I don't think the autopilot is where the value is anyway.
Last year I joined a high-end consumer product, a luxury registry for a demanding audience. The client arrived with a prototype an AI had generated. From a distance it looked fine. Up close it wasn't: inconsistent spacing, colors with no system behind them, and "components" that were really just duplicated rectangles. I wasn't brought in to redo it from scratch. I had to give that raw output taste and consistency without throwing away the speed that produced it.
Doing that changed how I work, though not in the way people assume. The AI didn't take over. I had to build a real system around it, and over the project that system became a repeatable way to run design production across several agents at once. The most important piece of it, and the part I want to start with, is how the AI knows what it's doing in the first place.
Atlas: a memory the whole team shares
The first real problem had nothing to do with design. It was context.
Every time I opened a new session, the AI started cold. It didn't know what we had decided last week, who the users were, or why we had ruled out an approach two meetings ago. And I wasn't the only one working this way. Other people on the project had their own sessions, and each one carried a slightly different version of the truth. We were quietly drifting apart, and the AI was confidently helping each of us drift in a different direction.
So I built Atlas. It is a shared context layer, versioned in the repo, that every person's AI reads from before it does anything. The idea behind it is plain: the chats are throwaway, but the context has to persist, and it has to be the same for everyone.
Atlas has three layers. At the bottom are the deep sources, the actual material of the project: the brief, meeting transcripts, tickets, the codebase. Those stay in the tools they already live in, reached through connectors. In the middle is a short summary that every session reads first. I kept it under a hard size limit on purpose, because the moment a "summary" grows to fifty pages, nobody reads it, human or machine. It holds the team, the current decisions, the open risks, and a map of where to find everything else. At the top is the working repo itself.
Two things keep it trustworthy. The first is a source-of-truth hierarchy: when two documents disagree, there is a written rule for which one wins, so nobody has to guess. The second is that Atlas mostly maintains itself. A meeting transcript gets turned into a digest, and a decision worth keeping gets promoted into a proper record, handled by small agents whose only job is to keep the context clean and current. New decisions fold back in as they happen instead of dying in a chat log.
The payoff sounds modest: everyone, and every agent, starts from the same understanding. In practice it is the thing that made everything after it possible. Without it, parallel work would have just meant parallel drift.
Running work in parallel without collisions
With shared context in place, I could run work in parallel. I set it up as an orchestrator with a set of executors: several agents working at the same time, each in its own isolated branch of the repo, each scoped to stop at a commit and a pull request. Merging into the main branch stayed a separate step, gated the same way an engineering team gates it.
The danger with parallel work is that two agents touch the same file and quietly undo each other. So every stream of work had to claim its area before writing any code, log what it changed, and treat a short list of shared, high-traffic files as one-at-a-time only. It is ordinary engineering hygiene, pointed at design production.
The design system lived in code
The deliverable stopped being a polished Figma file. It became a design system in code that both Figma and the running product pulled from.
Tokens lived as structured data in the repo. A build step turned them into the CSS and the framework presets the app used, and that same data stayed in sync with Figma's variables. The model had three tiers: raw primitives, then semantic roles, then component-level tokens. One rule kept it honest. Components never carry a raw color value, only tokens, and a check for stray hard-coded colors had to come back empty before anything shipped. After that I wasn't chasing consistency by hand. The system held it.
Agents that reviewed other agents
If the AI is producing work, something has to check it, because I can't manually review everything it makes. So I gave quality its own agents that ran before every publish.
One audited mobile layouts and flagged anything under the minimum touch size or breaking the grid. One read every piece of copy against the brand's writing rules. A third watched the design system and didn't stop at reporting problems. It fixed them in its own branch and opened a pull request until things were clean again. Separately, a visual check confirmed that a change I meant to be invisible really did move zero pixels on the main screens. The producing was automated and so was most of the reviewing, which is what let me spend my attention on decisions instead of the sweep.
Where it gets hard, and it does
None of this is free, and I would be lying if I made it sound like magic.
Building Atlas and the agent setup is real work before you get any speed back. On a small project it would be overkill. It only pays off because this work is large and runs for months.
The agents themselves need managing. Left alone, they drift. They will confidently produce something that looks right and is subtly wrong, and if you are not checking, that wrong thing ships. More than once I caught an agent taking a shortcut I never asked for, or trying to hand its own task off to yet another agent instead of just doing the work. A good share of my time went into writing the guardrails that keep them honest, not into the design itself.
There is a quieter risk too. When the machine is fast and usually right, it gets tempting to stop looking closely. That is exactly when quality slips, because the AI has no taste and no stake in the result. The speed is real, but it raises the cost of not paying attention. It does not remove the need to pay attention.
I keep the whole thing useful by staying a little suspicious of it. That tension is part of the job now.
So, is it autopilot?
No. That is the honest answer to the question everyone asks.
The AI does the prework and I approve it. It gets the ground ready faster than I ever could alone, and I decide what is good enough to keep. In my own task lists I still mark every step as either an agent's job or a human's, and the human column is the one that carries weight: taste, the close judgment calls, the places where technically correct and actually right pull apart, and the final sign-off before anything reaches a real person. The rule I hold the AI to is the same one I would give a junior in their first week: do the prework, show me, and I will decide.
So the polish didn't disappear. It moved. Figma became the place where I think, explore, and record decisions. The code became the place where consistency is guaranteed instead of maintained by hand. My own work moved from drawing every screen to running the system that draws them, and then deciding what deserves to ship.
That is the version of designing with AI I care about. The machine takes over the parts that were never the point, and I stay responsible for the judgment. It doesn't feel like autopilot. It feels like running a very fast, very literal team that still needs a clear head at the top.