AI Code Is Drifting, and Nobody Is Measuring It | Jonathan Gordon of ReWeaver

What we talked about.

Sunny Ray talks with Jonathan Gordon of ReWeaver about AI code drift, the gap between what a team intended and what the shipped software actually does. Gordon traces his path from software developer to usability engineer after watching staffing industry users bury his software behind sticky notes. He later worked on developer tools at Microsoft, where he owned accessibility for Visual Studio, and also worked at Oracle and SAP. He describes first spotting risky generated code while vibe coding, which led him to build ReWeaver, currently in beta. Gordon argues that AI cannot reliably check AI because models are probabilistic, so ReWeaver relies on deterministic detectors across nine dimensions of production readiness, including accessibility based on WCAG. He points to missing ARIA labels and empty try-catch blocks as examples of silent failure patterns that pass tests but frustrate users. The conversation also covers the gaps between design and engineering, the mentors who shaped his career, and why ReWeaver keeps the human in control of every decision by flagging problems and suggesting fixes rather than applying them automatically.

AI ships code faster than anyone can review it, and Jonathan Gordon explains how to see the drift between intent and outcome.

The questions, and the answers.

What did you see on that site visit that changed your career?

I had built a staffing software system and was proud of it. Then I watched real users, and it did not fit how they worked. There were constant interruptions and sticky notes covering their screens, with my software hidden behind them. I decided right then to stop creating pain for users and start solving it, so I moved into usability engineering.

What is the main lesson you carry from building developer tools at big companies?

Humans struggle to build systems because we each see the problem from a different perspective. That is healthy, but the challenge is aligning those perspectives. A designer, a developer, a product person and the business all speak different languages. Building a common language across those disciplines is really hard, and it shows up everywhere.

When did you first notice drift in AI-written code?

It was not immediate. I was blown away at first, building a shopping list app in Cursor. Then I watched code fly by and spotted an innerHTML pattern I knew was vulnerable. I asked the model about it, and it just said my bad and fixed it. I realized many people would never catch that, and that is when ReWeaver was born.

Why not use AI to check AI-written code?

AI is probabilistic and always will be, so you never get the same output from the same input. My stance is that AI cannot fix AI, because you are throwing another guesser at a guesser. It might get lucky if you keep pulling the handle, but it will never be deterministic, and that is what checking code requires.

What surprised you most when you tested AI coding tools?

Accessibility. I owned it for Visual Studio, so I know ARIA labels matter for screen reader users. I challenge anyone to view the source of an AI-built shopping app and count the ARIA labels. Probably fewer than one. Accessibility is a foundation of production readiness, and the models did not implement it.

Who feels drift first inside a company?

The people closest to the user feel it first, because drift ultimately shows up in the end user experience. Tests still pass and you can still ship, but the user feels it. One example is a button that does nothing because the code has an empty catch block that fails silently. I call those silent failure drift patterns.

How does ReWeaver handle problems it finds?

The human is always in control of every decision. ReWeaver tells you an issue exists, like an empty catch block, and offers a fix you can choose to use or not. It runs deterministic detectors across nine dimensions of production-ready code, including accessibility following WCAG, so newer developers get that knowledge built in.