The Moment Everything Shifted

A quiet Tuesday afternoon, a wine industry dashboard, and the realization that I could design and build in the same breath. Not a mockup — working code, shaped by conversation, at the speed of thought.

I need to tell you about a moment. Not a dramatic one. No angels singing, no slow-motion montage. Just a quiet Tuesday afternoon where I realized the rules had changed.

I was working on a client project — a dashboard for a wine industry platform. I had the design in my head. Not fully baked, but the shape of it. The data hierarchy, the visual weight, the interaction pattern. I could already see the grid structure — CSS Grid with named template areas, a sticky sidebar, the main content area handling overflow independently. Normally, this is where I'd open Sketch, spend a few hours building comps, then start recreating the design with code templates, custom fields, in one aspect, and from another, pass my designs to a senior developer who will then interpret the design as they see fit. All within a span of maybe two weeks.

Instead, I described what I wanted. And watched it take shape in front of me.

Not a mockup. Not a wireframe. Working code. A functional frontend that I could see, interact with, and refine — in the same session.

That was the first time I used Claude Code for real production work. And the feeling wasn't only excitement and wonder, but relief, or a sense of certainty around what is now possible. Claude Code is my new best friend.

Why This Was Different

Let me back up.

I'd been hearing about AI coding tools for a while. Copilot, ChatGPT, various autocomplete plugins. I tried some of them. They were fine for boilerplate — generating a component skeleton, scaffolding a basic layout. But they didn't think about design. They produced code the way a junior developer produces code: technically functional, visually generic. Flexbox with justify-content: center on everything. Default spacing. No rhythm, no system. The output had no opinion. No craft. It was the code equivalent of a Canva template — sure, it works, but you can feel the absence of intent.

So I mostly ignored them. I'm not a designer who needs someone to write my CSS. I've been writing CSS since before flexbox existed — since we were using floats for layout and clearing them with empty divs and calling it engineering. I've shipped production frontends, debugged layout issues across browsers, and refactored component architectures. I understand the medium I design for — not theoretically, but practically. What I needed wasn't a code generator. I needed something that could keep up with the pace of my thinking across both domains simultaneously.

Claude Code was different, and it took me a few sessions to understand why.

The difference wasn't speed, though speed was part of it. The difference was that I could operate in both languages — design and code — without switching contexts. I wasn't toggling between "what should this be" and "how do I implement this." I was doing both in a single conversation, at whatever level of abstraction the moment required.

Here's what I mean. I might start with design intent: "The content area needs a clear visual hierarchy — the primary metric should dominate, with supporting data receding." And in the same breath, drop into specifics: "Use a CSS custom property for the spacing scale, base it on 8px, and make sure the metric component uses clamp() for fluid typography between 48px and 72px."

That fluency — moving between concept and implementation without friction — is something I've always had in my head. But even when I filled both roles in my solo practice, the workflow forced me to split it into sequential phases: design exploration in Sketch first, then code translation after. Two separate sessions, two separate mindsets. The old workflow — whether handing off to someone else or handing off to yourself — forced that thinking into two separate artifacts: a design file that spoke in visual terms and a codebase that tried to honor them. Neither captured the full picture. Now the full picture lives in a single conversation.

What Changed and What Didn't

I want to be precise about what changed and what didn't.

What changed is the time between idea and artifact. What used to take days now takes hours. What used to take hours now takes minutes. I'm not exaggerating. A complete, responsive, interactive frontend view that would have been two days of solo dev work or a week of handoff-and-iterate — I can have a working version in a single focused session.

What didn't change is the thinking. The hard part of product design was never pushing pixels or writing CSS — and I say that as someone who genuinely enjoys writing CSS. (Yes, we exist. No, I will not apologize.) It was understanding the problem, mapping the user's mental model, making hundreds of small decisions about hierarchy and flow and affordance. That work is still mine. AI didn't replace it. AI made it matter more, because now every one of those decisions actually ships without being filtered through someone else's interpretation.

That's the part that surprised me. I expected AI to make building faster. I didn't expect it to make my design and development knowledge more valuable in combination. When you can express intent in design language and correct implementation in code language — when you can say "this feels too heavy" and also "drop the box-shadow spread to 1px and cut the opacity to 0.08" — the quality of the output reflects the full depth of what you know. There's nothing in between to dull it.

The first few projects were experiments. Small things. A landing page here, a component there. I was testing the edges, learning how to communicate in a way that produced the right output. It's a skill — not coding, not designing, but the ability to direct implementation through conversation at whatever level of specificity the situation demands. Sometimes that's conceptual. Sometimes it's "the border-radius on the inner card should be 4px less than the outer container to maintain consistent inset." (Looking at you, Apple. iOS 26 said border-radius relationships are optional now, apparently.)

I got faster at it quickly. Twenty-five years of design vocabulary combined with deep frontend knowledge turns out to be an exceptional foundation. When I say "the visual weight needs to shift left" or "convert this to a grid with auto-fill and a minmax of 280px," both carry equal precision. One describes intent. The other describes implementation. Being able to use either — or both — in the same breath is the advantage.

The projects got bigger. Full-scale AI products where I'm the lead designer. Client dashboards for my solo practice. Full application interfaces for enterprise teams. AI-based products with complex interaction patterns. Each one reinforced the same truth: the bottleneck had moved. It wasn't execution anymore. It was ideation. How many good ideas can I have? How fast can I shape them? Because for the first time in my career — whether I was working on a product at scale or a solo client engagement — the answer to "can I build this?" was almost always yes.

That unlocked something I hadn't felt in a long time.

The Constraint You Don't Notice

There's a thing that happens to experienced designers who also code. You stop proposing certain ideas because you know exactly how much work they are. Not abstractly — specifically. You can estimate the implementation cost in your head because you've built things like it before. "That interaction would be great, but it's three sprints of dev work." "That layout is ideal, but the CSS for that responsive behavior is a full day by itself." "I could design something better, but I know what the grid-template-areas declaration looks like for this and it's not worth the complexity."

You don't notice it happening. It accumulates over years, like silt in a river. Your creative range narrows — not because you lost the ability to think bigger, but because you know too precisely what bigger costs. Experienced designer-developers often mistake this for maturity. It's not. It's learned constraint built on accurate estimation.

When the execution bottleneck disappears, those constraints dissolve. The estimation still happens — you still know what things cost to build — but the cost dropped by an order of magnitude. Ideas that were a week are now an afternoon. The creative aperture widens because the math changed.

I started having more ideas. Not incrementally more. Dramatically more. Because my brain stopped running the background process of "but this would require a custom hook and a context provider and three days of state management" and freed up that energy for the work it's actually best at. Imagining things. Shaping experiences. Solving problems with design.

That's what this shift gave me back. Not just speed. Range.

This is Part 2 of a series on moving from a traditional design workflow to a code-first approach. Next up: what the day-to-day actually looks like now — and how the conversation between designer and AI replaces the handoff entirely.