How do you prevent AI coding assistants from forgetting your architecture?

One thing I’d add: measure when context rot starts, not just how to reset it. I’ve found the failure point is usually visible before the code gets bad: bigger prompts, repeated architecture reminders, more “why did it do that?” diffs, and a token/cost spike in the same session.

My current loop is: keep ARCHITECTURE.md short, restart when the session starts re-litigating closed rules, and track token spend per coding session so I know when I’m paying to recover lost context instead of shipping. I’m building TokenBar around that exact visibility for Mac users: https://tokenbar.site/

Not just you — this is real, and I've been fighting it for months on my own side project (Anthilia, a subscription tracker built in React Native + Expo + Supabase).

I call it the same thing internally, but what fixed it for me was treating context as infrastructure, not conversation.

Here's what actually worked:

Three source-of-truth Markdown files in the project root, updated every session:

• AGENTS — who does what (Frontend, Backend, QA, etc.), their constraints, their lanes
• PROJECT_CONTEXT — stack, architecture decisions, patterns, what's off-limits and why
• STATUS — current build state, open issues, what's been decided and closed

Claude Code starts every session by reading these. Not a README. Not a prompt. Structured files it can parse and reference.

The key insight: decisions are formally recorded and marked closed. If I decided "no raw SQL outside repositories," that's in PROJECT_CONTEXT with a note saying it's non-reopenable. The AI can't "forget" what it reads at session start — the rot only happens when context lives in the chat thread, not in files.

The second thing that helped: separating orchestration from execution. I use Claude for decisions and architecture (the Orchestrator), Claude Code for implementation. The Orchestrator never writes code. The implementation agents never make architectural calls. When a session ends, the files get updated before I close anything.

It's more overhead upfront, but it eliminated the re-explaining loop almost entirely. The token budget now goes toward actual work, not recovering lost context.

The underlying problem you're describing is that most people treat AI sessions like a conversation when they should treat them like a stateless function — give it everything it needs on every call, externalize the state.

context rot is a universal nightmare lol. claudes attention layer just completely degrades once the conversation payload gets too heavy with actual code blocks.

the fix is hardcoding your constraints at the system prompt layer using workspace rule files rather than pasting them into a live chat. pasting your readme in a dynamic thread means it’s destined to get pushed out of the window eventually. forcing it via root-level project rules saves a massive amount of token budget and keeps the repository boundaries rock solid.

The pattern that worked for me on a long-running project: ARCHITECTURE at the repo root, ~50 lines max, that the AI re-reads at the start of each session. Headers like "Conventions / Database access / Error handling / Testing rules" with one-liner rules each.

Plus a CURRENT-FOCUS (5 lines) that you update at the start of each chat with what you're actually working on right now. That doesn't drift like the architecture file does.

The killer move is having the AI verify it understood by paraphrasing both files back at the start of every session before any code changes. Adds 30 seconds, kills 80% of the drift you're describing.

The "context rot" name is good. Stealing it.

This is real, especially on larger codebases.

What helps is making the architecture impossible to “casually bypass”:

• document the core rules in a short architecture file
• keep controllers thin by convention and tests
• put DB access behind interfaces that are easy to reuse
• make edge-case tests part of the definition of done
• keep each change narrow enough to review properly

The biggest thing is not relying on memory. If the project structure does not constantly pull contributors back into the right pattern, they will drift.

A short ARCHITECTURE.md that the model re-reads at the start of each session has saved me the most pain — way more reliable than trusting it to "remember." I also keep a one-line "current goal" pinned at the top so it doesn't drift. Killed most of my "wait, why did it rewrite that" moments.

This is definitely real. The pain is not just that the model “forgets context,” it is that project rules slowly stop being treated as hard constraints. Architecture, repository boundaries, error patterns, testing rules, naming conventions — once those drift, the AI goes from speeding you up to quietly creating cleanup work.

The sharper product angle here might be “architecture memory for AI coding,” not just better prompting. Something that keeps the important project rules persistent, enforced, and visible across sessions would be much more valuable than re-pasting READMEs into every new chat.

I’d also think about the naming/category frame early if you turn this into a product. “Context rot” is a great pain description, but the bigger category is closer to AI dev workflow control or project memory infrastructure.

Xevoa .com would fit that direction well because it feels broad enough for coding workflows, persistent project context, rules, architecture memory, and AI-assisted development without boxing it into one narrow bug or prompt problem.