Moving a design team into the codebase at GetAccept

When R&D at GetAccept started shipping with agents, design had to change with it. Finding the right tool was hard in itself: none of the ones we tried did everything we needed, so I ended up building my own. Just as demanding was helping a team of designers leave the visual tool their craft was built around, and start working in a terminal and in Git.

This is the story of that transition, and of the coaching, teaching and reassurance it took. How the tool itself works is covered in the companion case, Designing at the speed of development.

Why we had to change

I joined GetAccept in August 2025 to lead a team of six product designers, working the way most design teams still do: explore in Figma, hand over to engineering and review what came back. As engineers started running agents in parallel and shipping at a new pace, that process was about to make us the bottleneck, so we moved design into the codebase, where the product already lives.

A big ask

For many designers, Figma isn't just a tool. It's where their professional identity lives. Asking them to leave it can sound like asking them to stop being designers.

In practical terms, we were asking people to go from a visual tool they were extremely comfortable in to a terminal and Git. That's a steep learning curve for anyone, and it came at a time when the industry is full of stories about AI replacing designers.

So the worry wasn't only whether we could learn this. It was whether we were losing our craft, and for some of us, whether we were losing our jobs. Those were fair questions, and I didn't want to wave them away.

Coaching, teaching and comforting

Getting the team through the change took a lot of coaching, teaching and comforting, and I didn't try to shortcut any of it. It happened in our weekly design sessions, in one-on-ones and in workshops I held for the team.

Teaching covered the practical side: the terminal, Git, and how to work with an agent instead of a canvas. Coaching was about confidence: working directly in the real product, and trusting your own judgement when the agent produces something that only looks finished.

Comforting mattered as much as either. I was honest that the work was changing, and just as clear that the craft wasn't going away, and that the team was needed more, not less.

The worries eased over time, as the quality got better and better. Fears turned into opportunities once designers noticed how much their output increased and how much their mental load decreased.

Taking the concerns seriously

When resistance came, it was about quality, and it was fair. Early versions of ga-designer produced work that wasn't good enough, especially before it could see what it had built, and designers who know what good looks like could tell straight away. They were right.

The answer was to improve the tool. Giving ga-designer the ability to see its own work was the turning point. Today designers log feedback on the tool through the tool itself, and each report becomes a Linear ticket that I act on, so the people using it shape what it becomes.

The craft, reframed

What helped people most was reframing the change: the craft wasn't disappearing, it was changing. Hierarchy, flow, copy, accessibility, interaction and taste matter just as much in code. The difference is working in the real material and seeing the real result, instead of waiting for a handover to find out how it turned out.

The designers' role grew too. The conventions an experienced designer applies without thinking now shape what everyone in R&D designs, so their expertise travels further than six designers ever could on their own.

Where the team is now

I'm extremely proud of how the team took this on. They trusted the direction and stayed open through an uncomfortable learning curve. Today everyone works in Claude Code, directly against our product.

We've also built a learning culture inside the team, where everyone brings their findings on new ways of working and the methods they use. My designers develop their own Claude skills and workflows, shaped to how they think and work, while our shared tool stays the basis for everything. There's still room for individual ways of working, and whenever a method proves itself truly useful, it benefits all of us.

What comes next

We'll keep building and extending the tool together. As the models underneath it become more powerful and capable, so does ga-designer, and so does what the team can do with it.

What changed

  1. The whole team made the move

    Every designer now works in Claude Code, prototyping directly in our codebase.

  2. No going back

    Asked the Sean Ellis question – how would you feel if you could no longer use ga-designer? – my designers made it clear they wouldn't want to return to how we worked before.

  3. A learning culture

    Designers share new methods and build their own Claude skills and workflows on top of our shared tool.

  4. Designers shape the tool

    Designers log feedback through ga-designer itself, and each report becomes a Linear ticket that I act on.