When designers start building

It works, but there’s a gap between designing something and seeing it ship the way you intended. At Automattic, we wanted to know what happens when designers step into that gap themselves. Not to become engineers, but to design inside the real product: working with actual components, real APIs, and the constraints of production code. Think of it as the next evolution of prototyping: instead of simulating how something will work, you’re shaping the thing itself.

So we ran a hands-on workshop at our biannual team meetup. Around twenty designers set up local development environments from scratch, and started working directly in their product’s codebase and shipping PRs. Here’s what we learned.

The question behind the workshop

Many designers are sitting with the same quiet question right now: what does AI mean for our role? The answer we kept returning to was about proximity: getting closer to the product as it actually exists, not just as it looks in Figma.

That meant rethinking what design artifacts look like. What if the prototype was the product? What if, instead of mocking up a flow in Figma and annotating the details, a designer could build it with the same components and data the shipped version would use, and iterate on it there?

Two of us facilitated a pair of 40-minute breakout sessions with a single goal: by the end of the workshop, every designer in the room would have a functioning local dev environment on a codebase they hadn’t worked on before, plus a Claude skill—a reusable set of AI instructions—that would walk them through opening their first contribution.

Two sessions, same direction

The first session was the conversation. We kept circling one practical question: how do we bring design expertise closer to the final polish of the product—not just the mockups—while still respecting the engineering expertise already in the room? One of our design leads summed it up: 

The goal is co-owning the output with engineers, not handing work over and hoping.

The second session was more grounded. We walked through real examples from our own work—contributions one of us had been shipping for months. Reworking conditional empty-state messaging (#). Designing a post-publish flow (#). Building a pre-publish checklist from scratch (#). These weren’t merely engineering tasks done by a designer, they were design decisions that happened to be made directly in the codebase, using the same components and constraints as the shipped product. The point wasn’t “here’s how to code.” It was “here’s what it looks like when your design environment is the product.”

What we learned

The bigger shift isn’t the tooling. It’s where design work happens now. Design iteration used to live almost entirely in Figma and then get translated into code. With AI in the loop, a lot of that iteration is moving into the codebase itself: tweaking spacing, trying a different empty state, rewording microcopy, rethinking a small interaction—all using production components, real data, and actual platform constraints. Figma is still where most of the bigger UX thinking starts. But the local dev environment is becoming a design tool in its own right: one where your prototype is already built from the real thing.

That changes what collaboration looks like. Instead of a baton pass, designers and engineers iterate on the same artifact. The designer proposes a change in code; the engineer catches the architectural edge cases the designer didn’t see. They go back and forth on the same surface. The result ships faster, and with more design care, than the old handoff could deliver.

But the tool that made the biggest difference wasn’t AI. It was a relationship. One of us had been shipping for months before the workshop because she had an engineering buddy—someone who talked through trade-offs, explained what broke and why, and treated her work as worth investing in. Over time, they built a shared language. Both sides learned. AI made the code feasible. The engineer made it feel safe to try.

What we’d tell another team

• Your local dev environment is a design tool. Real components, real APIs, real constraints: the prototype and the product become the same thing.
• Figma for thinking, code for calibrating. AI lets designers rework microcopy, try empty states, and tweak interactions directly in the codebase.
• Handoff becomes a shared surface. Designer and engineer iterate on the same artifact. The result ships faster and with more design care.
• An engineering buddy accelerates everything else. A specific engineer who reviews your work, explains failing tests, and encourages you to keep going makes trying feel safe. 
• Show real examples, not a generic tutorial. Designers need to see what working in code actually looks like before they believe it’s possible for them.

What’s next

The workshop was a starting point, but the momentum continued on its own. Designers who’d never touched a terminal are now treating their local dev environment as another design tool—a place to bring their expertise, not just hand it off. We’re already seeing a growing number of designers shipping and merging pull requests on their own.

Engineers are happier too. When designers handle the visual polish and microcopy directly, engineers can focus on the problems that need their expertise: architecture, performance, the hard systems work. Everyone’s doing more of what they’re best at, and the product is better for it.