AI-native design workflow. Prototypes built inside the product's own codebase, so designers feel the real system early and design and development build from the same material

On startup timelines, one step is always cut first: the interactive prototype. There is no time, so design happens in static mocks.

The quiet result is that a designer never really feels the product until it is built, and two problems follow from that.

The first is timing. When a mock becomes a real screen, the density, the data shapes, the roles, and the edge cases all appear at once, in production, the most expensive place to meet them.

The second is language. A mock describes the product in one medium and the code builds it in another, so every handoff is a translation, and things get lost in translation.

In the agentic era, a designer can build real, working screens inside the product's own codebase — with its real components, not a picture of them elsewhere.

The setup matters more than the tool. Built together with engineering, designers get their own copy of an environment that mirrors the live product — kept current by developers, so it stays accurate and is safe to break. Each concept gets its own branch, where an agent (Claude Code, Cursor) builds from the product's real design tokens and components, not lookalikes. The result is not a picture of the product; made from the same parts, it looks and behaves exactly like the real thing, while staying a prototype.

Because the prototype looks and behaves exactly like the product — without being production yet — the surprises arrive at the beginning instead of the end. You click through real data, real states, and real permissions while the idea is still cheap to change. And because each concept lives in a disposable branch, a large restructuring costs an afternoon rather than a sprint, so teams stop quietly avoiding ambitious directions.

This matters most exactly where products are hardest. In complex, data-heavy systems every flow is dense and particular — its own mix of states, roles, permissions, and edge cases — and none of that can be judged honestly from a static frame.

Working in real components changes the handoff before the handoff even happens.

Design and development stop keeping two separate representations of the same thing. Both sides work from the same tokens and the same Storybook components. Some of those components already existed; others were extended during design, and those changes flow back into the shared system.

There is one source of truth, used in both directions, so handoff becomes continuation instead of translation.

A prototype shows how something looks and behaves, but engineering needs more than that to build it for real: the full set of states, edge cases, and error paths, written down.

In the agentic era the most convenient form for that is a plain Markdown file that lives alongside the code.

Once the feature is implemented, two branches describe the same thing: the design prototype and the real build. Hand both to an AI assistant along with the Markdown document, and ask it to compare them. It finds where the implementation drifted from the intended design, and where either side missed a state or an edge case the document promised.

One move covers design QA and engineering QA at once — it makes review faster and cuts down on missed cases and manual checking.

None of this removes developers from the picture. The prototype is a thinking and communication tool, not a shippable codebase; architecture, state, and the real build stay with engineering.

The goal is narrower and more honest than replacement: take the guesswork and the translation loss out of the middle, so the same team ships better work, faster.