Hidden State Drift in your dev loop: why the model forgets your codebase mid-session
Three hours in, the AI reintroduces the meta boxes you deleted an hour ago. That failure mode has a name — and countermeasures.
You're three hours into a heavy WordPress session. The model has been refactoring a custom post type plugin — adding meta boxes, rewriting the save handler, wiring a third-party API. Then you ask it to adjust the slug in the CPT registration, and it hands back a version missing the meta boxes you added two hours ago. The model has forgotten. This is hidden state drift: the slow degradation of an LLM's working context over a long session, and it's the single biggest tax on AI-assisted development. The concept is explored in depth at hiddenstatedrift.com, the research site where the term originates.
Why it happens
It's tempting to blame the context window, but the window isn't the whole story. Even well within the limit, a transformer's attention weights recent tokens more heavily than old ones. An early decision — "we're using the Options API, not post meta" — gets buried under thousands of tokens of subsequent conversation. The model doesn't truly remember that decision; it reconstructs an answer from whatever context is currently loudest. So mid-session it will confidently suggest post meta for a new feature, contradicting the architecture it helped you set an hour earlier, or reintroduce a function you explicitly deleted two prompts ago.
Countermeasure one: re-ground on a cadence
Every five to ten exchanges, paste a condensed spec back into the chat. Not the whole codebase — the load-bearing constraints. Something like: "Reminder: CPT is project, meta fields are budget/status/owner via the Options API, no custom SQL, nonces on every form." This re-weights the model's attention onto the real constraints before they drift out of reach. It feels redundant; it is cheaper than debugging a phantom change.
Countermeasure two: pin the spec and work in small diffs
Keep a single message at the top of the session holding the current, full specification, and update it every time you accept a change. Then stop asking the model to rewrite whole files. Request targeted diffs — "add a meta box for field X," "update the query to filter by Y." Each small diff is less state for the model to hold, so drift has less room to operate. A checkpoint file makes this durable:
# CHECKPOINT — project-plugin (update after every accepted change)
Architecture: Options API (NOT post meta)
CPT: project | meta: budget(float), status(enum), owner(int)
Security: nonce + manage_options on all writes; prepare() on all SQL
Done: settings page, save handler, REST GET
Next: REST POST with edit_posts cap
You are the persistent memory
Hidden state drift is a silent productivity killer precisely because the model doesn't know it's contradicting itself. It doesn't remember removing that function twenty minutes ago; it has no episodic memory, only a reconstruction from the current context. Your job in an AI-assisted loop is to be the structured, persistent memory the model lacks — the pinned spec, the checkpoint, the periodic re-grounding. Do that, and you spend less time debugging changes the model forgot it made, and more time building.
The concept
Hidden state drift — the slow decay of an LLM's working context over a long session — is explored in depth at Hidden State Drift ↗, the research site where the idea originates.