Ways of Working & AI Delivery Model
How I grew the Arcos UX team from one designer to four, built the design systems and ways of working that enabled semi-autonomous output, then pioneered an AI delivery model where designers work in VS Code against the production codebase — outputting Higher Order Components that engineering can review, trust, and merge.
The question I came in asking wasn’t “how do we design better?” It was “how do we build a team and a way of working that makes better design the natural output?” That foundation work came first. What came after it is something I didn’t have a name for when I started — a delivery model that’s redefining what the boundary between UX and engineering actually means.
Building the foundation
When I arrived at Arcos I was the only full-time designer, working alongside two consultants. Growing that to three Senior Designers plus a consultant wasn’t just a hiring story — it required building the environment where senior people could do senior-level work without everything routing through me. That meant structured design feedback workflows, purposeful meeting structures, UX debt documentation, and shared design principles that gave the team a frame for making decisions independently.
The design token system grew in parallel. We started with something basic — a rule against raw values — and matured it into a three-tier semantic architecture: Core tokens for the raw palette and scale, Theme.Base for brand and platform-level decisions, and Theme.Component for semantic intent. As that maturity increased, something specific happened to the handoff: when a wrong token appeared in the dev environment, it became easy to identify and correct without a lengthy search-and-replace. The right answer became structurally easier than the wrong one. That’s what a design system is actually for — not enforcement, but making good decisions the path of least resistance.
The model that came next
By mid-2025, the foundation was solid enough to push further. I started exploring what it would mean for UX designers to work directly in VS Code with AI agents against the actual production codebase — not as a curiosity, but as a delivery model.
The distinction that matters: AI-assisted prototyping tools like Lovable, Bolt.new, and Figma Make are fast and generative, but the AI selects its own component library. The output has no relationship to the production codebase. Engineering correctly treats it as throwaway. That’s not a criticism — it’s just what those tools are built for.
What we built is different. UX designers work in VS Code using AI agents that operate within the actual front-end dependency tree — same tokens, same components, same patterns engineering already owns.
The output is Higher Order Components: not mockups, not scaffolding, but HOCs that wrap real production components with design intent baked in at the right abstraction level. The output is reviewable, trustable, and mergeable. It speaks engineering’s own language.
Building the infrastructure to make it real
To make this model work, I built an AI-enabled design system npm package. The architecture is a monorepo — a package for each theme, where theme means a combination of tech stack and CSS theme — structured to give AI models deep, structured context on our components, patterns, and tokens.
Dev team capacity wasn’t available. I built it alone. I brought tech leads and developers in as user-advisors — their input shaped the code structures that would work with the production environment — but the vision, architecture, and execution were mine.
Paired with Figma, Zeplin, and Storybook MCPs, an AI working in this context can read a design file and produce front-end code that’s already on-system. The right tokens. The right components. The right spacing. Not because someone made good judgment calls, but because the design system is the AI’s frame of reference. All four designers on the team are now working in VS Code with AI agents, sharing discoveries and expanding their agent skills files to continuously refine the design-to-code workflow.
What it changed in practice
On the Lighthouse project, this model produced a concrete outcome: a 3-day Shape Up Delivery Kickoff replaced what had previously been a 2-week investigation sprint. In three days, the team could size deliverable capabilities within the 6-week window and hand off working front-end code — agnostic of data and business logic, ready to be wired to APIs by engineering — with design intent already at the right fidelity.
The goal was never to make UX do development. The goal was to make the handoff disappear.
The culture change that’s still in progress
The hardest part of this isn’t technical. The Tech team isn’t monolithic. Engineers who are already AI-minded see the value and are active advocates — the Zeplin MCP has real traction in that group, and the conversation has shifted from “should UX be producing code at all” to “what does the review and merge process look like.” That’s a more tractable problem.
Engineers who are skeptical of AI, or uncertain, tend to feel that producing trustworthy code requires formal engineering training. That’s a fair position. I’m not trying to argue past it — I’m trying to demonstrate past it. Showing output before pitching the model is the only thing that actually moves the needle. We’re building advocates one demonstrated outcome at a time.
The underlying structural argument I’m working: the teams that will move fastest in an AI-assisted delivery environment aren’t the ones with the most developers. They’re the ones where each role does the work requiring their specific expertise, and AI handles the translation between them. UX owns the V. Engineering owns the M and C. That’s not a workflow change — it’s a structural argument for how product teams should be organized.
What this shows about how I lead
I’m comfortable operating at multiple levels at once. I can build an npm package alone when the situation requires it. I can hold a long-term structural argument across an organization and work it through culture and demonstrated outcome rather than mandate. I can grow a team from a single designer to a group of seniors doing novel work, and give them the environment to keep pushing further.
The foundation and the model aren’t separate stories. The foundation made the model possible. And the model is what the foundation was always pointing toward.