What Is Drift? (And Why Every AI-Assisted Developer Should Care)

AI now writes code faster and more prolifically than any team can review it. The result is a new category of problem that most teams feel, but no one has clearly named. That problem is drift — and understanding it is the first step to controlling it.

TL;DR

• Drift is the accumulating gap between what software was meant to be and what it has become.

• Drift is not new, but AI-assisted development has made it faster, quieter, and harder to see.

• There are several distinct types of drift — design drift, intent drift, architecture drift, semantic drift, and more — each living in a different layer of the codebase.

• Most teams measure output. Almost none measure drift. That gap is where production problems are born.

• ReWeaver AI was built to name drift, measure it, and close the gap at the source and before it compounds.

Code drift is the accumulation of divergence between a software system's intended state — its design, architecture, and specified behavior — and its actual state. It is not a bug. It does not break a test or throw an error. It is a slow, silent departure from what the system was meant to be, and it compounds with every commit that goes unverified.

The Problem No One Has Named

Ask any senior engineer or product designer about the last time a codebase felt truly coherent — when every component matched the system, every handoff landed cleanly, and what you shipped looked like what you designed. Most will pause. Some will laugh.

It doesn't stay that way. It never does. The design updates, the code updates, a model generates a new component, someone patches a bug under time pressure, and slowly — without any single person doing anything wrong — the gap opens. What was designed is no longer what ships. What ships is no longer what was specified. The system is technically functional and subtly wrong in ways that compound quietly until they aren't quiet anymore.

This is drift. And in the era of AI-assisted development, it is the central unsolved problem in software production.

What Drift Is, Exactly

Drift is the accumulating divergence between a software system's intended state and its actual state. It is not a bug — it does not break a test or throw an error. It is a slow departure from what the system was meant to be: the design that was agreed on, the architecture that was planned, the behavior that was specified.

Drift has always existed. Every sufficiently long-lived codebase drifts. What has changed is the rate. When a developer writes a component, the drift they introduce is proportional to their attention, their context, and their time. When an AI model generates the same component — in seconds, at scale, across dozens of files simultaneously — the drift it can introduce is proportional to its training distribution, its context window, and the absence of anyone checking.

The result is a new category of production risk: codebases that look right, pass tests, and ship continuously, while quietly becoming something other than what they were supposed to be.

The Taxonomy of Drift: Every Type, Defined

Drift is not one thing. It lives in different layers of a software system and shows up differently depending on where you look. Here is the full picture.

	Definition	Where it shows up
Design Drift	The gap between the visual and interaction specifications created in design tools and the components that actually render in production.	Inconsistent component behavior across teams, design systems that no longer reflect the product, UI that looks subtly different from the spec.
Intent Drift	The divergence between what code was originally designed to do and what it actually does — often invisible to tests because the code is technically functional, just semantically wrong.	Edge cases that behave unexpectedly, bugs that appear in code that "hasn't changed," business logic that no longer matches the product requirement it was built for.
Architecture Drift	The gradual erosion of the structural decisions — separation of concerns, layering, dependency rules — that a system was built around.	Components that do too many things, features that are impossible to test in isolation, and changes in one area that unexpectedly break another.
Semantic Drift	Changes in the meaning of code — variable names, function signatures, data structures — that no longer reflect what the code actually does.	Onboarding that takes longer than it should, bugs introduced by misreading a function's behavior, and code that requires significant context to understand correctly.
Context Drift	The loss of coherent system-wide understanding that occurs as codebases grow beyond what any single agent — human or AI — can hold in context at once.	Duplicate logic across teams, conflicting implementations of the same concept, changes that break distant parts of the system in ways no one anticipated.
Black Box Drift	The gap introduced when AI makes design and implementation decisions that are invisible to the humans who prompted it — plausible-looking output with hidden assumptions baked in.	Security vulnerabilities discovered after the fact, incorrect assumptions baked into components that propagate across the system, behavior that is hard to explain or audit.
Infrastructure Drift	Divergence between the expected configuration of a software environment and its actual state — particularly acute in AI-managed infrastructure.	"It works in staging but not in production," deployment failures that can't be explained by code changes, environment-specific bugs.

Design Drift

Design drift is the most visible form of drift — and paradoxically the most ignored. A spacing token gets hardcoded. A color value gets approximated. A component gets reimplemented by a different team with slightly different behavior. The design system says one thing; the product does another. Over time, "pixel-perfect" stops being an expectation and becomes a punchline.

AI accelerates design drift because generative tools produce components that look right without verifying they are correct. A model that translates a Figma frame into React doesn't know whether the component it produces matches the one already in the design system. It produces something plausible. Plausibility is not fidelity.

Intent Drift

Intent drift is the quietest and most dangerous form. A developer writes a function to handle a specific business rule. An AI agent, updating that function six sprints later, preserves the structure and the tests but subtly alters the behavior. The tests pass. The pipeline is green. The original intent — the reason the function existed — has shifted without anyone noticing.

Intent drift is a silent failure mode of AI-assisted development. AI writes code that satisfies the immediate prompt, not the original specification. When no one tracks the relationship between code and its intent, divergence accumulates undetected.

Architecture Drift

Architecture drift happens when code grows in ways that violate the system's intended structure. Business logic migrates into UI components. API calls appear in places that were supposed to be stateless. A clean separation between layers gets bridged by one shortcut, then another, until the boundary no longer exists.

AI accelerates architecture drift because models optimize for task completion, rather than architectural coherence. An agent asked to add a feature will find the shortest path to a working result — often one that cuts across the architecture rather than respecting it. No single change is indefensible. The pattern, accumulated over dozens of sessions, is erosion.

Semantic Drift

Semantic drift is the gap between the labels on a system and what those labels now mean. A function called validateUser that, once validated, now also logs, rate-limits, and mutates session state. A variable named isActive that encodes three different conditions depending on context. The code works, but reading it misleads.

In AI-assisted development, semantic drift accelerates because models generate names based on context at the time of generation, not based on what a name will mean as the system evolves. As code is patched, extended, and refactored by successive AI sessions, the names and the behavior drift apart.

Context Drift

Context drift is a structural problem of scale. A developer working on one file doesn't see the three other files that duplicate its logic. An AI agent working within its context window doesn't know about the invariants established in the files outside it. Decisions get made locally that conflict with decisions made elsewhere, and no one has the full picture to catch it.

As codebases grow and AI agents take on more autonomous work, context drift becomes a systemic risk. Each agent session is coherent within itself and potentially incoherent with everything outside it.

Black Box Drift

Black box drift is the newest and least understood form. When a human implements a design, the decisions they make are legible: you can ask them why they chose a particular approach, what trade-offs they considered, what they weren't sure about. When an AI generates the same implementation, those decisions are hidden. The output looks right. The reasoning that produced it is inaccessible.

The result is a codebase that accumulates invisible assumptions: wrong choices that no one made intentionally and no one can easily trace. A model sounds confident. The output passes review. The hidden decision only surfaces when an end user finds it.

Infrastructure Drift

Infrastructure drift is well understood in DevOps: environments are patched manually, configurations diverge from their specifications, and what was deployed no longer matches what was declared. AI-assisted infrastructure automation accelerates this by introducing configuration changes at speed, sometimes without the audit trail that makes drift detectable.

Why All of This Matters More Now

Every type of drift described above existed before AI. What AI has changed is the rate, the volume, and the invisibility.

A human developer drifting from a spec does so at human speed, with human context, and usually with some awareness that they're making a trade-off. An AI agent drifting from a spec does so at generation speed, across the full codebase, with no awareness that anything is wrong — because for the agent, nothing is wrong. The output satisfied the prompt.

The result is that the old approaches to managing drift — code review, design QA, occasional architecture reviews — are no longer paced appropriately for the problem. The gap between what teams produce and what teams inspect has widened to the point where drift is no longer an occasional problem. It is a continuous condition.

How to Measure Code Drift

Measuring drift requires comparing the current state of a system against its intended state — continuously, not just at review time. Most teams don’t do this. Most tools don’t support it.

Measuring drift requires comparing the current state of a system against its intended state — continuously, not just at review time.

Standard engineering metrics — lines of code, pull requests merged, features shipped — count output. They say nothing about how far that output has drifted from intent. A codebase can hit every velocity target and still be drifting faster than the team can see.

The right question is not "how much did we ship?" It is: is what we shipped still the same thing we designed, specified, and agreed on? That is a verification question, not a generation question. And most of the tools in the current ecosystem are generation tools.

ReWeaver AI was built for the verification side. The Production Drift Ratio (PDR) quantifies how far a codebase has drifted from its intended production-ready state, weighted by the engineering time required to remediate it. It doesn't use an LLM to guess at what looks right. It compares what exists against what was specified and surfaces the gap — so that teams can see drift while it is still a choice to address, rather than after it has become a crisis.

Frequently Asked Questions

What is the difference between a bug and drift?

A bug is a discrete failure: something does not work. Drift is a directional departure: something still works, but it is no longer what it was supposed to be. A bug shows up in a test. Drift shows up when you compare the current state of a system to its original intent — and find that the two have quietly stopped agreeing.

Does drift only happen with AI-generated code?

No. Drift has always existed in software development. Every codebase that evolves over time accumulates some amount of drift. What AI-assisted development changes is the rate at which drift accumulates and the invisibility of the decisions that produce it. AI generates at speed and at scale, without the self-awareness a human developer has when making a trade-off.

Which type of drift is most dangerous?

Intent drift and black box drift are typically the most damaging because they are the hardest to detect. Design drift and architecture drift are more visible — you can see a mismatched component or a violated separation of concerns — but intent drift and black box drift can hide behind a green test suite and a passing code review for a long time before they surface.

How does ReWeaver AI detect drift?

ReWeaver AI's drift-detection engine compares the current state of a codebase against its intended production-ready state across multiple drift dimensions: design system alignment, accessibility standards, architectural patterns, and behavioral specifications. It does not use an LLM to infer what looks right — it uses deterministic detection to surface where the current state diverges from the specified state, and weights the result by the engineering time required to remediate each finding.

Can drift be prevented entirely?

No. And trying to prevent all drift is not the right goal. Some drift is the natural result of a system evolving as requirements change. The goal is to keep drift visible, measured, and manageable so that it never accumulates to the point where it becomes the invisible reason a simple change takes three times as long as it should. A team that can see its drift can make informed decisions about when to address it. A team that can’t is always in reaction mode.

How is drift different from technical debt?

Technical debt is a deliberate or accidental accumulation of shortcuts that will need to be addressed later. Drift is a divergence from intent — what the system has become versus what it was supposed to be. The two overlap but are not the same thing. You can have a codebase with low technical debt that has drifted significantly from its original design intent, and vice versa. Drift is specifically about the gap between specification and reality.

---

ReWeaver is currently in private beta. Try out the ReWeaver Playground to see where drift is living in your codebase today, and then request to join the beta for full repository-level drift detection on every commit.