DEV Community: Jonathan Gordon

Why using AI to catch AI drift is the wrong thing to do

Jonathan Gordon — Fri, 10 Jul 2026 20:00:58 +0000

Something's been bugging me about how most teams are handling AI-generated UI code right now.

The pattern goes: Cursor, Copilot, v0, or Claude Code writes the component. It looks right. It compiles. It probably even matches the Figma file at a glance. Then six sprints later someone notices the button padding doesn't match the design tokens anymore, or the loading state was never implemented, or there's a hardcoded hex value sitting in a component that's supposed to pull from the theme. Nobody did that on purpose. It just... drifted.

The numbers back this up if you don't already feel it in your own codebase. Faros AI's 2026 engineering report found code churn is up 861% against pre-AI baselines, and 31.3% more PRs are now merging without any human review at all. Humans didn't get worse at reviewing. There's just more to review than any team can keep up with, and a lot of what's slipping through isn't broken code — it's code that's quietly disagreeing with the design system it's supposed to be implementing.

So teams reach for the obvious fix: point another AI model at the diff and ask it to catch what the first one missed.

I think that's the wrong architecture, and it's worth explaining why.

The problem with "AI checking AI"

Using an LLM to catch drift introduced by another LLM has three structural problems that don't show up until you're relying on it in production:

It's non-deterministic. Ask the same model to review the same diff twice and you can get two different answers. That's fine for a suggestion. It's not fine for something you want to gate a merge on, because "sometimes it catches this class of bug" isn't a policy, it's a coin flip.

It's expensive in a way that compounds. Every scan is more tokens on top of the tokens that generated the code in the first place. At CI scale, across every PR, that adds up fast — and it's a cost that scales with your team's AI usage instead of shrinking it.

It's a black box checking a black box. If a model flags something, can you explain why to a teammate, in a way that's the same explanation every time? If not, you've just added a second layer of "trust me" on top of the first one.

None of this means detection should be AI-powered. It means the checker needs a different design than the thing it's checking.

What deterministic checking actually buys you

A deterministic engine — same input, same output, every single time — isn't just a nice property. It's what makes a check trustworthy enough to gate a merge on in the first place. If a rule flags something, it flags it because a specific, inspectable condition was true, not because a model's confidence crossed some threshold on a given run. That means:

You can explain exactly why something was flagged, every time, to anyone.
It's safe to run in CI as an actual gate, not just an advisory comment.
It doesn't get more expensive as your team ships more AI-generated code — there's no additional model call per scan.
Two people running it on the same code get the same answer, which is the whole point of having a shared standard at all.

This is the architecture we went with for ReWeaver: a versioned rule engine that runs the same checks over your design source and your code, surfaces drift as a diff, and never asks you to trust a probability score.

Drift isn't one thing — it's at least nine

"Design-code drift" gets used loosely, so it's worth being specific about what it actually covers. We ended up mapping it across nine dimensions, because "does the code still match the design" turns out to be a much bigger question than color and spacing:

Design Consistency — hardcoded hex values and inline styles that bypass your design tokens.
Accessibility — missing roles, broken keyboard patterns, the stuff that's functionally fine but unusable for real users.
User Experience — the happy path is complete but the loading, empty, error, and undo states around it never got built.
Reliability — stale closures, missing cleanup, absent error boundaries — the edge cases that don't show up until production.
Maintainability — the defensive fallbacks and copy-paste noise that accumulate every sprint until the codebase is mostly scar tissue.
Architecture — business logic that quietly collects in UI components instead of where it belongs.
Testability — tests that pass on write and don't actually protect anything once the code changes.
Security & Privacy — vulnerabilities reproduced from training data that look identical to safe code.
AI Code Governance — no audit trail of what was accepted, overridden, or suppressed, and by whom.

A hardcoded color and a missing error boundary are both "drift" in the sense that matters here: the code no longer agrees with the intent it was supposed to implement, and nothing forced a human to make that decision on purpose.

Finding it isn't the hard part — deciding what to do about it is

A checker that only flags issues just moves the bottleneck. You still need someone to triage every finding, which doesn't scale any better than manual review did.

So, findings come with a proposed fix, not just a flag. And when something genuinely should be suppressed — a false positive, a deliberate exception — that suppression has to be an explicit, git-visible decision (a //reweaver-ignore with a reason), not a silently ignored warning. Given that nearly a third of PRs are merging without review at all, a decision gate only does anything if someone is actually the one making the decision. The goal isn't to add another layer of noise on top of an already-overwhelmed review process — it's to make sure the decisions that do get made are visible and on the record.

It's also model-agnostic by design. It doesn't matter whether the code came from Cursor, Copilot, Claude Code, or v0 — the same rule engine runs regardless, and it doesn't need extra API tokens to do it. It runs inline in VS Code, does a round-trip sync with Figma (not just one-way detection), and runs as a GitHub Action on every PR — no new dashboard, no workflow change.

Where this stands right now

We're in private beta and looking for a small number of teams actually shipping AI-generated frontend code to run this against a real repo and tell us what you find. Even if it's just one small workflow, your feedback is valuable.

The beta is developer-led, not a sales process — install it, point it at something real, see what surfaces. You get direct access to the founder and engineering team for bugs, questions, and feedback while we build this out.

(Current caveat, in the interest of not overselling: it runs primarily on Mac today. Windows support exists in beta but has some rough edges we're still smoothing out.)

If you want to see the detection engine before committing to anything, there's a no-signup Playground where you can paste a snippet of real AI-generated code and get a live drift score. If you're interested in the full beta — running across your actual codebase, Figma files, and PRs, that's here.

Either way, if you're dealing with this problem, I'd genuinely like to hear how you're handling it today, even if it's not with us.

Preventing Drift with a True Closed-Loop Roundtrip

Jonathan Gordon — Thu, 25 Jun 2026 15:11:57 +0000

Every team that ships software eventually faces the same invisible problem: the design and the code start out in agreement and then quietly stop being the same thing. The roundtrip is what fixes it—but only if the loop **actually closes.

TL;DR

Design-code drift is the silent, accumulating gap between what was designed and what ships — and it predates AI.
The industry has gotten good at handoffs. A handoff is not a roundtrip.
Generation-based roundtrips where each pass re-interprets rather than verifies, don't close the loop. They accelerate drift at a more rapid pace.
A true roundtrip doesn't just translate. It verifies. It tells you whether what you're looking at is still the same artifact, not a plausible approximation of it.
ReWeaver AI exists to close that loop for real: naming drift, measuring it, and resolving it in both directions.

The Quiet Tax Every Team Pays

Every team that ships software pays a quiet tax. On the first day, the design and the code agree. Then the design changes, the code changes, and the distance between what was drawn and what's getting built starts to grow. By the time anyone notices, the redlines no longer describe the product, and the "source of truth" has quietly become a file two teams have stopped trusting.

This is design-code drift — and most of the industry treats it like the weather: something you complain about, and plan around but never really expect to fix. It's the reason design systems rot, the reason "pixel-perfect" is now a punchline, and the reason designers and engineers suspect the other has gone off-script.

Design and code are connected. Unlike the weather, we can affect outcomes rather than simply accept drift as a given.

Drift Lives in the Gap Between Design and Code

The usual connection between design and code is a handoff. Someone turns a design into code, or code into a design, and then lets go. What AI produces is a snapshot — accurate the moment it's captured and wrong not long after, because there's nothing that carries the next change across the gap. When this happens in both directions, you have two different snapshots pointed at each other, never meeting in the middle.

A verified roundtrip where changes in one side are translated into changes in the other is the solution. The loop stays closed. What returns is the same artifact rather than a fresh reinterpretation of it that crossed the gap. Drift only happens when the loop never truly closes. Fix that gap, and drift goes with it.

Why Generation Alone Won't End Drift

The obvious objection in 2026 is that models have gotten remarkably good at turning code into a design and a design into code. Some will say: why won't generation simply handle the roundtrip?

Because better generation answers the wrong question. Ask a model to generate, and it shows you what something could look like — plausible enough to earn a "Wow." What a team actually needs to know is whether the artifact in front of them is still the same as the code behind it. Plausibility doesn't address that. A generated result can drop a value, approximate a layout, or reinvent a component. Because looking right is the whole assignment, no one is watching for these silent failures.

There's a more stubborn reason generation alone won't end drift: a system that guesses can't vouch for what it produces. Every regenerated pass is a new interpretation. New interpretations don't line up with the last one, so the faster that loop spins, the faster it drifts. Each cycle is another chance to wander from the source that the previous cycle had already settled. That isn't closing the loop. It's drift on overdrive with a faster clock and better marketing.

Closing the Gap: Trust and Verification

In a world where everyone can generate beautifully in both directions, the original problem survives untouched. There is still no guarantee that what you're looking at is still true.

A tool doesn't earn trust when it always gives a thumbs-up. A trustworthy system is one that will reliably say, "There's a problem, and here's where it is." Most tools can make a design that looks right. The harder, more valuable challenge is making a design that is right, and keeping it that way.

Drift is the problem nearly every team already feels, and almost no one has bothered to name.

Generation and verification are different operations. Generation produces something new. Verification compares what exists to what came before. The industry has gotten very good at the first one. Almost no one has built for the second.

ReWeaver AI exists to close the roundtrip for real, in both directions. It names drift for what it is, measures it with the Production Drift Ratio, and closes the gap so that the design and the build are reliably the same.

This is the problem ReWeaver AI was built to solve. Join the beta or try the Playground to see where drift is living in your code.

Frequently Asked Questions

What is design-code drift?

Design-code drift is the accumulating gap between a product's original design intent and the code that actually ships. It doesn't require a single dramatic mistake — it compounds across small decisions: a color value approximated here, a component reimplemented there, a spacing token ignored in the next sprint. Drift has always existed in software development, but AI-assisted development accelerates it because models generate plausible code faster than human review can verify it.

What is the difference between a design-code roundtrip and a handoff?

A handoff is a one-time transfer — a snapshot of one artifact converted into another. A roundtrip keeps the loop continuously closed: changes on either side propagate back to the other, and the artifact stays true across both. Most tools, including current AI-powered design-to-code flows, produce handoffs that look like roundtrips. The distinction is whether the system verifies that the two sides still agree, or simply generates a new version that looks plausible.

Why don't current design-to-code tools solve drift?

Most design-to-code tools are generation tools. They produce a new version of one artifact from the other — plausible, often impressive, and fundamentally unverified. Because each pass through the loop is a fresh interpretation, divergence accumulates with every cycle. The loop appears to close, but what's actually happening is a series of re-translations, each one a small opportunity to drift further from the source.

What is ReWeaver AI, and how does it address drift?

ReWeaver AI measures and resolves design-code drift using the Production Drift Ratio (PDR) — a score that quantifies how far a codebase has drifted from its intended production-ready state, weighted by the engineering time required to remediate it. Unlike generation-based tools, ReWeaver's drift-detection engine doesn't use an LLM to guess at what looks right. It compares what exists against what was specified and flags the gap. The goal is a closed loop in which the design and the build are verifiably the same—not just plausibly similar.

Why can't AI generation solve the roundtrip problem on its own?

Because generation and verification are different operations. Generation produces something new that looks plausible. Verification confirms that what exists matches what was specified. A model that re-generates a design from code on every pass produces a new interpretation each time — and new interpretations accumulate divergence. The faster that loop spins, the faster drift compounds. What ends drift is not a better generator but a system that can say with confidence: these two things are still the same, or here is exactly where they aren't.

What does "closing the loop" mean in design-code workflows?

Closing the loop means that a change on either side — design or code — is reliably reflected on the other side without loss, reinterpretation, or manual correction. Most teams have a loop that opens and closes imprecisely: a designer updates a component, an engineer re-implements it from the updated spec, and somewhere in that translation, a value changes or a behavior gets dropped. A truly closed loop doesn't re-interpret. It verifies, propagates, and confirms.

The Production Drift Ratio: Why AI Development Teams Need to Quantify Drift

Jonathan Gordon — Tue, 23 Jun 2026 19:55:32 +0000

When AI ships code faster than anyone can review it, velocity metrics go vertical, and code drifts rapidly and silently from the original intent, accumulating problems and vulnerabilities in its wake. The Production Drift Ratio is the first metric designed to make that cost visible.

TL;DR

Drift is defined as the silent and accumulating gap between design intent and code output.
AI-assisted development creates code drift faster and at greater volume than human review can catch.
Standard velocity metrics (story points, PRs, time-to-merge) do not measure drift.
The Production Drift Ratio (PDR) expresses drift as a number that quantifies the amount of drift weighted by how much time and effort would be required to address it.
A PDR below 0.30 is low; above 0.70 is severe.
AI should be used to detect and fix drift, not just generate it.

The Problem: AI Has Become a Drift Engine

Software has accepted a quiet bargain: ship faster, ship more, ship anything — and stop asking whether it's any good. AI made the trade feel free. Generate a component in thirty seconds, refactor by prompting, spin up a feature before the standup ends. The velocity charts went vertical. Underneath them, the codebases started coming apart.

This is drift — the silent and widening gap between the standard a codebase is supposed to meet and the state it's actually in. No single commit causes it; a raw hex value here, a dropped focus state there, an API call in the wrong layer, each defensible alone but corrosive together. Drift has always existed. What's new is the pace. A model that emits plausible code faster than anyone can review it is, by the same token, a drift engine. We argue that drift, not code quality, is the real problem.

Almost no one measures it. The industry has become expert at quantifying how much code it produces but has not paid attention to how far that code has drifted from intent.

What Is the Production Drift Ratio?

The Production Drift Ratio (PDR) measures how far a codebase has veered from its intended production-ready state and weights the result by how time-intensive that drift will be to remediate. The PDR makes degradation visible long before it compounds into a crisis. The PDR score ranges from zero (no drift) to one (profound drift).

PDR Score Reference Table

PDR Score	Label	Meaning
< 0.30	Low	Minor drift, easily absorbed by normal development. No dedicated sprint time needed.
0.30 – 0.50	Moderate	Noticeable drift. Worth allocating sprint time to address before it compounds.
0.50 – 0.70	High	Significant drift. Dedicated cleanup effort required.
≥ 0.70	Severe	The codebase has substantially diverged from production readiness and represents a compounding liability.

Low drift is what a normal week absorbs without noticing. Severe drift represents significant amounts of dedicated remediation time that no one has planned for.

What Velocity Metrics Miss

Story points, PRs per week, time-to-merge: these metrics count output and stay silent on whether the output was any good. AI has widened that blind spot enormously. When a model emits 800 lines of plausible TypeScript in a minute, the metrics keep climbing while the thing they're supposed to measure quietly stops being true:

A button gets re-implemented 17 times across nine teams, each with a slightly different focus ring, and none matching the design system.
Accessibility regressions ship continuously — interactive elements built from non-semantic markup, focus traps in dialogs — because the model doesn't know what your users can or can't see, and nothing is checking.
Business logic and API calls pile up inside UI components, secrets get bundled into the client, error boundaries go missing. None of it appears in the dashboard until one of them takes down a page in production.

None of this shows up in velocity; all of it shows up in the codebase, and eventually in a product that looks like seven teams built it, because seven teams plus a model did. Or worse yet, seven agents built it on their own with humans only "in the loop." This is the drift no one was measuring, and a cost no one counts is a cost no one has to answer for.

Why Quantifying Drift Changes Everything

Every drifted token, every stripped focus state, every API call in the wrong layer is a small debt written against some engineer's future afternoon. Drift only becomes real when expressed in the one unit engineers actually trade in — hours of human attention — weighted so that a flood of trivial issues never obscures the one problem that matters.

And that number changes the leadership conversation too.

Caring about coherence has always been a thankless, invisible job — whether you were the accessibility advocate, the architect worried about coupling, or the design-systems lead watching tokens erode. You would notice the codebase drifting, try to make the case to leadership, and lose — because "things feel inconsistent" is not a sentence that wins a planning meeting against a roadmap.

A PDR score changes that conversation entirely. Drift expressed as a cost — this much engineering time, concentrated in these parts of the system — is something leadership already knows how to weigh against everything else competing for the sprint. The worry stops being a matter of taste and becomes a line item in the budget. That shift, from taste to evidence, is what finally lets the people who care about coherence win an argument they have been losing for years.

AI Should Detect and Fix Drift, Not Just Create It

The same technology that can scatter a thousand subtle deviations across a codebase in an afternoon should be clearing the ones with an unambiguous fix. Deviations with a single correct resolution are fair game for automation. The judgment calls — should this new pattern join the system or be refactored out? Is this divergence intentional? — should remain human decisions.

The future we are building is a human-to-human loop with AI working quietly in the middle: the cost gets named, the unambiguous parts get resolved, and the important decisions go back to the designers and engineers equipped to make them.

Production Readiness at AI Speed: What ReWeaver AI Is Building

Craft at speed is not a contradiction. It just has a prerequisite: sight. A team that can see its drift can move fast and stay coherent. A team that cannot only finds out where it stands when the simple feature takes two weeks and nobody can say why.

ReWeaver AI was founded on the belief that production readiness should be something a team can see and steer by — not a feeling a few people have to defend in rooms where feelings lose to hard numbers. The Production Drift Ratio is the first expression of that belief.

We are actively sending invitations for the beta and sharpening the product capabilities against real codebases to deliver the best product experience possible. If you have watched your own work drift and wished someone were counting, join us for the Beta, try out some of our key capabilities in the Playground, and follow along at reweaver.ai.

Frequently Asked Questions

What causes drift in AI-generated code?

Drift occurs when small deviations from a codebase's intended standards accumulate faster than human review can catch them. No single commit causes drift — it compounds across hundreds of small decisions: a raw value here, a misplaced API call there, a focus state stripped from a component. The structural cause is that AI generation speed has outpaced the review processes designed for human-pace development.

How is the Production Drift Ratio different from code quality scores?

Traditional code quality scores measure static properties of code — test coverage, complexity, linting violations. The Production Drift Ratio measures the gap between what a codebase was specified to be and what it actually is, expressed in hours of engineering time required to close that gap. A codebase can pass every linter and still carry a high PDR if AI-generated components have drifted from the design system, accessibility requirements, or architectural standards.

What is a good Production Drift Ratio score?

A PDR below 0.30 is considered low — an amount that a normal development week absorbs without dedicated cleanup. Between 0.30 and 0.50 is moderate and worth sprint time. Above 0.50 requires dedicated remediation. Above 0.70, the codebase has substantially diverged from production readiness and represents a compounding liability.

Does the Production Drift Ratio replace code review?

No. The PDR is designed to make drift visible and quantifiable so that human review can focus on decisions that require judgment. It automates the identification of deviations with unambiguous resolutions, clearing noise so engineers and designers can focus on the architectural and design questions that cannot be pattern-matched.

What types of drift does ReWeaver AI detect?

ReWeaver AI's drift-detection engine identifies deviations across design system alignment, accessibility compliance, architectural patterns (such as business logic placed inside UI components), and production readiness standards. The engine does not require the use of an LLM — findings come from deterministic drift detection, not inference.

How does AI-assisted development create accessibility drift?

AI models generate code based on statistical patterns in training data, not on an understanding of a specific user's needs or a team's accessibility standards. As a result, AI-generated components frequently omit semantic markup, skip focus management, and miss ARIA requirements. Because these gaps ship continuously at AI-generation speed, accessibility drift accumulates faster than traditional review cycles are designed to catch.

Talking about the "design-code roundtrip that isn't" at AIE World's Fair

Jonathan Gordon — Tue, 23 Jun 2026 16:43:22 +0000

Here's the abstract for my talk on Wednesday of the conference (July 1):
Everyone is using Figma's MCP tools, Claude Code, or Codex. The demos are seamless. The narrative is compelling. What's actually happening under the hood is something else entirely. And the gap between the story and the reality is where your next six months of pain is going to come from.

I'm Jonathan Gordon, founder of ReWeaver AI and a programmer-turned-UX designer who spent 30 years in developer tools at Google, Microsoft, Apple, Facebook, and Oracle watching the design-engineering gap widen in slow motion. I've seen every generation of tooling promise to close it. I know exactly where the seams are.

I wrote a technical teardown of what Figma's bidirectional workflow actually ships, what get_design_context does, what generate_figma_design actually captures (hint: it's a screenshot, not your design system), and why iterating through that loop 12 times leaves you progressively farther from your canonical design intent.

This talk will walk attendees through each step, backed by research and specific examples, and include a demo showing how drift accumulates in real time. The problem is not that drift happens; it's that it's happening exponentially. Let's talk about how we can stem that tide and keep humans in control of the process, not just "in the loop."

https://www.ai.engineer/worldsfair/2026