I am a product designer. I am in Figma every day. For the last year I have also been in Claude Code most days, and the heatmap on how I work shows what that looks like over twelve months. People see that chart and ask the same question: what does a designer do in a terminal?
I do not ask it to design. I ask it to build what I designed, and to do the parts of my job that were never design in the first place.
The four jobs I give it
Prototypes in hours. The old prototype was a Figma flow with hotspots. It looked right and did nothing. Now I build the prototype in the real stack, with real data shapes and real states, and take it to customers the same week. People react to a thing that works in a way they do not react to a picture of it. Engineering commits after that, with the feedback in hand.
Components on spec. Most of my design work is systems: tokens, components, the rules that keep a product consistent while it grows. With the rules in a file next to the code, I write the spec for a new component and the agent builds it. It comes out typed, on the tokens, in both themes. I review it like a pull request from a colleague. I wrote the whole setup down in a design system your coding agent can use.
The site and its chores. This site is built with Claude Code, and so are the metadata, the sitemap, the RSS feed, the image pipeline and the MDX that renders this article. Each post now exists in two languages, and the plumbing for that took one afternoon. A designer used to wait for a developer for each of those things. Now the wait is a few minutes.
Data and scripts. Things that were never UI. The script that turns my training data into one sentence each morning, which I described in my watch tracks everything, Claude explains it. The scripts that generate the activity charts on this site from GitHub and from my own Claude Code logs. Small tools I would not have written by hand, because the writing would have cost more than the tool was worth.
The parts I keep
The brief. What the product is for, who it is for, what the one action is. If I cannot write that down, no tool will get it right, and the agent will fill the gap with the average of the internet.
The first version of a new pattern. When something has not existed in the product before, I draw it in Figma first. A sketch rather than a polished mockup, enough to settle what is on the screen, what is not, and what comes first. Once that exists, the build is translation, and translation is what the agent does well.
Taste. Each decision about what looks right, what feels off, what is one element too many. The agent can propose and I decide. Half of the value I add is saying no to things that work.
The review. I read each diff, and I read the diff rather than the summary the agent writes about it. A model is confident about what it changed and sometimes wrong. The file is never wrong about what is in it.
The setup that makes it reliable
A good session is mostly set up before it starts.
- Rules in a root file.
CLAUDE.mdwith the design rules, the copy rules, the workflow: which branch, how to verify, what never to do. The agent reads it at the start of each session, so I say these things once. - A reference it can search. The design system document: tokens, the type scale, a catalog of each component with when to use it. Half of "build me X" is answered by "we already have X".
- Hooks. A small script that runs after each edit to a component and reminds the agent of the three rules it is most likely to break. Twenty lines, and it has saved me more cleanups than anything else in the setup.
- A sandbox route. A page that is not in the sitemap, where new pieces get tried before they touch a real page. The agent builds the piece there, I look at it in the browser, and only then does it move.
- A branch per idea. They are cheap to throw away, and I throw away a lot of them.
- Content in data files. Projects, testimonials, articles, all data. The agent edits a record rather than a page, and the page cannot break in the process.
How a session goes
I say one thing. Not "redesign the blog" but "the blog index should be a list of rows: date, title, reading time, newest first, no cards". The agent builds it. I open the browser and look at the page, not the summary. If something is off, I say the one thing that is off. Three or four rounds like that and the thing is done.
Then I ask for the diff and read it. Then I commit, with a message that says why, because in six months neither of us will remember.
I keep sessions short. A long session accumulates assumptions, and at some point the agent is working on the product it thinks we have. A new session reads the rules again and starts clean.
The mistakes I made
"Make it nicer." The agent adds things: gradients, shadows, a hover lift, an icon per list item. To a model, nicer means more. I learned to name the one thing and the one value.
Letting it choose components. Without the catalog, it builds a second card, a third button, a fourth kind of list. The catalog is the fix, and keeping it up to date is the discipline.
Trusting the summary. "Updated the component to use semantic tokens." It had, in four places out of six. The diff shows six. The summary shows what it meant to do.
Fixing by hand what should have been a rule. Each time I fixed a mistake in the code instead of in the rules file, the mistake came back a week later. Now a mistake becomes a rule the same day.
Skipping the browser. The build passed, the types passed, and the page was wrong. A passing build means the code is consistent, which is a different thing from right. I look at each change in the browser, in both themes, at phone width.
What changed in the job
One person holds more now. I design the thing, build a lot of it, and ship it. When the same person designs it and ships it, nothing is lost in the handoff, because there is no handoff. The design system is the running code rather than a library that drifts away from the product.
The design part did not get smaller. It became the only part that is mine. The agent does the translation, the plumbing and the chores. The brief, the first sketch, the taste and the review stay with me, and those were the parts that mattered all along.
If you are a designer and you have not opened a terminal yet, what is the one thing you are waiting on a developer for right now? That is the first thing to try.