The prototype is the deliverable in the AI era

For a long time, "design deliverable" quietly meant pictures of the product.

Figma is incredible at clarity, speed, and shared language. But pictures have a ceiling. They're static. They pretend inputs and outputs are neat. They can't carry the full truth of what software actually is: stateful, conditional, messy, alive.

Then AI changed what shipping looks like. And it changed what alignment looks like too.

Jenny Wen at Anthropic shared something that stuck with me: designers are rebounding each other's prototypes until everyone feels aligned on the product.

Not rebounding frames. Prototypes.

That single shift is bigger than it sounds. It's not a tooling preference. It's a statement about where truth lives.

Fidelity isn't "more pixels." It's "more reality."

There's a difference between a mock that looks real and an experience that behaves real.

A high-fidelity prototype in the AI era isn't a polished screenshot. It's something closer to the actual mechanics of the product: loading states, empty states, errors, latency, partial responses, the weird edge case that only shows up when a human tries to break it.

If you're designing ChatGPT-style or Claude-style software, you already know the problem. The UI isn't a layout problem. It's a conversation problem. User input and model output are hyper contextual and non-deterministic. Figma can hint at that. It can't simulate it faithfully.

So the prototype stops being a presentation artifact. It becomes the shared object everyone argues with productively.

The handoff problem, reframed

The old handoff fantasy was: designer writes the spec, engineering implements the spec, QA verifies the spec.

The modern failure mode is different. The spec explodes. The nuance lives in interaction. The truth is distributed across tools and Slack threads.

Here's the optimistic version of the new story: if the prototype is code, the spec is already inside it.

Not every annotation. Not every pixel label. But the important stuff: structure, states, real copy paths, real components, real constraints.

And if your team is using coding agents well, the handoff isn't a package of documents. It's a codebase that already runs. Engineering's job becomes extension and hardening, not translation from picture to program.

That's not automatic magic. It's a discipline. But it's a different discipline than "export redlines."

Related: Agent skills for designers.

Design systems should live where the product lives

If you want speed in the AI era, your design system has to stop being a museum in Figma and start being something the product can import.

Design systems in code mean prototypes built on the same foundation as production can inherit updates automatically. When tokens or components change, prototypes don't lag by a quarter. They move with the system.

That's how you get leverage: not more design files, but fewer mismatches between what design means and what users touch.

This doesn't mean Figma disappears. It means Figma's job shifts. It's for exploration and communication, not the single source of truth for how the product behaves.

Prototypes in code can do what code can do (and that's the point)

When the prototype is code, you stop designing imaginary versions of dynamic behavior and start designing with the same materials as reality.

Examples aren't gimmicks. They're arguments:

A credit card scanner flow can use a real OCR library in the prototype, not a fake success screen every time.
A translator concept can run live translation in-browser or via an API, so you feel latency, failure, and delight.
You can use real device capabilities: camera, microphone, haptics, location, whatever your product actually depends on.

Suddenly you're not selling a narrative in a deck. You're testing a truth in your hand.

Yes, prototypes can become too real too early. Yes, you can overbuild. The antidote isn't going back to static mocks for everything. It's choosing the right fidelity for the decision you're trying to make.

How to start without boiling the ocean

You don't need permission to become an engineer. You need a workflow that lets you touch code without turning your life into build tooling.

Practical starting points people actually use:

Cursor (and similar editors) for editing a repo like a product surface: fast iteration, inline help, refactors without ceremony.
Claude Code and agent-style workflows for "make this component behave like X" and "wire this flow end-to-end."
A tiny repo that is yours: a sandbox app, a branch, a design-system playground.

The goal isn't "designer becomes SWE." The goal is designer becomes unblockable: able to produce a running artifact that teams can align around.

For more on the mindset and prompts, see moving from Figma toward code, AI-native design systems, and prompting rules you can reuse every day.

The uncomfortable truth (and why it's still worth it)

Pictures are fast. Code is slower at first.

But alignment is expensive. Rework is expensive. Building the wrong thing beautifully is expensive.

If teams are really rebounding prototypes until alignment lands, that's not a fad. That's a return to a simpler idea: truth beats representation.

The prototype isn't a step on the way to the work.

In the AI era, it might be the work.

Also published on Substack

Read or discuss on Substack →