The Design-Code Roundtrip That Isn't — Jonathan Gordon, ReWeaver AI

Jonathan Gordon, founder of ReWeaver AI, opens with a small piece of AI-assisted improvisation: after display mirroring hid his speaker notes, Claude extracted them from the slide deck. Whether it extracted them correctly was another question. That uncertainty neatly previews the larger problem: a generated result can look useful without proving that it faithfully preserves its source.

A genuine design–code roundtrip has three requirements. It must move in both directions, preserve fidelity, and carry persistent provenance. If a button appears on a design canvas, the system should know which code produced it; if someone changes that button in the design, the corresponding code should change without losing bindings, behavior, tokens, or other meaning.

That standard is higher than generating a clickable mockup or visually similar component. Design and engineering have historically optimized for different outcomes: design carries product intent, branding, and a vision of what the customer should experience, while engineering must satisfy technical requirements and constraints. Gordon’s more than 30 years building developer tools and working across that handoff never produced a perfectly closed loop. Negotiation could get software shipped, but it could not guarantee that intent and implementation remained identical.

Large language models appeared to remove that organizational split. One model could interpret design intent and write code, suggesting that the loop might finally close “at the speed of inference.” The important question, however, was not whether a model could create both artifacts. It was whether repeated movement between them remained lossless.

Gordon tested that possibility by going all in on vibe coding beginning in April 2025. Cursor told him he was in its top 0.1% of usage—an achievement that prompted the conclusion, “I need to spend more time outside.” Underneath the joke was a sustained experiment: move from design to code, move back from code to design, and see whether the pixel-perfect result survives.

The turning point came while generated code streamed past faster than he was reading it. The token innerHTML caught his eye. Because writing untrusted content through that API can create an injection risk, he stopped the agent, asked what it had done, and ordered a revert. The observable change in his workflow mattered more than the individual correction: the code stopped being background output and became an artifact requiring inspection and steering.

Once he began reading again, more issues appeared. The same skepticism then applied to public demonstrations of code-to-canvas workflows. Creating a Figma artboard from a Claude Code prompt looked magical, but successful generation in one direction did not establish a roundtrip. The test had to include the return journey and inspect what disappeared along the way.

The demonstration harness puts AI-generated code on the left and a design canvas on the right. Either side can serve as the starting point, and an LLM-mediated prompt performs the transformation. In the example, a form becomes a design system represented in both a running application and Figma.

A design system supplies the shared vocabulary: components, tokens, variables, and styles become the basis for constructing software. The example then changes visibly. A company field and an orange button appear, and both the code and design update. That is enough to demonstrate synchronized generation. It still does not prove that the relationship can survive another trip backward.

The Show Drift action changes the question from “Did both sides update?” to “Where do they now disagree or fall short?” ReWeaver scans the code and design together and groups findings across dimensions including design quality, code quality, performance, and design tokens. This treats the rendered result and its implementation as two representations to reconcile, rather than trusting either one as complete.

Accessibility provides the concrete failure. The scan finds a dynamic element without an ARIA live region, which means a screen reader will not announce its update to a blind user. ReWeaver offers a fix; after it is applied, the red issue disappears while another blue issue remains. The sequence is inspectable: generation produces an apparently working interface, the scanner detects an omitted accessibility behavior, the user authorizes a correction, and the finding changes state without pretending every other issue is solved.

What relationship does this make visible? The diagram shows why a visual match alone cannot close the loop: both representations must feed a common reconciliation step, and a human must decide what happens to each finding.

Testing five bidirectional tool setups did not produce a complete code–design–code roundtrip. The failures were lossy in different ways: bindings disappeared, or a change survived in the design while the corresponding code did not. These outcomes leave open the possibility that future tools will improve, but they show why a successful one-way demo cannot establish persistent fidelity.

The proposed remedy comes from conventional developer tooling. Compilers, parsers, and abstract syntax trees provide repeatable structure: the same input can be checked against the same rules. Put a probabilistic model before, inside, or after that process and identical outcomes are no longer guaranteed. Deterministic guardrails therefore surround rather than replace AI, checking its artifacts for known mismatches after generation.

Three kinds of drift emerge from this model:

• Representation drift: code and design no longer describe the same component, token, binding, or state.
• Production drift: generated code works nominally but omits qualities such as accessibility, performance, or governance.
• Temporal drift: small unobserved changes accumulate over repeated iterations until the codebase carries a new form of technical debt.

A separate experiment ran 12 iterations over a codebase with a sufficiently complex interface, comparing pure model-led output with output checked and corrected through deterministic guardrails. Gordon reports that pure model output began around 30% fidelity and degraded, while guarded iterations held up better; he also reserves the final stretch for human judgment. The talk does not define the fidelity calculation, show the underlying series, or explain how the stated percentages relate, so it supports the direction of the reported result rather than a measurable effect size.

This changes the unit of concern. Drift in one generation is a review finding. Drift over six months becomes accumulated maintenance work—“the new tech debt.” The danger is not merely that one model response varies, but that variation keeps entering a codebase faster than people notice and reconcile it.

The target system is fully bidirectional and lossless: edits travel both ways, all relevant surfaces remain intact, and provenance identifies where each element came from. If a button in Figma originated from a particular line of code, changing the button should preserve that relationship rather than silently creating two independent artifacts.

Deterministic reconciliation then follows an accept-or-refuse rule. When the system knows a valid correction, it can propose that fix. When it knows only that something is wrong, it should report the issue and leave the resolution to a person. Refusal is valuable because uncertainty remains explicit instead of being converted into another plausible approximation.

ReWeaver is described as using a fully local LLM at its core, with optional connections to external models, and as adding no extra token cost in its default configuration. More important than model placement is the control model: the person retains authority over cost, code, and design. Generated changes remain visible, reversible, and ignorable.

That is a stronger role than being summoned only when an agent encounters trouble. “Human in the loop” can still leave the agent directing the process. “Human in control” makes automation subordinate to explicit decisions about what should change and what should ship. Gordon jokingly names the desired result “winny wig”: what you need is what you get.

ReWeaver organizes its checks into nine top-level dimensions of software quality and production readiness. The talk names three in detail. Design consistency checks whether a codebase and its design system still agree. Accessibility gets its own dimension rather than being folded into generic code quality. AI code governance records and controls generated changes as code moves quickly through the system.

The product’s authority remains deliberately bounded. ReWeaver does not independently decide to rewrite the repository. When a user selects Apply the fix, it writes the proposed change visibly; the user can undo it, ignore it, or leave the finding unresolved. The goal is a closed loop that catches drift before merge without turning detection into unreviewed autonomy.

The public playground accepts AI-generated code and returns scan results. Gordon also describes a challenge based on PDR, or production drift ratio, with beta access offered for code scoring below 0.30. The recording does not explain the formula for PDR, so the score is best treated as a product-specific diagnostic rather than a general code-quality metric.

The durable lesson is not that AI should leave the workflow. Generation stays. What changes is the surrounding discipline: inspect both design and code, preserve provenance, use deterministic checks for properties that can be checked, refuse uncertain automatic repairs, and keep the person who owns the product in control of the final change.