Sole product designer shipping production code with AI

I'm a product designer, the only one at Cloud-IAM, working next to an engineering team that ships fast. On the console I make the product-design calls, layout, hierarchy, wording, spacing, the way a thing behaves, and then I ship them myself in the running product, closing the gap between "here's how this screen should feel" and "here it is, live in the browser, behaving the way I meant." I've never written a line of frontend or backend code. Claude Code writes all of it. I direct, I don't draw.

Almost everything written about designing with AI starts from a blank canvas: a fresh idea, an empty repo, a clean demo. This isn't that. I joined an existing B2B SaaS whose interface had been built by developers. It worked, and there was a design system behind it, but a thin one, with real ergonomic problems. My job is to pull it toward a coherent system without breaking what people already rely on: the slower, less glamorous version of the work, one screen at a time, inside an existing codebase, in a product that's already live.

The product itself: Cloud-IAM is an identity and access management platform based on Keycloak. Keycloak is the open-source system apps use for login, sign-in, sign-up, single sign-on, and who's allowed to do what, and we host and run it so companies don't have to. The console is where our customers set it up and operate it: deployments, realms, users, security, extensions. That's the surface I design.

Working this way changed the shape of my job as much as its speed. Three things moved underneath me: design stopped being a file I hand off, the hard part stopped being the drawing, and what I'm even able to design started to depend on what sits under the screen. Then there's how I actually steer it, day to day, and the setup that lets me. Here's the whole thing.

The handoff disappeared

For most of my career, design ended at a handoff. I'd work a screen until it was right in Figma, write up the spec, and pass it to a developer who turned it into the actual product. Everything after that (the edge cases, the real data, the interactions a static mockup can't show) happened without me, and the distance between what I drew and what shipped was where the work quietly could leak away.

Now I skip the handoff. I design in the running product, and the design is the thing that ships. To make that concrete, here's one job, adding a feature from zero to production, the old way next to the new one.

Claude Code estimated this from our design workflow over the last three months: a feature that used to take two to three weeks from zero to production now ships in a few days, up to 60% faster, depending on the change. Almost none of that comes from designing faster. It comes from the meetings, handoffs, and rounds of design QA that simply stopped happening, because there's no longer a gap between my work and the build to police.

Some of it is also the fidelity of where I work. A Figma mockup carries my intent on the happy path, so a developer still has to guess at the edge cases it never showed, and when they guess differently than I pictured, we lose a round to a meeting. A proper component library narrows that gap, of course, but it still shows each piece in isolation. The whole screen only comes together in the running product, and that's where I'd rather meet the surprises, before a customer does.

Design stopped being a file I hand off. It became the product itself.

The bottleneck moved

People assume the slow part of design is the drawing. On a product like this, it never was. Cloud-IAM, a B2B SaaS, has dense features, and the people using them are technical profiles. The hard part is understanding a feature well enough to design it honestly, and for years getting that understanding meant a chain of handoffs: I'd ask a developer to explain it, mock it in Figma, come back to reshape the edge cases I'd missed, ask more questions, and only then reach something final.

Now the first move is a conversation. Understanding the technicality of a feature used to take me a few rounds of chats with the developers. Now I do it with Claude in one sitting, before I start designing, and sometimes while I'm designing. It's like having a technical person able to answer me at any point. I have it bring me up to speed on the feature and the person it's for:

can u get me the general context of this feature, what it does and what the user is trying to achieve

whats the link between the screen "upgrade" and the releases?

Then I design from real understanding instead of guessing. On a product this dense, that's the difference between a screen a technical user trusts and one they quietly work around. The bottleneck used to be communication: getting a developer to build what I meant. Now it's comprehension: understanding the feature, and the person it's for, well enough to design it. The hard part landed in the right place, because that understanding was always my job, not someone else's.

The data decides what I can design

Working inside a live product taught me something a prototype never could: what decides how I design a screen isn't how it looks, it's what sits underneath it. Every change ships as a merge request, and what I can do with one depends entirely on the data: whether it already exists, and whether I control it.

Most days the change touches nothing underneath: consistency, layout, spacing, hierarchy. That kind of cleanup lives entirely in the interface, so I take it end to end on my own: branch, change, review it live, ship. There's nothing to wait on.

Sometimes the design I want needs data the backend doesn't expose yet. There I build the screen the way it ought to work, mock the missing data, and get it in front of the team live before I walk the developers through what it needs to connect to. At that point the design is the spec: it shows exactly what to add and how it'll be used, so the backend work gets scoped against something real instead of a paragraph in a ticket.

And sometimes the data comes from a source we don't own, an outside API or feed. Then I can shape how it reads: the grouping, the order, what the screen shows when there's nothing to show or the source is slow to answer. But I won't let the UI pretend it controls numbers it can't.

Knowing which of those three I'm standing in before I start is half the job. It tells me whether I'm free to ship, speccing data that doesn't exist yet, or making sense of data I don't control.

What decides how I design isn't how the screen looks. It's what the change touches underneath.

What directing looks like

I came to design from architecture, and that background still runs underneath everything I do here. Architecture teaches you to hold a whole structure in your head while you work on one room of it, to feel how a decision in one place loads onto another. That turns out to be most of this job: holding several threads at once, mapping what a piece of work needs before it starts, keeping a few branches and merge requests moving in parallel without letting them collide.

If design is now the running product, my job is to steer it there. I'm not writing specifications; I'm reacting to what's on the screen and pushing it toward what it should be. My messages are short, lowercase, visual, and quick to change direction. A few habits show up in almost every session.

Looking, not reading

I judge the work by looking at it, never by reading the code. Almost every request ends with some version of:

ok give me in local this page and lets iterate

The loop is always the same: branch, look at the running app, react, adjust, look again. And when there's nothing to look at yet (an empty table tells you nothing about its own controls), I make it visible first:

mock me some data in the table

Claude seeds fake rows, and suddenly I can watch the sorting, the pagination, and the spacing behave before I commit to any of it.

Correcting, not specifying

My best results come out of corrections, not first drafts. When the first attempt is wrong, I name it plainly and re-specify in concrete, visual terms:

ok i see you did the side menu in medium weight. put them back. i meant the menu of the top bar

u took it too literal i think. the install button can stay where it is. the rest can change.

The live preview is what makes that cheap. It lets me change my mind, even reverse a call I made an hour earlier, once I see it standing in front of me: "ok make the top bar items as in the deployments i think it was better." And I give the feedback as a principle, not a pixel: proximity, reading order, honest labeling, restraint. Claude understands that vocabulary, so I work with it the way I'd work with another senior designer instead of narrating "move this 4px left." Naming the principle is what carries the intent, which means the fix holds across the whole screen and not just the spot I pointed at. On the release drawer I never asked anyone to move a box; I pointed out that the screen made people pick a release first and then scroll back up for the details that justified the choice, so we rebuilt it to read in the order the decision actually happens.

Keeping the call mine

I talk to Claude as a fellow designer, which means I open up the reasoning rather than just issuing orders:

so ill tell u my issues with this screen layout:...

what do u think?

That last one comes up constantly, and I mean it: it's a thinking partner, not a vending machine I drop instructions into. When I'm genuinely unsure, I don't argue it in the abstract; I have Claude build the options and hide a switch out of the way so I can compare them live:

build me 3 variants and put a toggle in absolute position somewhere so its not impacting the design

Sometimes I keep a version that's already good enough safely parked while I chase a V2 my gut prefers. And once a direction is settled, I'm decisive about clearing the rest, so nothing dead is left behind:

none of the rest is good, keep only V2

I name the principle, not the pixel. The last call stays mine.

What holds it together

None of this works because of clever prompting. It works because of context. I set the whole thing up once, and now Claude has standing access to the codebase through Claude Code (every file in the console, the conventions, the design system, and the notes I've written about how I work), so it reads and writes the code and runs the app against staging, never production. I never re-explain the project, and I've come to believe that matters far more than the wording of any single prompt: a clever prompt sitting on top of no context just gets you a confident stranger's guess.

The shape of the setup:

Around the repo, a handful of tools give Claude eyes, ears, and a surface to work on:

• A persistent live preview at http://localhost:3000, logged into staging, the page where I actually design. Every time Claude cuts a branch it hands me that link, so I can start looking right away.
• Figma, so Claude can read my UI kit (the components and tokens I keep deliberately AI-friendly) and draw back into the files; it runs in both directions.
• Mobbin, so when I want a fresh take I can point Claude at how strong products solve the same problem instead of inventing it alone at my desk.
• Slack, so it can read the team's channels and the client feedback that lands there, which feeds how I triage what's even a design problem.
• GitLab, where the work is tracked and shipped. I don't type git commands; the rules (branch from staging and never main, a strict commit format or the push is rejected) are encoded once so Claude gets them right without me ever seeing them.

When Claude drifts into developer-speak and starts to lose me, there's a mode I switch it into — a custom skill we created:

lets alexandra dev

It does one job: keep Claude talking to me like a designer. No jargon, one step at a time, told in terms of what I should see rather than what happened underneath. When something turns red, that's normal: "red is just the computer pointing at the one small thing to fix next." It's a volume knob for how technical Claude gets, and when it drifts too deep it turns the dial back down to my level.

Put together, those pieces are one loop with a clear seam down the middle: my half is design and structure, the team's half is verification and security. Every merge request I open is reviewed by an engineer before it ships to production.

What the job is now

I've started to think this is simply part of the job now, that a product designer should improve the UX of their own way of working, not just the product's. At Cloud-IAM the tech team keeps hunting for better ways to operate, and this is where we've landed as of June 2026. In a few months it might look different, or go deeper; for now, it holds up.

What surprises me is that I'm not sure I could comfortably go back to designing purely in Figma. Working this way leaves me more in control (more in the orchestrating seat than the drawing one), and it strips out a layer of overhead I'd stopped even noticing. A mockup quietly pulls your attention onto the file itself: its components, its variants, its auto-layout, when the thing that actually matters is how the product feels in someone's hands. Designing in the live version keeps me looking at that instead of at the stand-in for it.

It isn't friction-free, though. Because there's suddenly room to do more, and faster, I tried running a few things in parallel the way some of the developers do, and hit something specific to design. Two shallow tasks at once are fine, but when both need real decisions, switching between that depth while Claude is thinking on each is genuinely hard; design judgment doesn't context-switch as cleanly as code seems to. So I keep the deep work to one thread at a time, and let the parallelism happen on the lighter stuff.

I'm still not a developer, and I don't need to become one. Design became the thing that ships, and that moved me from the end of the process to the middle of it, where the calls actually get made.

Why I wrote this

Claude Code wrote the words of this article, drawn from my actual work over the last three months rather than from a brief I dictated. I hadn't opened Figma for the console in all that time, so Claude already had the context it needed: how I approach the work, how I talk, how the two of us collaborate.

But the article is mine. I prompted the idea, shaped its structure, then checked and verified it and kept simplifying the text until it read the way I wanted.

I asked for it because I couldn't find much written about this particular case: a designer shipping production code with AI inside an existing B2B SaaS, rather than someone starting from a clean slate.

So this is a case study of one: three months of real work, measured.