The handoff is dead

For most of my career, design ended at a line. You did the thinking, built the screens, wrote the spec — and then you handed it across a wall to engineering and hoped what came back resembled what you drew.

At FYERS, that wall used to be inside the design team itself. We ran a relay: a UX designer picked up a requirement, handed it to a UI designer for finesse, who handed it to front-end for the build. Three handoffs, three chances to lose intent. And even after we unified those roles and built a real design system, the wall didn't fully disappear — when our engineering team turned the design system into a coded component library, we couldn't get a 100% match between the design and the code. Not because anyone did poor work, but because the gap between "designed" and "built" is real, and it has always needed a translator.

I recently stopped waiting for the translator. I designed a product called Wealth Tracker — one consolidated view of everything an investor holds, with performance over time — and then shipped it. The actual front-end, myself, working with Claude as an AI pair. Nine working days, start to finish.

That changed how I think about what a designer is.

What actually changed

The old constraint was never imagination — it was translation. I could always picture the interaction; I couldn't always produce the production code, and the moment my design left my hands, some of the intent leaked out. AI collapses that translation step. The thing I designed and the thing that ships can now be the same thing, made by the same person, because the hardest part of writing front-end — the syntax, the boilerplate, the "how do I do this in my stack" — is exactly what an AI pair is good at.

That's a judgment problem, not a syntax problem — and judgment is what senior designers already have.

My workflow

Here's how I work with Claude to go from design to shipped front-end.

• Start from the system, not a blank page. I anchor the AI in the design system first — the tokens, spacing, and component rules from FDSG — so everything it generates speaks the same language as the rest of the product. The system is the constraint that keeps AI output from drifting.
• Work in components, then compose. I build the smallest pieces first and get each one right — an order row, a price cell, a button state — then assemble screens from parts I trust, rather than asking for a whole page in one shot.
• Describe intent, not just appearance. I tell the AI what an interaction is for — "this confirms an order, so it must be impossible to trigger by accident" — not just how it should look. Intent is where design judgment lives, and it's what keeps the behaviour faithful, not just the pixels.
• Stay in the loop on the hard parts. I let the AI carry the boilerplate and syntax, and I step in by hand on the things that need taste and judgment: timing, spacing, edge cases, and the states most people forget.
• Review like a designer, test like an engineer. Every pass gets checked against the design intent and run in the browser — real states, real edge cases — before it's anywhere near done.

What it means for design teams

If one person can carry a problem from user need to shipped screen, the org chart should stop pretending those are separate jobs. This is the same conviction that led me to push for "Product Designer" as a role at FYERS instead of a split between UX and UI: fewer handoffs, less lost intent, more ownership. AI extends that logic one step further — the handoff to front-end becomes one more seam a single owner can close.

I don't think this makes engineers redundant; it makes the boundary negotiable. The interesting work — architecture, performance, the genuinely hard systems problems — still belongs to engineering. But the long tail of "design it, then wait weeks to see it built roughly right" is going away, and designers who can direct an AI to build their own work will move faster and lose less of themselves in translation.

The honest limits

I want to be clear-eyed, because the hype around this is loud.

• AI doesn't replace understanding. It amplified me because I already knew the system, the interaction, and what "correct" looked like. I asked for a confirmation step on an order action once and got a textbook modal dialog: clean, accessible, correctly built, and completely wrong. A modal is what you use when you want someone to stop and think. This was a screen for people who trade in seconds — the confirmation had to live under the thumb that was already moving. That's how the hold-to-confirm ended up in the Lab piece. The AI answered the question I typed; it couldn't know the question I meant. Point it at a problem you don't understand and it will confidently build the wrong thing — cleanly, convincingly, and wrong.
• The last mile is still craft. The output got me most of the way, but the finish — the timing of a transition, the states nobody remembers, accessibility, the pixel-level fidelity to the design — is where I spent my own hands. AI closes the distance; taste closes the gap.
• It's a pair, not a pilot. The quality of what comes out still tracks the quality of the direction going in.

Design has spent years arguing about whether designers should code. I think AI quietly ended the argument — not by making everyone an engineer, but by making the wall between designing something and shipping it low enough to step over. I stepped over it with Wealth Tracker. I don't plan to step back.