For about a year, the most interesting problem I owned as Head of Design wasn’t a screen. It was a line. Where does prototyping end and delivery begin, now that AI lets a designer build something real in an afternoon? Get that line wrong and you don’t ship faster. You just generate more to throw away.
That sounds like a tooling problem. It wasn’t. The tools were the easy part. The hard part was getting designers, engineers, and product leaders to agree on how the new speed should be spent.
Speed without a system is just faster drift
When vibe coding became the trend of the year, the instinct across a lot of teams was to celebrate the acceleration and worry about the consequences later. Designers could suddenly turn an idea into something clickable in an afternoon. Product people could skip the “imagine this, but interactive” conversation entirely.
The risk was never that the AI couldn’t produce something that worked. It almost always could. The risk was that *what worked in a prototype bore no relationship to what we’d actually ship.* Buttons that were close to our components but not actually them. Spacing and color values that looked right and weren’t ours. A prototype that demoed beautifully and then cost three days of cleanup the moment an engineer opened it and found none of it mapped to the real codebase.
In a B2B SaaS environment moving at sprint pace, that drift compounds fast. You don’t get faster. You get faster at creating rework.
The pipeline that held up: Figma MCP to Bolt to Cursor, with the design system fed in as context at every stage rather than bolted on at the end. The dashed wall marks where prototyping stops and production begins; engineers cross it deliberately, taking only what’s worth keeping.
The bridge we built
The workflow that finally held up was a chain, not a single tool: Figma MCP as the source of truth, Bolt for prototyping, Cursor for refinement, with the design system carried through the whole pipe as context rather than as an afterthought.
Concretely, that meant the prototype didn’t start from a blank canvas. Figma MCP fed the model the real design tokens, the actual component names, and their variant structures, so a “primary button” in the prototype was our primary button, not a plausible lookalike the model invented. That one move is the whole game. It pushes the consistency problem upstream, where it costs a configuration step, instead of downstream, where it costs an engineer’s afternoon.
This is exactly where my thinking converged with Marcel Kalveram, a former colleague who wrote about the same shift from the engineering side. In his piece Vibe Coding: Blessing or Curse?, he lands on context engineering as the biggest lever. Give the model your stack, your conventions, and your component library up front, and you change the ratio of reusable to throwaway code in your favor. I’d been arriving at the same conclusion from the design seat.
That’s the quiet thesis of the whole effort. The design system isn’t a library you reference at the end. It’s the context you feed the machine at the start.
Same three components, two different starting points. Without the design system as context, the AI produces convincing lookalikes that don’t map to production and cost days to rebuild. Fed the real tokens and component names up front, the prototype maps cleanly and the rework disappears.
The real unlock was organizational
Here’s the part the tool tutorials leave out. The pipeline didn’t work because we found the right combination of products. It worked because a group of people agreed on where prototyping ends and delivery begins.
That agreement ran across senior product designers, senior product developers, a VP of Product, a CTO, and a Principal Architect who stayed close to the work. Leading it meant less time evangelizing tools and more time negotiating a boundary, the kind where designers got a genuinely isolated playground to build in and put in front of clients, and engineers could cherry-pick the parts worth keeping and integrate them deliberately, on their own terms.
Marcel describes the same wall from his side: a clean separation between the prototyping environment and the production codebase. We built it from both sides at once, which is the only way that kind of wall actually holds. A boundary one discipline imposes on another gets resented and routed around. A boundary both disciplines design together gets defended.
That’s also what kept this from being yet another “AI experiment” that fizzles after the demo. The point wasn’t to prove vibe coding could work. It was to define a process repeatable enough that it kept working after the novelty wore off.
Where the reclaimed time actually went. The win wasn’t doing the same work faster, it was shifting roughly three days of each sprint out of prototyping and rework and into testing ideas with real clients. Figures are directional, not audited.
What we got back
The payoff showed up as time. Roughly 2,000 hours a year reclaimed across the design and handover process. In practical terms, that’s about three days of a two-week sprint handed back to each designer, plus the engineering hours that used to disappear into reconstructing prototypes from scratch.
I’d treat that number as directional rather than audited, but the shape of it is real and it’s the part that matters. The reclaimed time didn’t vanish into doing more of the same faster. It went back into the work that actually de-risks a product: putting real prototypes in front of real clients, earlier and more often, and killing the weak ideas before they reached a backlog. We found out which bets were wrong while being wrong was still cheap.
Human + AI, not AI instead of human
The version of this story that gets told too often is “AI made us faster.” The more honest version is that AI made us faster only after we decided what to do with the speed. Left alone, the tools optimized for an impressive prototype. The process we built optimized for a validated decision and a clean handoff, two things the tools don’t care about on their own.
That’s the distinction I keep coming back to. AI is a remarkable instrument. But an instrument doesn’t decide where prototyping should end, or which hypothesis is worth a client’s time, or where the design system’s integrity is non-negotiable. People do. The wins came from the seam between the two: designers, engineers, and product leaders deciding together how the speed should be spent.
AI as instrument is useful. Human + AI, with a process holding the two together, is where the real leverage lives.
With thanks to Marcel Kalveram, whose engineering-side write-up of this same shift is the natural companion to this one.
LET'S BUILD WHAT'S NEXT
Collaborate on forward-thinking work shaped by branding, data, craft and technology.
