I've always been a code-first designer, but code was slow and design was my first skill, so I mostly stayed in Figma. Agentic tools like Claude Code and Codex changed that. Now I work directly in code at the speed of a canvas.
At Enterpret, a customer feedback platform, my work starts in a folder where Claude Code does the legwork, and ends up as a prototype or a pull request.
The folder
Each workstream gets one folder, with a subfolder per thread of work: research, customer interviews, prototypes and whatever else the work needs. Every Claude Code session for that work opens at the top of the folder, so any session can read what the others produced. The one I'm in most has had 75 sessions since 1 October.
Two files at the top do most of the work.
CLAUDE.md holds the rules and the current priorities. Claude reads it at the start of every session. Mine says which subfolder holds what and keeps a priority stack I check new work against. With the project details taken out, its shape looks like this:
# <Workstream>
Every session for this work opens here. README.md is the index.
- research/ what we learned, and from whom
- interviews/ one folder per person: prep, transcript, debrief
- prototype/ the current HTML prototype
## Current priorities
Check new work against this stack before adding scope.
- P0: ...
- P1: ...
When I reorganised the subfolders once, I added a table to CLAUDE.md that maps old paths to new ones, so sessions from before the move still find their files.
README.md is the index and the memory. It has a status line, a table of the subfolders and a decisions log where every entry gets a date and a reason, newest first. A second CLAUDE.md, in the parent folder that holds all my workstreams, says decision entries are never deleted. When a session needs to know why we paused something or cut it from scope, the answer is in there with a date and the reasoning next to it.
Unlike a Figma file, the folder holds the research, interview transcripts, decisions and prototype code alongside the screens, and an agent can read all of it.
Context comes in through MCPs
Another rule in that parent CLAUDE.md: pull context from MCP integrations instead of writing manual summaries. MCPs (Model Context Protocol servers) are the connectors that let Claude read directly from tools like Slack, Linear, Notion, Granola (my meeting notes) and PostHog (product analytics).
This changes how a task starts. I give a name or a link and say what I need, and the agent gathers the rest. When I plan customer research, the agent looks at product analytics to help pick who to talk to, then writes a short brief on each person before the call. After the call, it files the Granola transcript in that person's interview folder and posts a summary to their Notion page.
Enterpret as a source is my favourite. It has its own agent, so I research our customers with our own product, and it has surfaced problems I wasn't looking for.
Paper is the canvas, and the agent draws on it
I still need a canvas. I use Paper, a design tool whose MCP lets Claude read a file and write onto it directly. I picked it over Figma because a Paper file is HTML, where a Figma file is vectors. Claude already reads and writes HTML well, so it designs in Paper far more efficiently than it can by pushing vector layers around. Since October, my Claude Code sessions have made 2,272 calls to Paper and 44 to Figma.
When I want references, the Mobbin MCP searches its library of real app screens and the agent pastes the matches onto the same Paper page, next to the frame I'm working on. For design work we repeat, we use skills: sets of instructions Claude loads when a task matches them. launch-modal turns a feature's scope and screens into the "What's new" dialog we show after a release, with copy on the left and a product graphic on the right. My writing skill learns from my edits: after a session it logs what I changed, and the next draft starts from those notes.
Production screens replaced our design system
We don't use a design system anymore, at least not one that lives in a design tool. Every mock starts from a production screen, using create-mock, a skill another designer on our team wrote. In capture mode it opens a screen of our app with Playwright, a browser automation tool, reads what's actually rendered, and rebuilds it in Paper with the theme tokens and type from our codebase. I design on top of that copy, by hand on the canvas or by describing the change, instead of assembling screens from a component library.
The skill's first principle is "discover, don't assume", so a mock starts out looking like our app instead of a generic SaaS dashboard. It also removes a job: there's no library to keep in sync with the code, because the code is where the screens come from. When the design turns into a PR, it's built from components that already exist.
What leaves the folder depends on who else is involved
Team efforts get prototypes and specs. Bigger features have a PM, engineers, leadership and often customers with opinions, and they need something to react to before anyone writes production code. For them I build HTML prototypes in the folder, numbered so everyone knows which version they're looking at, and publish them, with a spec alongside, to an internal static host with one command. The host supports comments anchored to parts of a page, and the same command-line tool that publishes a page reads its comments back. When I'm the reviewer, I click through the prototype with an annotation tool and paste its export into the next prompt. The export lists each note with the CSS selector of the element it points at.
Self-led work goes straight to a pull request. When nobody else needs to sign off on the direction, a prototype is an extra step. I make the change in our frontend repo with Claude Code, raise a PR, and get feedback in review and from the product itself. These tend to be contained pieces of work, like a visual cleanup across several pages or an experiment behind a feature flag. Since November last year I've opened 116 PRs across Enterpret's repos, 95 of them against the production frontend, and 93 have been merged.
The line between the two blurs once a team agrees on the direction. Then the prototype often turns into my PRs too, split into a stack of small ones that each add one part of the page.
UX Pulse: the same habit, for the whole team
The design team runs a version of this together. Every Monday an automation in Enterpret's agent produces a list of papercuts, the small UX problems people keep running into. We triage it, pick items up and raise PRs. Review rules live in the frontend repo's CLAUDE.md, and an automated check runs each PR against them one by one. I added a papercut-scanner skill to our shared skills repo that audits the Enterpret dashboard in a browser. The goal is for agents to handle the triage, with people stepping in where judgement is needed.
Parts of it still don't work well. Coding agents make architecture mistakes our skills don't catch, so we've talked about running agent review three or four times before a PR goes up. And LLM-based design checks turned out slower and less reliable than plain rules, so we want to replace them with lint rules that run automatically on every PR.
What still needs me
The agent does the gathering and most of the making. Some calls stay with me.
- Anything that goes out under my name. The agent can take email copy I wrote, build a version for each person and check the drafts against the send list. My prompts in those sessions say "DO NOT SEND ANYTHING YET", and sending is a separate step I run myself.
- Deciding what the data means. Connectors make it easy to trust the wrong number. Usage reports can count automated activity as people, and accounts with a missing field quietly drop out of a ranking. Reading the raw numbers before trusting the ranking is still on me.
- The conversation itself. Claude coaches me before and after a customer call. Before, it helps me plan the flow: what to open with, which questions matter most and what to avoid. After, it goes through the transcript with me so I can see what I'd do differently next time, then helps with the debrief and the follow-up. The call in between is mine.
If you want to try something like this, start with the folder. Write a CLAUDE.md with your rules and priorities, keep a dated decisions log in the README, connect the one tool you copy-paste from most, and start every session for that project from there.