Design-to-Code

For years, the handoff from Figma to code was where fidelity started leaking. A designer would finish a screen, engineering would build it, and by the time it shipped, the spacing had drifted, the wrong button variant got used, or a token was hardcoded instead of pulled from the system. Nobody was cutting corners on purpose. The process just had too many hand recreations in it, and every recreation is a chance to lose something.

The market shifted at the same time. Growing numbers of design role I look at now expects real fluency with AI tooling, not as a portfolio trick but as a way of actually solving problems faster. I didn't want to bolt AI onto a project just to check that box. I wanted to point it at a real problem I already had.

Getting a preview to look right isn't the hard part. Anyone can eyeball a screenshot and get close enough to pass on a glance. The real gap is semantic: whether that same-looking preview is actually built out of the design system's real tokens and real components, or a plausible-looking copy of them underneath. A surface that matches Figma but isn't wired to the system will drift the first time someone touches it, the same failure mode as a manual handoff, just faster and better disguised.

Tokopedia and TikTok Shop don't even run on the same design system. TikTok Shop is built on TUX, TikTok's own component library. Tokopedia runs on T-Nest, a separate library with its own foundational tokens, core components, and business-layer patterns. Any preview tool that ignored either library and reinvented its own version of a button or a price tag wasn't solving the problem. It was just moving where the drift happened, from the handoff to the preview itself.

The two systems didn't start from the same place, either. TUX already lived inside a broader TikTok tooling ecosystem that had been trained and refined well before I touched it, so a coding agent working on TikTok Shop already had real instincts for TUX's tokens and components. T-Nest had no equivalent. For Tokopedia, I had to do that research and training myself: pulling the library apart, writing down clear dos and don'ts, and only trusting the agent with the harder judgment calls once the easy ones were locked down.

The preview has to look exactly like Figma. That part was never in question. What's non-negotiable is what's underneath it: every layer of that surface has to trace back to something real, T-Nest for Tokopedia, TUX for TikTok Shop, an actual token, an actual component contract, an actual variant, not a hand-tuned approximation dressed up to pass a glance. Getting the surface right is the easy half. Getting the surface right on top of something cleanly tokenized, semantically correct, and as readable to engineering as the design system we've already invested in demands, that's the actual bet.

Which meant the first weeks of work couldn't be about the preview app at all, at least not on the Tokopedia side. They had to be about turning T-Nest into something a coding agent could reason about with the same confidence it already had for TUX. I used the Figma MCP to crawl T-Nest directly: foundation tokens for color and typography, the full icon set, every core component family, and the business components built on top of them, documenting all of it as structured, evidence-based reference material rather than letting an agent infer behavior from screenshots. Where the source evidence was partial, I marked it as an open gap instead of guessing, because a confidently wrong assumption baked into a design system is worse than an honest unknown.

Only once that documentation existed did I let the agent touch the Tokopedia preview. It reads off that library now, not off an approximation of what T-Nest looks like.

The pipeline is three layers.

1. 01Figma stays the source of truth for both libraries.
2. 02A documentation layer, crawled through the Figma MCP, turns each library into structured references, foundations, core components, business components, each with its own scope and its own list of unresolved items instead of pretending to be complete. T-Nest needed this built from scratch. TUX already had that maturity.
3. 03A preview renderer, a React app with its own routes for both brands, consumes real components from each library to build screens several steps closer to shippable code than a static Figma frame ever gets you.

Even on the TUX side, where the agent started from a stronger base, that discipline still had to be enforced case by case. This exchange is from the TikTok Shop preview:

Enforcing that with a coding agent meant being unusually specific about how I fed it work, on both platforms. Feedback like this had to name the actual component and variant, not just describe the pixels, so the agent could fix the token usage rather than the surface. That discipline doesn't show up in a screenshot, but it's the part of the work that actually matters.

TikTok Shop is the closer of the two to pixel-perfect right now, and that's mostly a head start, not harder effort on my part. TUX came in already trained, so the agent had real component instincts from day one. That's not to say it was flawless on the first pass, the exchanges above are proof it wasn't, but the corrections landed fast because the agent already had TUX's real vocabulary to reach for instead of guessing at one.

Tokopedia is the harder, slower half, and the more interesting one. T-Nest didn't have that same head start, so all of the rigor from the section above, the crawling, the documentation, the dos and don'ts, had to happen before the preview could even begin. Home, search, PDP, cart, and checkout now render as live previews built on real T-Nest components, with a working light, dark, and system theme switch and a table of contents to move between screens. None of it is a static export, every screen in these previews is running code, but it isn't pixel-perfect yet. It gets measurably closer with every component, semantic rule, and token I embed into the agent's understanding of T-Nest.