Context Drift

Context drift is the gradual divergence between the information an AI system acts on and the current, approved truth about a product or business. In AI-assisted software development, it shows up as code whose behavior slowly moves away from the approved requirements, because agents keep working from incomplete, outdated or inconsistent context. The output often looks correct, which is what makes drift hard to catch.

How Context Drift Works

Drift rarely comes from one big mistake. It accumulates through ordinary work:

• Gaps filled by guesses: a requirement leaves an edge case undefined, and the agent makes a reasonable assumption that nobody approved.
• Decisions that do not propagate: a rule changes in a meeting or chat, but the spec, tickets and tests still describe the old version.
• Stale material re-entering context: an outdated document or old conversation is loaded into a new session and treated as current.
• Inconsistent language: the same concept is named differently across tasks, so separate pieces of work interpret it differently.
• Tests that confirm the code, not the intent: tests written from the implementation lock in drifted behavior instead of catching it.

Each step is small and locally sensible. Over many tasks and sessions, the small gaps compound.

Why Context Drift Matters

Drift is a quiet failure. A hallucination often produces something visibly wrong. Drift produces output that is internally consistent with the premises the AI was given, so it passes a quick review. Atlan describes this as a model reasoning correctly over stale definitions with no error signal.

For product teams, the cost appears later: features that technically work but break business rules, rework when someone finally compares the code with the PRD, and lost trust in AI-generated code. Drift also gets more expensive the longer it runs, because more code is built on top of the wrong assumption.

The countermeasures are about keeping truth in one place and connected to the work: a clear source of truth for requirements, traceability from each requirement to the code and tests that implement it, and disciplined context management so that only current information reaches the agent.

Context Drift Example

A team decides that free-trial users can create up to three projects. The rule is written in the PRD. Later, in a planning call, the limit changes to five, but only the pricing page is updated.

Over the next two sprints, a coding agent builds project creation, an upgrade prompt and an admin report. Each task loads different material. The creation logic uses the PRD (three). The upgrade prompt uses the pricing page copy (five). The admin report counts "projects" including archived ones, because nobody defined the term. Every feature passes its tests. Customers see an upgrade prompt telling them they can have five projects while being blocked at three. A detailed look at causes and prevention is in how to prevent context drift in AI-generated codebases.

Context Drift vs. Specification Drift

Specification drift usually describes an implementation diverging from one stated spec. Context drift is broader: it covers decisions, definitions, tickets, code and tests drifting apart across the delivery lifecycle, including cases where the spec itself is out of date. It also differs from concept drift in machine learning, where real-world data patterns change and a trained model becomes less accurate.