Designing in the age of AI agents
For most of my career the boundary was clear. Designers made the intent, engineers made it real, and the handoff between them was where quality quietly leaked away. Agents collapse that boundary. The interesting question for designers now is not whether to use AI, but what our job becomes when the distance between a decision and a working artifact drops to near zero.
WHAT I’VE FOUND BUILDING REAL BEHAVIORAL-HEALTH SOFTWARE THIS WAY
The unit of design work is changing
A mockup is a promise that something could exist. It still has to be interpreted, negotiated, and rebuilt in code, and every step loses fidelity. When I can direct an agent to produce the working thing, the mockup stops being the deliverable. The deliverable becomes the system that the agent applies: the tokens, the component rules, the accessibility constraints, the copy voice. Design shifts from drawing screens to encoding judgment.
That is why I stopped thinking of a design system as a library of components and started treating it as a set of instructions an agent can follow. I built our design system first, then wrote its patterns down as skills an AI could read, then used those skills to build a FHIR form builder directly in code. There was never a Figma file for it. The system carried the rules, the skills taught the agent to apply them, and I designed by building in the medium the product actually ships in.
Leverage is real, and it is not free
The honest version of the AI story is not that it makes work disappear. It is that it removes the slowest, least valuable steps so a small team can hold a much larger surface. I run design across five products, and AI is a large part of why that is possible: an agent wrote hundreds of code-level accessibility findings into our tracker with file and line references, so I could spend my time on the remediation strategy instead of the transcription. A contrast-safe color engine turns one brand color into a full themed, accessible palette, so whitelabel onboarding is an input rather than a week of hand-tuning.
None of that is magic. It works because the constraints are written down well enough that an agent cannot quietly get them wrong.
The moat is judgment, not speed
When everyone can generate a screen in seconds, generating screens is not the skill. The skill is knowing which screen is correct, and being able to say why. In healthcare that is not a preference argument. A fabricated clinical code silently corrupts outcome measurement and billing. A form that clears a patient’s answers when a field is hidden is a data-integrity bug wearing a UX costume. An agent will happily produce any of these unless someone with domain judgment has defined the guardrails and the tests that hold them.
So the practice I trust pairs speed with rigor. Fast because of AI. Trustworthy because of fundamentals: decision records that explain why, tests that pin behavior, accessibility enforced in the pipeline rather than audited at the end. The agent moves quickly inside a fence I am responsible for building.
What this asks of designers
Three things, in my experience. Learn enough of the medium to build in it, because the people who can close their own loop will set the pace. Get precise about intent, because vague direction produces vague output at high speed, which is worse than slow. And take ownership of correctness, because the moment your design ships as working software, its bugs are your bugs.
The designers who thrive will not be the ones who resist agents or the ones who hand everything to them. They will be the ones who treat an agent as a very fast, very literal collaborator, and who do the harder human work of deciding what is right.
That is the job I am building toward: design at the system level, built close to the code, with AI as a multiplier on top of judgment that does not come from a model.
See it in practice: Forming, the design system, and my process.