← All speakers

Bio, Work & Ideas

Jonathan Gordon

Conference affiliation: ReWeaver AI

On this page

Jonathan Gordon is the founder and chief executive of ReWeaver AI, where he develops tools to detect and repair divergence between software and its intended design. A programmer turned user-experience designer, he brings decades of work on developer tools to a problem AI-assisted coding can compound: functioning software can still depart from its creators’ intent, and repeated generation can make those departures harder to track.

Gordon’s move into design began when he watched people use software he had built. They could not find a feature he had spent months developing. That experience shaped his argument for understanding users before accelerating development: producing software faster does little good if the team misunderstands what people need or how they will use it.

From developer tools to design–code reconciliation

He worked as a senior user-interface designer at Oracle from 1996 to 1998 and as a user-interface program manager at Microsoft from 1998 to 2003. On Visual Studio .NET, he helped design the core interface and common user model, collaborating across product teams to make an extensible development environment coherent. He also drove accessibility work across the developer-tools division, using standards, usability testing, and interactive prototypes to guide implementation.

Gordon subsequently held user-experience architecture roles at Attachmate, SAP, and Informatica, followed by work at AT&T, Ivy Softworks, and Philips. At Facebook in 2018–2019, he designed internal products for employee mobility, career planning, and mentorship. From 2019 to 2024, he was a staff UX design manager at Google, working on BigQuery; in 2024–2025, he designed internal software-engineering tools at Apple. In May 2025, he began developing AI-augmented professional tools through GoJonGo Labs. These roles brought him repeatedly into the space between what people needed from software and what engineering teams implemented.

At BigQuery, Gordon led design work for data analysts, data engineers, and data scientists. He evaluated usability and accessibility, audited interface components, and worked with the design-system team to address gaps. Customer feedback informed priorities, while prototypes and design sprints helped teams explore what to build. Component patterns and measurable experience criteria connected those decisions to the implemented product—the same relationship between intent and outcome that later became central to ReWeaver.

AI initially seemed to Gordon like a way to close the longstanding gap between design and engineering. If a model could understand design intent and write code, perhaps it could reconcile work that teams had struggled to coordinate through handoffs. He immersed himself in AI-assisted coding beginning in April 2025. During those experiments, he noticed an innerHTML operation he considered unsafe, stopped the assistant, and required a different implementation. The experience prompted him to inspect generated code more closely instead of judging it solely by the interface it produced.

What faithful software requires

  • Persistent provenance. Gordon defines a genuine design–code roundtrip as editing in both directions without losing fidelity or the connection between a design element and the code that implements it. A button on a Figma canvas should remain traceable to its implementation when either side changes. Across five tool setups, he reported lost bindings and changes preserved in one representation but lost in the other. Those experiments explain his skepticism toward claims that the roundtrip has been solved; they do not establish that every workflow fails.
  • Deterministic reconciliation. Gordon’s proposed response connects detection to controlled repair. ReWeaver’s resolution mechanism allows corrections to update either the code or the Figma file itself, depending on which side should change. It uses exact-match-or-refuse behavior: a correction proceeds when its expected target matches, and otherwise is refused. Decisions are recorded in git, preserving a history of how disagreements were resolved. This makes reconciliation an operation on the underlying software and design, with a record of the decision, rather than merely a list of findings. Gordon also distinguishes this work from guidance that helps a generator select plausible components: component selection alone does not establish that an existing implementation remains aligned with its design system.
  • Accessibility is part of fidelity. Drawing on his Microsoft experience, Gordon objects to treating an interface’s visual appearance as sufficient evidence of quality. In his ReWeaver demonstration, the tool detected a missing ARIA live region: an interface update would not be announced to a screen-reader user. He then applied a correction. The example shows how software can appear correct to a sighted reviewer while failing to communicate essential information to someone else. Accessibility is a distinct dimension of the checks he is building, alongside design consistency and other aspects of production readiness.
  • Human control. People should be able to inspect findings, choose whether to apply a fix, undo a change, or leave an issue unresolved. Gordon treats human judgment as necessary even when automated checks improve alignment: detecting a mismatch does not settle whether a proposed change is right for the product. His approach gives people control over the resolution as well as visibility into the problem.

Gordon’s writing on drift extends the problem beyond visual mismatch to behavior, architecture, naming, and system-wide context. A function can pass tests while departing from its intended business rule; an agent’s locally reasonable change can conflict with assumptions elsewhere in a repository. He treats this accumulating divergence as a maintenance problem that execution checks alone may miss. The concern is especially relevant when AI makes changes quickly enough that teams struggle to inspect the relationships those changes disturb.

ReWeaver’s workflow brings rule-based checks into VS Code, Figma, and GitHub. Its Production Drift Ratio incorporates severity and estimated remediation effort to help teams prioritize findings. The aim is to catch divergence before changes merge, then let people decide how code and design should be brought back into agreement.

Gordon calls this ongoing work reweaving: maintaining agreement between code and evolving design and engineering standards. His aim is to retain the speed of AI-assisted development while giving teams concrete ways to inspect divergence, repair either representation, and preserve the decisions that shape the software.

1 conference talk

Key ideas

Scroll to read ↓

Jonathan Gordon tests the promise of lossless movement between design and code, finds drift across five tool setups, and proposes deterministic reconciliation that keeps AI generation inside human-controlled guardrails.

  • A true design–code roundtrip must be bidirectional, lossless, and provenance-preserving; generating similar artifacts on both sides is insufficient.
    1:12 ↗
  • The innerHTML incident shows why fast code generation still requires inspection: plausible output can conceal security or production-readiness problems.
    4:58 ↗
  • Scanning design and code together can expose omissions that visual comparison misses, such as a dynamic element without an ARIA live region.
    9:27 ↗
  • Five tested tool setups lost bindings or failed to carry changes into both representations, demonstrating that one-way generation is not yet a lossless roundtrip.
    11:16 ↗
  • Deterministic guardrails should surround probabilistic generation: apply known fixes, report uncertain findings, and preserve human authority over code, design, and cost.
    12:16 ↗
  • Unwatched drift compounds over time into maintenance work—the “new tech debt”—so reconciliation must happen continuously and before merge.
    14:16 ↗

References