In Class 37 you learned that professional AI development can look slower because every change carries a definition: goal, scope, checks. Context drift is what happens when that definition slowly stops guiding the work.

What context drift actually is

Context drift means the AI's next steps begin following something other than the agreed task: an accidental assumption, an old message, an attractive side quest, or a goal it inferred incorrectly. You asked for source dates; three hours later the agent is proposing a new state-management library and a database migration. Each step felt locally reasonable. The destination is wrong.

This is not proof the AI is malicious or useless. It is a predictable failure mode of long, ambiguous work: an agent built to keep going fills gaps and tries the next plausible step, and helpfulness compounds into drift.

Why long conversations drift: the context window

To understand drift, recall Part IV on context windows. The context window is the working material a model can actively consider in one turn or session: instructions, loaded files, conversation so far, tool outputs. It is not infinite, perfectly organized project memory.

Context-window management is therefore a real coding skill, not an optimization detail. As a coding conversation grows, it accumulates old plans, failed experiments, superseded decisions, code snippets, test logs, and half-tested assumptions. Even a large window eventually becomes expensive and harder for the model to prioritize correctly. The model starts weighting stale material as heavily as current material. More context is not automatically better context.

The operating rule is simple:

Load the specification, the relevant files, the current decision, and the acceptance checks. Do not feed every old chat message or the entire repository into a task that only touches one component. A session doing citation-date display needs the citation component, the research-record mapping, and the rule for missing dates — not the full export history and three earlier navigation debates.

Watch the window while you work

Do not wait for total failure. Watch for these signs during the session:

• The model repeats a question you already settled.
• It refers to an older version of the plan you replaced.
• It forgets a constraint you stated clearly ("no new dependencies").
• Its answers get broader instead of narrower as the task continues.
• It loses track of the next acceptance check.
• It spends tokens re-reading material that is no longer relevant.

Any one of these is a signal to pause and create a clean handoff before another change is made. Treat these signs the way a client treats a crew opening walls that were never in the plan: stop, look at the plan, re-agree, then continue.

Sloppy input creates risky inference

Drift often starts before the first edit, in a vague request. AI is built to be helpful when details are missing, so it fills gaps with a plausible assumption: which user role is meant, whether a field may be nullable, what a button should do, which pattern applies, whether it may change a related system. Often that inference is correct. When it is wrong, a small request becomes the wrong feature or a broad rewrite — all delivered confidently.

The operational rule:

Do not keep prompting around a wrong assumption. State the decision, update the task file, and resume only with that ambiguity removed. One explicit sentence now ("shareable means a private link for the account owner, nothing public") prevents forty confident edits in the wrong direction.

Five drift signals to memorize

Keep this list visible while an agent works:

1. Scope explosion. You asked for a small bug fix and it proposes a framework replacement. 2. Unasked structural changes. The model changes a database shape or authentication path without being asked. 3. Time travel. The answer keeps referring to an older version of a decision you already revised. 4. File-list growth. The list of touched files grows while the acceptance check remains unresolved. 5. The blank stare test. The AI cannot state the current goal, constraints, and next verification step in a few sentences.

If two or more appear together, assume drift, not progress.

Example: the dashboard that became a migration

Take the research dashboard. The request was narrow: show the publication date for each source. The agent returned with a proposal for a new state-management library, a redesigned navigation system, and a database migration to "support dates properly."

Each extra change adds risk while doing nothing to prove the original user outcome. A new library means new bugs. A navigation redesign means re-testing every screen. A migration means touching every stored record. None of them answers the user's question: can I see when this source was published, and what happens when the date is missing? Drift disguises itself as thoroughness.

Example: "make it shareable" means four different systems

Now consider the inference trap: "Make the research brief shareable." That single sentence can mean at least four things — a private link for the account owner, a public page indexed by search engines, a downloadable PDF, or a permissioned team workspace. Each implies a completely different access model, and the wrong one is a security incident, not a cosmetic error.

If the builder does not decide which meaning applies, the AI will choose one and confidently build it. Stop, define the intended audience and access rule, and put it in the task before code continues. Ambiguity about access is never a detail to resolve later.

Drift is a security problem, not just an annoyance

That last example points to the sharper edge. Drift is not only wasted time. An unrequested authentication rewrite, a new dependency, a database migration, a browser-side secret, or a broadened permission can create a vulnerability while you are focused on a completely different feature. You came to fix date display; you leave with a weakened login flow you never reviewed.

The intervention: STOP-AND-SUMMARIZE

When you suspect drift, use one intervention before anything else: STOP-AND-SUMMARIZE. Stop all edits, then ask the model to state:

• the goal in one sentence,
• current observations,
• files changed so far,
• tests run and their results,
• assumptions it is making,
• unresolved questions,
• the exact next proposed step — singular.

Compare it to asking a contractor to stop mid-job and show the plan before opening another wall. The summary forces the hidden reasoning into the open, where you can compare it against the agreed task.

The five-step reset protocol

If the summary confirms drift, run the reset:

1. Stop automated edits and run no further changes.
2. Inspect the actual files/diff and identify the last known-good state.
3. Save a concise handoff in Markdown: goal, decisions, evidence, changed files, unknowns.
4. Start a clean conversation with only the relevant handoff and files.
5. Ask for a plan before another edit.

The reset does not throw away knowledge. It converts a messy conversation into durable project context — the habit taught in Part II, where Markdown files carry decisions, evidence, and open questions between sessions. You keep what was proven; you leave the confusion behind.

Stop it immediately when scope breaks

One rule admits no patience: the immediate-interruption rule. If an agent starts changing files outside the agreed scope, proposes a new framework, database, or authentication design, makes an unsupported claim, or acts on an important unstated assumption — stop it immediately. Do not let it "finish the thought." Inspect the diff while the damage is still small.

Rollback: the decision before the mechanics

Sometimes the right move is a rollback: returning the project to the last known-good version after a bad change. For a local uncommitted change, that may mean restoring the affected files after inspection; for a saved checkpoint, it means returning to the working version and reattempting the task with a cleaner brief. Part X teaches the exact Git mechanics — commits, diffs, branches, and reverts. Here you learn the decision: when the task is off the rails, stop, inspect, roll back, and restart from a known-good point rather than piling repairs on a bad direction.

Timing matters. A fifteen-minute wrong turn is a small correction; three hours of agent edits, follow-up patches, and new dependencies turn into a difficult investigation. Early rollback is not giving up.

The 2-loop rule: stop guessing, audit before the next try

If the AI fails the same task twice with the same approach, do not let it try a third time the same way. Two failed loops is the signal — the plan is wrong, the context is polluted, or a key fact is missing. More retries just burn tokens and bury the evidence.

Stop it with one of these two prompts (pick the one that fits, or run both in order):

Option A — summarize and diverge (fast):

Option B — full workflow audit before another guess (thorough — use when the task matters):

Option B is the stronger medicine: it forces the model to reconcile its work against the task, the contract, and the evidence instead of inventing a third variation. Use it whenever the change touches auth, data shape, money, or production — or whenever Option A returns two guesses that both sound like guesses.

After either prompt: resolve the open decisions yourself, update TASK.md (and the interface note if the contract moved), start clean if the context is polluted, and only then approve one approach for one more bounded attempt.

Keep a context budget: the SESSION-HANDOFF.md habit

Make the reset cheap by practicing it when things go well. After the source-date feature is complete, save the decision, changed files, test result, and remaining question in SESSION-HANDOFF.md. Then start the next task — say, an export fix — in a clean session carrying only the export files and the handoff, rather than dragging the entire source-date discussion into the new work.

Exercises

1. Write the handoff. Take a long chat (real or imagined) and create SESSION-HANDOFF.md with objective, current state, constraints, evidence, unknowns, and next bounded task.

2. Run the interruption drill. Give an AI an ambiguous task ("make the report shareable"). Identify its first inference, stop before implementation, write the missing decision into a clean brief. Then name the checkpoint or diff you would inspect if it had already changed files.

Finish line: one clean handoff a new AI session could use without reading the transcript.

Check your understanding

• What is context drift, and why is it predictable rather than malicious?
• Why can a longer conversation produce worse results than a short, task-specific one?
• What should you do the moment you notice the model inferring something important?
• What does STOP-AND-SUMMARIZE require the model to state, and why stop edits first?

In the next lesson you will move from recovery to prevention: the rails — bounded-change requests, file boundaries, plan-first conversations, and model routing — that keep the AI productive without letting it wander.