AI coding tools can write code incredibly fast now.
But there’s a problem I keep running into: project context doesn't seem to persist very well.
...
For further actions, you may consider blocking this person and/or reporting abuse
Project context is becoming the real moat in AI coding. The model can write fast, but it needs durable memory of decisions, constraints, naming, user promises, and why the weird parts of the system exist. Without that, speed just creates faster drift.
Exactly. The “faster drift” part is what I find interesting.
Once a project has accumulated enough decisions and constraints, losing that context doesn't just make the AI less useful — it can gradually push the codebase away from decisions the team already made.
I'm curious whether you've found any approach that actually preserves the why behind those decisions, rather than just the rules themselves.
That is the right concern. I would treat context drift as a product failure mode, not just a model limitation. Once the assistant starts violating older decisions, the team needs a way to tell whether the problem was missing retrieval, stale memory, or an instruction that was never captured clearly enough.
Yeah, I like framing context drift as a product failure mode rather than only a model limitation. The three failure points you mentioned also seem useful because they make the problem more diagnosable.
Especially the distinction between “the context existed but wasn't retrieved” and “the context was never captured in the first place.” Those feel like very different problems, even though the developer might experience both as “the AI forgot.”
I’m curious whether you think developers should be able to see that distinction directly when something goes wrong, or whether that level of visibility would add too much complexity to the workflow.
Yes, that distinction is useful because each failure needs a different fix. Missing context is an indexing/retrieval problem. Compressed context is a summarization problem. Misapplied context is closer to a decision-policy problem. Treating all three as one generic memory issue makes the system much harder to improve.
Exactly. I think that separation is what makes “memory” such a misleading umbrella term. The user sees the same symptom — “the AI forgot” — but the underlying failure can be completely different. Being able to diagnose which layer failed seems just as important as improving the memory itself.
So I built a system to handle exactly that, into V.E.L.O.C.I.T.Y. IDE, it uses a merkle root SiteMap, that stores the transactional states of the codebase in realtime, so it handles concurrency better, by initiating discourse immediately when 2 agents affect the same code, so they can discuss why and how to resolve it, all of which is recorded to the merkle root, to make sure that whenever you, or an agent look at any part of code, you can see the exact reasons it's the way it is, when did it change and what commit did it change. Essentially functioning like Git, but with agent context and live, instead of diff merge based. Idea being you can have 1000+ agents operate simultaneously and the more widely used a single resource is, the larger the comity who decides what approach needs to be taken so everyone can adjust accordingly. It also syncs into the codebase's wikis that stay updated (got the idea from Qoder's wiki generator and knowledge cards), so at any given time, an agent has the best context:token ratio for their task. It also acts as a great way to isolate runners, so they keep their code clean and tested, without stepping on toes and stay within their designated areas.
That’s a really interesting approach. I especially like the idea of recording the “why” alongside the code changes rather than relying on the current code to explain itself.
One thing I’d be curious about is how you handle stale or conflicting context. If an older decision is recorded in the history but a newer change intentionally invalidates it, how does the agent know which reasoning is authoritative?
That feels like one of the harder parts of persistent project context to get right.
Merkle root, so it's timestamped. What's newer, is always right, because what's newer was written in context of the past. That's why it's a live VC system, not git'ish where it's commit based, it's literally handled at agent write time
I've mostly relied on a CLAUDE.md / repo-level instructions file, and it works well for the first few weeks — but it degrades as the project grows. The file either stays too high-level to be useful for specific decisions, or it becomes a dumping ground that's too long for the model to actually weight properly.
What's helped more than a single static file: keeping decision context close to the code it affects (a comment or small doc next to the relevant module explaining why, not just what) rather than centralizing everything in one instructions file. The AI picks it up naturally when it's working in that area, instead of relying on it to remember a 500-line context doc from the start of the session.
Curious if anyone's found a good middle ground between "one instructions file" and "context scattered everywhere" — feels like there should be something better than both extremes.
Yeah, I think that middle ground is the interesting part. A single file doesn't scale, but scattered context is hard for agents to discover. Ideally, project decisions stay structured and connected to the code they affect, while still being discoverable when needed.
I’ve ended up treating repo instructions as an index, not memory itself. AGENTS or CLAUDE files are useful for stable constraints and “don’t touch this” rules, but the fragile part is keeping decisions fresh enough that the model doesn’t obey a stale note with confidence. The best setup I’ve seen keeps short durable rules in the repo, links to ADRs or issue threads for the why, and asks the agent to cite what it relied on before changing code. It is slower, but it leaves a receipt.
This is a really interesting distinction — treating repo instructions as an index rather than memory.
The stale-note problem is probably the part I keep coming back to. A rule can be technically correct when it's written, but become misleading as the project evolves.
I also like the idea of asking the agent to cite what it relied on. It makes the reasoning traceable instead of just asking us to trust the output.
Have you found a good way to keep those durable rules and ADRs updated as the project changes, or is that still mostly a manual process?