The Design-Coder, One Year Later

A year ago I wrote that designers who code were about to take the lead. I believed it then. I’ve lived it since, and I was more right than I knew — though not for the reasons I expected.

When I wrote that first piece, I was excited about the tools. Bolt.new, Cursor, the idea that one person could carry a product from sketch to ship. That part came true. But the tools I named have already been replaced in my own workflow, and the ones replacing them will be replaced too. The tools were never the story.

The story is what happens to the person holding them.

I’ve had a rare vantage point on this. Over the last year I didn’t only build with these systems every day — I was contracted by one of the country’s top AI companies to help train their large language models, writing the golden prompt formulas and grading model output against golden responses. I’ve worked with these systems since they first opened to the public, and I’ve evolved with them the whole way, from the inside and the outside at once. That combination changed how I think about this work. It’s why I’m writing the follow-up.

It starts before Figma — with the real problem

Before any of the tools come out, there’s the part no model can do for you: understanding the actual problem.

Not the newest hype. Not the cool visual that’s making the rounds this month. The real problem — the one that exists whether or not there’s an AI trend to hang it on. Who is this for? What do they actually need, as opposed to what’s fashionable to build? Where’s the ROI, and does the thing we’re about to make earn its cost? What does success look like in numbers, not vibes?

AI can’t answer any of that. It comes from listening to clients, watching users, and being honest about what’s worth building. Skip it, and you’ll use the fastest tools in the world to ship the wrong thing beautifully. Every hour of speed AI gives me downstream is only worth something because I spent the time upstream making sure I was solving a problem someone actually has.

It all goes hand in hand. The clarity you earn before Figma is what makes everything after Figma move.

What a project actually looks like now

Once I know what I’m actually solving, the design work starts in Figma. That’s where I think — user flows, the design system, the visual language, the decisions that have to be made before a single line of code is worth writing. Figma didn’t shrink in my process. It grew, because everything downstream depends on the clarity I build there.

From Figma, Claude Code became my build partner. Depending on the job, that work ships into Framer, into WordPress, or into a hand-coded React project. When a piece needs editorial imagery, I write the prompts for it in Midjourney. When a client needs video, I generate it with Higsfield. Some projects call for wiring the model into the systems I’m working in through MCPs; most days I just work in the harness and move.

Five separate workflows became one connected system. And the honest result: on most projects, I’ve cut design and development time in half.

Not because the tools are magic. Because I know what to ask for, and I know what “done” looks like before I ask.

What training the models taught me about using them

Here’s the lesson that surprised me most, and it runs against the grain of nearly every prompt-engineering article you’ll read.

The people getting the most out of AI are not the ones writing the cleverest prompts. They’re the ones bringing the most context to the conversation.

When I write a prompt for Claude Code, I’m not saying “build me a nice homepage.” I’m giving it the problem, the user, the design system it has to obey, the accessibility rules, the responsive behavior, the implementation details, and where the interface has to go three versions from now. That’s not a magic phrase. That’s a brief — the same brief I’d hand a developer sitting across from me.

The prompt isn’t where the thinking happens. It’s where the thinking gets communicated. And you can’t communicate thinking you never did.

So yes: learn to craft a good prompt. Learn to build your agents. Learn to integrate AI into the systems you already work in. But understand what those skills actually rest on. They rest on knowing the craft well enough to say what you want in terms the machine can execute — how a thing should look, how it should feel, how it should work, and how it will scale when there are ten thousand users instead of ten. AI will happily give you the first three and quietly ignore the fourth. That’s your job.

Your design system is the language you and the AI both speak

The single most useful thing I’ve done for my AI workflow had nothing to do with AI.

It was building better design systems.

Without structure, AI drifts. It invents small inconsistencies. It adds variation nobody asked for. It wears down the coherence of a product one component at a time, and it does it fast. Give it a mature system, though, and the opposite happens. Components hold. Spacing obeys the rules. Type scales the way it should. Accessibility survives because it was built into the foundation instead of bolted on at the end.

A design system used to be documentation for designers and developers. Now it’s the framework that lets a human and a machine build the same product without pulling it apart. Integrating AI into your workflow isn’t a matter of picking a tool. It’s a matter of building the structure that makes the tool trustworthy. The stronger your system, the more you can safely hand off — and the more of the boring work disappears.

The unicorn was never a myth. Now it’s the job.

People used to call designers who code unicorns, as if the skill set were rare and mythical. I always thought that framing sold it short. It isn’t mythical. It’s just demanding — the T-shaped person with real depth in one thing and working literacy across the rest.

What’s changed is that this shape is no longer a nice-to-have. It’s the thing that lets you harness AI to do not just the design, but the development too.

Think about what that combination unlocks. A designer who understands HTML, CSS, responsive layout, semantic markup, accessibility, and component-based thinking can point an AI code tool at a real outcome instead of a vague hope. They can read what it produces and know whether it’s right. They can catch the accessibility failure, the layout that breaks at the wrong breakpoint, the component that violates the system. They aren’t asking the machine to guess. They’re giving direction grounded in experience, and then they’re checking the work.

The designer who can’t read the code can only ask and hope. The developer who can’t think about users can only build what they’re told. The person who can do both is the one who drives the whole thing — and right now that person is doing the work of a small team.

The two roles are going to collide

For years we’ve kept product designers and front-end developers in separate lanes. That made sense when every screen had to be carried by hand from a design file into production code. Someone designed it, someone else built it, and the handoff between them was a whole discipline of its own.

That handoff is dissolving. AI scaffolds interfaces, generates components, and accelerates implementation in ways that simply weren’t possible a few years ago. The manual translation that justified two separate roles is being automated out of existence.

I’ll say the uncomfortable part plainly, because I said it a year ago and it’s only more true now: this hits junior front-end work first. The tasks that used to be an entry point — implementing basic UI, tweaking layouts, fixing CSS bugs — are increasingly handled earlier in the process, by a designer with an AI code tool. That doesn’t mean junior developers aren’t needed. It means the bar moved. The ones who stand out will understand how design works, how users think, and how products get planned from the first day.

Where this leads is one role, not two. The designer and the front-end developer are going to merge into a single person who does both — and that person will be expected to know more, will be paid more, and will have to spend more of their life keeping their skills current, because the tools underneath them won’t stop moving. More expertise. More pay. More upkeep. That’s the trade. It’s a good one if you’re willing to keep learning, and a hard one if you’re hoping the ground will hold still. It won’t.

What to do about it

If you’re a designer who’s been curious about code, this is the moment to stop being curious and start being competent. You don’t need to master every language. Build a side project. Break something. Learn enough to read what an AI writes for you and know whether it’s any good.

If you’re a developer, move toward design. Learn to read a design system, to think about product goals, to sit in the ambiguity before the requirements are clear. Your understanding of the machine is worth more when it’s paired with an understanding of the person using it.

And if you already do both — this is your era. The industry spent years treating your skill set as a novelty. It’s about to treat it as the standard.

Underneath all of it, invest in the thing no tool can hand you: systems thinking. Learn how products scale. Learn how design systems evolve. Learn how an engineering choice shows up in a user’s hands. Learn how the business shapes the design. The people who thrive won’t be the ones chasing every model release. They’ll be the ones who see how the pieces connect — because that’s the part AI can’t do for you.

Keep your hands on the wheel

One line has stuck with me all year. AI can’t drive the bus. You have to drive it, and you have to keep it between the lines.

I believe that more now than I did twelve months ago. AI has made me faster. It prototypes with me, builds with me, and takes the repetition off my plate. I wouldn’t give it up. But it hasn’t taken the responsibility that comes with building products for real people. It hasn’t taken the curiosity, the empathy, or the experience. Those still decide whether a product lives or dies.

A year ago I said the designers who can build were stepping into leadership. I’ll go further now. The design-coder and the front-end developer are becoming the same person, and that person is worth more than either role ever was alone.

We’re not waiting to be invited into the room anymore.

We’re building it.