If you use AI coding tools seriously, you have probably accumulated a small pile of context files: a CLAUDE.md here, an AGENTS.md there, maybe a MEMORY.md, plus a scattering of MCP configs. They tell each tool how your project works — the conventions, the rules, the structure. They are also maintained entirely by hand, which means they are accurate the day you write them and slowly wrong every day after, until one afternoon the agent confidently follows a rule that stopped being true weeks ago.

This is context drift, and it is a structural problem, not a discipline problem. No amount of diligence keeps a hand-edited file in sync with a moving project, because the project changes constantly and the file changes only when you remember to touch it. The gap between them widens silently, and you discover it the moment an agent acts on stale instructions.

Manual memory is wrong by default

A context file is a snapshot of the project at the moment you last edited it. The project does not hold still for the snapshot. Decisions change, structure evolves, the FastAPI setup you documented gets reorganized — and the file keeps describing the old world. Because nothing forces an update, the default state of a hand-maintained context file is mildly out of date, trending toward badly out of date the longer the project lives.

The cost is subtle and corrosive. An agent following a stale rule does not error; it does the wrong thing correctly, with full confidence, because the instruction told it to. You then debug a problem that traces back not to the code but to a memory file nobody updated. The manual approach does not just fail to help — it actively misleads, precisely when you have stopped watching it.

You are re-explaining the same things forever

The other half of the pain is repetition across tools. The same project rules have to be told to Claude Code, to Codex, to Cursor, separately, again and again, because each one starts from nothing and there is no shared source of truth between them. You become a human synchronization layer, copying the same context into three different formats and keeping all three current by hand — which, predictably, you do not, so they drift independently and disagree with each other.

The deeper question people keep asking is the right one: how much project context should you even give an AI tool, when the files holding that context are manual and quickly outdated? The honest answer is that the format is the problem. Pasting and re-pasting context into per-tool files was never going to scale, because it puts the maintenance burden on the human and the maintenance never gets done.

Chat history is memory too, and it keeps moving

The same fragility shows up in conversation history. People lose track of where their Cursor chat history went after an update relocated it, or watch long sessions bloat with irrelevant history and then truncate at the worst possible moment. The record of what you and the agent worked out together is also project memory, and it is just as unstable — scattered across tools, silently moved, quietly dropped when a context window fills.

A project's memory should not be this brittle. The decisions, the rules, the history of what was tried — these are exactly the things that should persist reliably, and instead they live in hand-edited files and ephemeral chat logs that drift, move, and vanish.

Durable beats manual

The fix is not more disciplined file maintenance; it is removing the manual maintenance from the loop. A durable, source-linked context layer — one that holds the project's rules and decisions and history in a place that survives tool changes and does not depend on someone remembering to update a markdown file — is what keeps project memory from rotting. The goal is a single source of truth the tools draw from, instead of N hand-kept copies that each go stale on their own schedule.

Until that exists, the context files will keep doing what they do now: looking authoritative, reading confidently, and quietly describing a project that no longer exists.