Claude Code - a car big enough for designers, product managers and developers
We attended Lydia Hallie's Frontend Masters workshop on Claude Code. Even though it was aimed at developers, it confirmed for us that the line between designer, PM and developer blurs when AI tools become available to everyone.
Last week we attended the Frontend Masters Deep Dive workshop on Claude Code, led by Lydia Hallie from Anthropic. Claude Code is an AI assistant that, powered by language models like Claude Opus, reads files, suggests changes, keeps track of agents, can use skills and runs commands. Anthropic also has a simpler desktop app, Cowork, for those who want to try it without a terminal — and they recently added expanded support for Claude Code there.
The workshop was clearly aimed at developers. “Comfortable in a terminal and with git. Node.js or Python set up locally.”
The workshop was excellent — hands-on, and gave us the chance to ask Lydia questions directly. She was methodical and pedagogical. We both felt it held up the whole way. That says something. Roles are shifting. A designer, PM or developer can work in each other’s spaces without changing jobs. It takes curiosity and collaboration, not just learning to “code”.
In the early days of open source, there was a lot of talk about the democratization of code. The feeling now is that language models, together with open source, have actually delivered on that. We’ve gone from professors in white coats explaining how the holes should be punched, to anyone being able to describe what they want and get it done.
Hanna and I have been working with Claude Code a lot — about a year now. Even though Hanna doesn’t have a developer background, she keeps up just fine. That’s exactly why this walkthrough was so valuable: a chance to see what you actually can do to build a more effective workflow, and what’s there to be picked up. The big win: if you don’t know what’s possible, it’s hard to even ask the question.
It’s the shell, not the model
The first thing Lydia said was: “Claude Code is not the AI model. It’s the shell around the model.”
The model is the engine: Opus, Sonnet, Haiku, GPT, Gemini. The shell is the car. Permissions, context, rules, workflows. Everyone has access to the same engines now (well, except maybe Claude Mythos…). The difference is what you’ve built around them. Which car do you want to drive?
What the shell looks like in practice
Lydia gave us a taste. Here are some of the parts we took away — or had confirmed — from the workshop:
Context, context, context — not to nag, but context matters. It’s about how much you let the language model understand what you actually want it to do. Very similar to what we do as UX designers when we give a user the right information at the right moment so they can do what they want in a system or interface.
CLAUDE.md — a simple text file in the project that the AI loads into context almost as the first thing every session. Claude can create one for you automatically, so you have a starting point. Then you fill it in with what’s specific to you, your project or your team. For a designer it might be: “Always use our design tokens, never hard-coded colors. Follow our design system in Figma. Write UX copy in the ‘we’ form, avoid exclamation marks. Our tone of voice is direct and concrete.”
Permissions — what the AI is allowed to do freely, what requires approval, what it has to show as a plan first. “Can change colors and spacing freely. Has to ask before touching the component library. Has to show a plan before anything is published.” Configurable via /permissions, and reduces manual oversight of routine commands that are safe in your environment.
Different modes — Claude Code supports several modes. Use them.
Plan mode — perfect for working in a planning session in parallel while Claude works on the same branch in another session. When Claude is done in the executing session and you’ve saved/committed, you can immediately start the next plan in the prepared planning session.
Auto mode — Claude Code supports an auto mode where Claude Opus evaluates the commands being run and judges whether they’re safe to execute. Safer than running with no restrictions, and makes it possible to parallelize more and let parallel sessions explore different design directions.
Git worktrees — another way to work more in parallel, with multiple sessions against different copies of the same git branch. Built-in support in Claude Code, but a bit advanced — Lydia said she doesn’t use it as her primary approach.
Skills — recurring workflows saved as text. “This is how we review design tokens. This is how we run accessibility tests under WCAG 2.2. This is how we do brand reviews.” Written by a designer, run by a developer. Or the other way around.
Hooks — rules triggered automatically in Claude Code’s lifecycle. The simplest example is a terminal like Cmux that sends a notification when a session needs input from you. Especially useful when you’re working on something else in parallel and want a nudge to check back in when Claude needs a hand or feedback.
MCP servers — plug in your own tools and data sources. Figma so Claude can read designs directly. Linear for tasks. Notion for design documentation. Your internal component APIs.
Subagents — multiple AI agents with different roles working in parallel. One does (or prepares for) user research, one builds wireframes, one reviews accessibility.
Plugins — package your team’s CLAUDE.md, skills and hooks as an installable unit. Your entire design system’s rules, review flows and guidelines in a single command.
You can run Claude Code without any of this. But with a bit of attention to the shell — the car you’re sitting in — you stop repeating the same instructions, the AI stays inside your guardrails, and small jobs that would otherwise die in the backlog get done. What used to live in one person’s head becomes something the whole team can pick up.
That the shell — skills, environment, what you’ve set up — really matters got confirmed in an unexpected way: Lydia had switched computers before the workshop, which meant she ran into trouble with parts of the session around setting up an MCP server. We saw it as a positive. Things got more real, and it gave more room for the participants to ask the questions we were actually interested in.
Designers and developers on shared ground
In the workshop, Claude Code changed a button color from light blue to dark blue. Three lines of CSS. One diff. Done. That’s design work, but it happened in the developer’s tools. And it could just as well have been started by a designer.
The boundary becomes workable, not dissolved. Designers don’t become developers. Developers don’t become designers. The deep crafts remain. But the in-between — CSS tweaks, layout adjustments, flow prototypes — becomes shared ground. And that in-between is exactly where good UX starts paying back in conversion and customer loyalty, once small fixes stop getting stuck in a backlog.
This isn’t a future projection. It’s a way of working that already exists, and it works best when the whole team understands the car we’re driving together.
Want to explore how your team could start working like this?
We help teams find the right entry point. A workshop, a pilot session, or a conversation about where you’d start. No coding background required. Our full-day training for teams getting started with AI in practice is often a good place to begin. Get in touch and let’s talk.