The Designer Who Gets Closer to the Code

How to become genuinely technical without losing what makes you a great designer

My founder said something last week that I’ve been turning over ever since. Something to the effect of: designers need to be technical now. AI-native. As close to the code as possible.

My first reaction was defensive. I already annotated my specs. I already speak in tokens and components. I already sit in on engineering standups. Isn’t that close enough?

But the more I sat with it, the more I realized the gap my founder was pointing at wasn’t about syntax or terminal commands. It was about agency. The old handoff model — designer throws a Figma file over the wall, engineer interprets it, designer redlines it back — is breaking down. Not because the tools changed. Because the expectation changed. In a world where one person with Claude Code can ship a working feature in a day, a designer who can only participate in that process through screenshots and Slack messages is a bottleneck.

So I stopped being defensive and started asking a better question: what does it actually mean to be technical as a product designer in 2026?

Being Technical Doesn’t Mean Being an Engineer

The first thing to let go of is the idea that “technical” means writing production code. It doesn’t. What it actually means, for a product designer, is something closer to this:

You understand how the product is built well enough to make better decisions about how it should look and behave.

That’s it. Not shipping PRs independently. Not owning the database schema. Just closing the gap between design intent and engineering reality — which, historically, has been enormous.

According to a 2025 Figma report, 30% of designers now strongly agree that AI tools significantly enhance their efficiency, and that number is rising. But the designers getting the most out of these tools aren’t the ones using AI to generate prettier mockups. They’re the ones using it to collapse the distance between their decisions and their consequences.

There are a few concrete dimensions to this:

Reading the codebase, not just the product. Before designing a feature, open the repo. Not to understand every line — to understand shape. Where does this component live? What states already exist? What’s been built before that you could extend instead of reinvent? This is the kind of context that historically only engineers had, and it changes how you design.

Writing documentation that machines can read. Design systems are no longer just for humans. As one designer put it bluntly: if your tokens aren’t machine-readable, you’re leaving performance on the table. Your design decisions need to be expressed in a form that an AI coding agent can act on — not just a PDF that a developer reads once and ignores.

Prototyping in the medium that matters. A Figma prototype is a conversation starter. A working prototype in a browser, even a rough one, is evidence. The distance between those two things is where most product decisions go wrong.

Enter Claude Code, and Why It’s Different for Designers

Claude Code is an agentic coding tool that lives in your terminal. It reads your files, understands your project, makes code changes, and runs your app. It was built for engineers. But the designers who’ve figured out how to use it have found something interesting: it doesn’t require you to think like an engineer. It requires you to describe what you want clearly, which is something designers are already trained to do.

Meaghan Choi, the designer of Claude Code at Anthropic, doesn’t just use Claude Code as a user — she builds inside the actual codebase with it. She queries what states a component currently has, tests new features directly in production code, and explores micro-interactions at speed. Her framing is important: this isn’t about designers becoming engineers. It’s about gaining enough access to the real product that your design decisions have actual weight.

The mental model shift for designers is this: stop thinking of Claude Code as a tool that writes code for you. Think of it as a collaborator who knows the codebase and can execute what you describe.

The CLAUDE.md File: Your Most Important Design Artifact

Here’s the thing nobody tells designers when they start using Claude Code: the most important thing you’ll ever write isn’t a prompt. It’s a markdown file.

CLAUDE.md is a special file that Claude Code reads automatically at the start of every session. It’s your project’s persistent memory — the context you’d otherwise have to re-explain from scratch every single time. Think of it as the onboarding document for a new collaborator who shows up every day with no memory of yesterday.

For designers, this file is a superpower hiding in plain sight.

What to put in your CLAUDE.md:

Project overview. One sentence. What is this product? Who is it for? “This is a B2B SaaS dashboard for logistics coordinators managing last-mile delivery” tells Claude more than you think. It shapes every decision it makes.

Design system references. Where are the tokens? What are the component naming conventions? Point Claude at the source of truth. “Design tokens live in /tokens/. Always reference these — never hardcode colors or spacing values.”

Your role and context. This one matters more than it seems. Explicitly tell Claude you’re a designer, not an engineer. “I am a product designer. When I ask for code changes, explain what you’re doing in plain terms, break changes into small steps, and flag anything that might affect other components.” This single instruction changes the quality of every interaction.

Interaction and animation principles. If your product has a design language around motion — easing curves, transition durations, animation principles — document them here. Claude will apply them without being reminded every time.

What not to touch. The sections of the codebase that are off-limits or fragile. “Do not modify anything in /api/. Do not change shared layout components without flagging first.” This is your safety net as a non-engineer working in a live repo.

Known gotchas. Every project has them. The quirky workaround in the auth module. The component that’s being refactored and shouldn’t be extended. The thing that always breaks on Safari. Write them down. Claude will work around them.

The best advice on writing CLAUDE.md comes down to one principle: less is more. Don’t stuff it with everything you could possibly want Claude to know. Give it what it needs to do the work you’re actually doing, and tell it where to find the rest. A focused 100-line CLAUDE.md outperforms a bloated 500-line one every time.

Custom Slash Commands: Turning Repeated Work Into a Single Word

Once your CLAUDE.md is solid, the next unlock is custom slash commands. These are markdown files you store in .claude/commands/, and they become reusable prompts you can call with /command-name in any Claude Code session.

For designers, the use cases are obvious once you see them:

/component-audit — asks Claude to scan a specific component for inconsistencies against your design system. Spacing violations, hardcoded colors, and missing states. Run this before every design review.

/new-screen — a template prompt that walks Claude through creating a new screen: which tokens to use, which existing components to pull from, and what empty/error/loading states to include.

/copy-review — feeds a section of the UI to Claude and asks it to evaluate the copy against your brand voice guidelines (which live in your CLAUDE.md).

/accessibility-check — prompts Claude to evaluate a component against WCAG criteria and flag issues with contrast, focus states, or keyboard navigation.

The point isn’t to automate your judgment. It’s to stop spending cognitive energy on the scaffolding so you can spend it on the decisions that actually matter.

Drag, Drop, and Annotate: The Visual Workflow

One thing that surprises most designers when they start: Claude Code handles images well. You can drag a screenshot directly into the terminal window, annotate it by circling the area you want changed, and Claude will often fix it in one shot.

This changes how you use Figma in the workflow. Instead of the traditional handoff (Figma → spec → dev), you start working more like this:

1. Design the change in Figma (or sketch it)

2. Screenshot it

3. Drop it into Claude Code: “The spacing between the list items feels off — the design shows 16px, the current implementation has 8px. Fix this.”

4. Claude makes the change in the actual codebase

5. You check the live output, iterate

It’s not a replacement for careful design work. It’s a tighter feedback loop between your design decisions and their real-world consequences.

The Mindset Shift That Makes All of This Work

There’s a reason most designers stop at “I asked ChatGPT to make me a button.” The tools work. The mindset hasn’t caught up.

The designers getting the most out of Claude Code share a few things in common. They think in outcomes, not outputs — they describe what they want to happen, not how to code it. They maintain context deliberately — they invest time upfront in CLAUDE.md so they don’t waste time explaining the same things repeatedly. And they stay close to the real product — they’re not designing for a Figma file. They’re designing for the things users actually use.

Your founder’s challenge isn’t asking you to become an engineer. It’s asking you to stop designing at a distance. The tools to close that gap exist. The question is whether you’re willing to open a terminal.

A Week-One Checklist

If you’re starting this week, here’s the minimum viable version:

• Install Claude Code (desktop app or npm install -g @anthropic-ai/claude-code)

• Clone your product’s repo locally, think of it as duplicating a Figma file; you can’t break production

• Run /init In Claude Code to generate a starter CLAUDE.md

• Rewrite it from scratch with your own context: product overview, design system location, your role, what not to touch

• Make one small change — a color, a spacing value, a copy tweak — and watch it happen in the live codebase

• Create your first slash command for something you do repeatedly

One week. One terminal. One file. That’s the on-ramp.

The Open Question

Design has always been about closing the gap between intention and reality. We sketch to make ideas visible. We prototype to make interactions tangible. We test to make assumptions falsifiable.

Claude Code is another instrument in that process, one that closes the gap between design and production in a way nothing else has before.

The interesting question isn’t whether designers should use it. It’s what kind of designer you become when you do.

What’s one thing in your product you’ve always wished you could change yourself, without waiting on an engineer? Start there.

References

• Anthropic. Best Practices for Claude Code. https://code.claude.com/docs/en/best-practices

• Anthropic. Using CLAUDE.md Files: Customizing Claude Code for Your Codebase. https://claude.com/blog/using-claude-md-files

• Builder.io. How to Write a Good CLAUDE.md File (February 2026). https://www.builder.io/blog/claude-md-guide

• Builder.io. Claude Code for Designers (March 2026). https://www.builder.io/blog/claude-code-for-designers

• Christina Yang, Medium. Using Claude Code SMARTLY as a Product/UX Designer (July 2025). https://medium.com/@christina0w0

• David Robinson, Medium. AI in Product Design: Where We Are Now in 2026 (February 2026). https://davidrdesign.medium.com

• Figma. AI Data Report 2025. https://figma.com/reports/ai

• HumanLayer Blog. Writing a Good CLAUDE.md (November 2025). https://www.humanlayer.dev/blog/writing-a-good-claude-md

• Startup House. The Future of Product Design: Building AI-Native Digital Services (March 2026). https://startup-house.com/blog/future-of-product-design-ai-workflows-2026

• Tyler Burnam, Medium. How I Use Claude Code (June 2025). https://tylerburnam.medium.com/how-i-use-claude-code