On this page

Related reading

← RCF

Concept

What is AI drift?

AI drift describes two problems. Across a codebase, generated code can outpace a team’s engineering discipline. Within a coding session, the model can lose track of the specification. Each needs different safeguards.

Last updated

Codebase drift develops over weeks or months when AI output outpaces engineering practice. Session drift occurs when a model’s understanding of a task diverges from the specification during a long thread. Both differ from model drift.

Two drifts, one word

MLOps uses several related terms, including model drift, prompt drift and LLM drift, for changes in model or prompt behaviour over time. The final section distinguishes those meanings from the two software-development problems covered here.

At codebase scale, generated code exposes weaknesses in engineering discipline over weeks and months. Within a session, the model can diverge from the specification as the thread grows.

Sense How fast it moves What actually moves The fix
Codebase-scale drift Weeks and months Team discipline under faster code generation Methodology: the chain, the cycle, the contract
Session-scale drift A single thread, sometimes one afternoon The model’s working understanding of the spec Short threads and repeated specification references

Two drifts, one word

codebase scale · session scale

Two drifts, one word: the label AI drift forks into two different problems at two different scales, each with its own mechanism and its own fix. A fork diagram. At the top, a pill holds the shared word, AI drift. Two arrows branch down from it into two cards. The left card is codebase scale: weeks, whole codebase; the mechanism is intent decaying across sessions and agents; the fix is encoded requirements plus traceability. The right card is session scale: hours, a single session; the mechanism is the context window rotating turn by turn; the fix is session hygiene plus re-anchoring. One word, two problems, two fixes. AI drift: one label shared by two different problems. AI drift Codebase scale: over weeks, intent decays across sessions and agents; the fix is encoded requirements and traceability. Codebase scale weeks · whole codebase the mechanism intent decays across sessions and agents the fix encoded requirements + traceability Session scale: over hours, the context window rotates turn by turn; the fix is session hygiene and re-anchoring. Session scale hours · a single session the mechanism the context window rotates, turn by turn the fix session hygiene + re-anchoring Two drifts, one word (vertical layout). A fork diagram, stacked. A pill at the top holds the shared word, AI drift, with two arrows branching down to two cards. Top card, codebase scale: weeks, whole codebase; intent decays across sessions and agents; fixed by encoded requirements plus traceability. Bottom card, session scale: hours, a single session; the context window rotates turn by turn; fixed by session hygiene plus re-anchoring. AI drift: one label shared by two different problems. AI drift Codebase scale: over weeks, intent decays across sessions and agents; the fix is encoded requirements and traceability. Codebase scale weeks · whole codebase the mechanism intent decays across sessions and agents the fix encoded requirements + traceability Session scale: over hours, the context window rotates turn by turn; the fix is session hygiene and re-anchoring. Session scale hours · a single session the mechanism the context window rotates, turn by turn the fix session hygiene + re-anchoring
different scales, different mechanisms, different fixes

This page covers codebase-scale drift first, because it’s the slower-moving and better-understood of the two, then session-scale drift, which is newer and less named.

Codebase-scale drift

What it is

Codebase drift occurs when code arrives faster than the team can assess it. Agents then make unreviewed choices about schemas, edge cases, security and contract boundaries. The code can compile and pass agent-written tests while leaving the team unable to explain the decisions behind its behaviour.

Weak engineering discipline creates this risk with or without AI. Manual code writing previously limited how quickly it accumulated. Agent speed removes that limit and exposes existing weaknesses sooner.

Any team with weak engineering practices is at risk. Preventing drift requires explicit decisions and verification, including on teams that use little AI.

Why it surfaces now

The gap between demo-ready and production-ready is more visible when code writing is cheap. Requirements, criteria and review remain necessary. They must be carried into the agent workflow rather than assumed to follow automatically.

Teams that skip these practices produce more code with less understanding. The gap grows with each feature. The team remains responsible for deciding what to build and checking the result.

What it looks like in a codebase

These failure patterns predate AI. Agent speed makes them accumulate faster.

Schema drift under autocomplete. An agent adds a column, field or payload shape inferred from nearby code. Other services adopt it with different interpretations. Each change can look locally reasonable while the data model becomes inconsistent. Without a recorded design, the team must reconstruct the intended meaning.

Silently invented edge cases. An agent may treat empty strings as null, clamp negative numbers to zero or normalise Unicode differently for storage and display. Each can be reasonable in isolation. Without a human decision and a record, the team cannot later explain which policies the product should follow.

Tests that prove nothing. Tests written alongside generated code can verify its current behaviour without verifying the intended behaviour. Passing CI then provides inadequate product evidence. Acceptance criteria as the contract gives tests an independent target.

Requirements that were never written down. An agent can build a feature from a Slack conversation without creating a durable requirements record. When the people who remember it leave, the team loses the reason for the feature and cannot justify retaining it.

How to prevent it

The team must define requirements, acceptance criteria and the links between them. The agent implements the code within that structure.

The first safeguard is traceability. Code and tests link to criteria, stories and requirements. Code Nodes make the source reference checkable. Missing criterion or test links are visible, so the team can correct drift early.

The second is the build cycle. Every specification passes through five stages, each ending in a commit. Review is separate from Build and checks that the output matches the specified work.

The third is acceptance criteria as the contract. Criteria are written before code and verified by tests the team owns. The agent’s output is judged against that agreed target. Traceability and the cycle depend on this contract.

These are established engineering practices. As agents accelerate implementation, teams must keep those practices effective at the new pace.

Intent decay and the chain

without the chain · with the chain

Intent decay and the chain: how a codebase built by many locally coherent sessions drifts from its original intent, and how the requirement, AC and trace chain holds it on target. Two side-by-side panels compare six weeks of AI-assisted work without and with the document chain. In both, a dashed vertical line represents the original intent carried forward, and six short straight segments represent sessions, each one locally coherent. In the left panel, without the chain, the intent anchor at the top is drawn faded because the intent lives in heads and chat threads, and each session starts where the last one stopped, marked by handoff dots. The straight segments compound into an aggregate walk away from the intent line, ending visibly off-target with an arrowhead labelled intent decay. In the right panel, with the chain, the anchor is solid because the intent is encoded, and every session starts back on the intent line, pulled there by dashed connectors, with chips labelled requirement, acceptance criterion, code node and trace marking what each fresh session re-anchors on. A re-anchored session can now restart from the code node itself: the CodeNode resolves the acceptance criterion to the source that implements it. The comparison lands the section's claim: no single session is wrong; the difference is whether each one starts from the last session's code or from the documents. The document is the memory at team scale. Six sessions over six weeks. Each segment is straight and locally coherent, but each starts where the last one stopped, and the aggregate walks away from the original intent. The original intent, held in heads and chat threads, never written down. intent, in heads Handoff after session 1: session 2 starts from session 1's code, not from the intent. Handoff after session 2. Handoff after session 3. Handoff after session 4. Handoff after session 5. The drift has compounded. Six sessions over six weeks, each starting back on the original intent because the session reads the chain, not just the last session's code. The same intent, encoded in the requirement, AC and trace chain. intent, encoded Session 2 starts from the requirement. REQ Session 4 starts from the acceptance criteria. AC Session 5 starts from the code node. A re-anchored session can now restart from the CodeNode itself: the CN resolves the acceptance criterion to the source that implements it, so rcf validate catches a rename or move that would break the link. CN Session 6 starts from the trace. trace Session 1 starts on the intent line. Session 2 starts back on the intent line. Session 3 starts back on the intent line. Session 4 starts back on the intent line. Session 5 starts back on the intent line. Session 6 starts back on the intent line. Intent decay and the chain (vertical layout). Two stacked panels compare six weeks of sessions without and with the document chain. Top panel: each straight, locally coherent session starts where the last one stopped, and the aggregate walks away from the dashed original-intent line, ending with an arrowhead labelled intent decay. Bottom panel: every session starts back on the intent line, pulled there by the chain, with chips labelled requirement, acceptance criterion, code node and trace at session starts, the code node marking that a re-anchored session can now restart from the CodeNode itself. Six sessions, each straight and locally coherent, each starting where the last stopped. The aggregate drifts. The original intent, held in heads and chat threads, never written down. intent, in heads Six sessions, each starting back on the original intent because the session reads the chain. The same intent, encoded in the requirement, AC and trace chain. intent, encoded Session 2 starts from the requirement. REQ Session 4 starts from the acceptance criteria. AC Session 5 starts from the code node. A re-anchored session can now restart from the CodeNode itself: the CN resolves the acceptance criterion to the source that implements it. CN Session 6 starts from the trace. trace
with the chain, intent survives the handoffs

Coding-session-scale drift

Session drift can develop within an afternoon. As a thread fills the context window, early references lose influence. The model may invent earlier agreements or omit criteria that were in scope at the start. Individual replies can remain coherent even as the task they address changes.

Session drift has four common symptoms. Drift from the spec. Later replies solve a different problem from the original request. Reference decay. Generated code ignores a constraint given earlier. Invented agreement. The model reports an agreement that never occurred. Silent scope creep. Changes extend to modules outside the ticket without an explicit decision.

A bug-fix session can shift into restructuring an unrelated module. Tests may pass while the original bug remains unresolved, even though nobody explicitly changed the task.

A better initial prompt cannot resolve this by itself because it occupies the same changing context window. Keep work small enough for one short session. Cite requirements, acceptance criteria and trace references explicitly every few turns. Use the documents as the durable record and check output against the AC before shipping.

Assign unrelated discoveries to a separate worker with a fresh context window. Keep the original session focused on its task.

Anchor and drift

unstructured session · structured session

Anchor and drift: how a long agentic session wanders from its original instruction, and how re-anchor points hold it close. Two side-by-side panels compare a session running without structured anchors against one held by re-anchor points. Each panel plots session turns as dots along a trajectory. An anchor sits at the top of each panel as a signal-coloured ring, with a dashed vertical reference line dropping down through the panel to represent the original instruction carried forward. In the left panel, the unstructured session, the trajectory drifts steadily to the right of the reference line over eight turns and ends visibly off-target, rendered in signal colour with an arrowhead marking the drift direction. In the right panel, the structured session, the trajectory wobbles gently but stays close to the reference line, with three dashed pull-back markers at turns three, five, and seven, labelled acceptance criterion, brief section, and requirement, where the turn is re-anchored exactly on the reference line. The comparison lands the walkthrough's core claim: with structured re-anchor points, every turn can be compared mechanically against a stable target rather than against fading memory. Drift trajectory over eight turns. Each turn wanders further right of the ideal reference line. Anchor: the original instruction at the start of the session. anchor Turn 1, close to the anchor. 1 Turn 2, drift small. 2 Turn 3, drift growing. 3 Turn 4, noticeable drift. 4 Turn 5, clearly off the ideal line. 5 Turn 6. 6 Turn 7. 7 Turn 8, visibly off-target. 8 Held trajectory over eight turns. Turns hug the ideal reference line, with periodic re-anchor pull-backs. Anchor: the same original instruction, kept referenceable. anchor Re-anchor at turn 3: an acceptance criterion pulls the turn back to the reference. AC §1 Re-anchor at turn 5: a briefing section pulls the turn back to the reference. brief §2 Re-anchor at turn 7: a requirement pulls the turn back to the reference. REQ §3 Turn 1, on the anchor line. 1 Turn 2, small wobble. 2 Turn 3, re-anchored. 3 Turn 4, small wobble. 4 Turn 5, re-anchored. 5 Turn 6, small wobble. 6 Turn 7, re-anchored. 7 Turn 8, held close. 8 Anchor and drift (vertical layout). Two stacked panels compare a session without anchors against one with re-anchor points. Top panel: an unstructured session drifts steadily right of a dashed reference line over eight turns, rendered in signal with an arrowhead. Bottom panel: a structured session hugs the reference line, with three dashed pull-back markers labelled acceptance criterion, brief section, and requirement at turns three, five, and seven. Drift trajectory over eight turns. Anchor: the original instruction. anchor 1 2 3 4 5 6 7 8 Held trajectory over eight turns. Anchor: the same original instruction, kept referenceable. anchor Re-anchor at turn 3, acceptance criterion. AC §1 Re-anchor at turn 5, brief section. brief §2 Re-anchor at turn 7, requirement. REQ §3 1 2 3 4 5 6 7 8
with re-anchor points, the drift is bounded

The chain also provides durable session references. Acceptance criteria give the output a fixed target, independent of what the thread retains. See acceptance criteria as the contract and traceability.

The mechanisms behind session-scale drift are covered in more detail in Context engineering. The model isn’t wrong. It’s weighting the wrong thing., which names four ways a session’s context window goes bad: density, similarity, drift, and pollution.

How do you prevent AI code from drifting from requirements?

You prevent it by treating the requirements as the source of truth and testing the acceptance criteria, not the code. Write the AC before the agent writes anything, keep the trace from requirement to test unbroken, and run every slice through a build cycle whose review stage the agent can’t skip. At the session scale, add the hygiene above: short threads, the AC re-cited, the document as the memory.

AI drift versus model drift, prompt drift, and LLM drift

The following terms describe different problems and require different responses.

Model drift is the trained-model performance problem. A classifier trained on 2024 data starts misclassifying 2026 inputs because the world moved. The fix is retraining, monitoring, and the MLOps toolchain. Owners: ML engineers, data scientists.

Prompt drift and LLM drift are the agentic-system variants: the same prompt or the same model behaving differently across runs or across model versions, with downstream effects on agent reliability. The fix is evals, observability, and version-pinning. Owners: ML platform teams, agentic-systems engineers.

AI drift, as used here, concerns team practices and coding sessions. At team scale, use the document chain, build cycle and acceptance contract. At session scale, also keep threads short and re-cite the specification. Engineering leaders, tech leads and session operators own these practices.

These terms all describe accumulating deviations, but their causes and remedies differ. MLOps vendors and model providers cover the model and prompt variants. The RCF methodology addresses the codebase and session practices described here.