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

Curious about the hexagonal piece specifically — once you hit the 30-min mark and the AI starts dumping logic in controllers, what breaks first for you: the rule itself (no business logic outside use cases) or the module boundaries? Wondering if a layer map in CLAUDE.md is enough or if you need linters in CI to keep the AI honest.

This pain is pretty universal. The part that matters is deciding which rules are memory and which rules are enforcement.

I would keep the context file small: architecture shape, closed decisions, naming conventions, and the current work slice. But for anything that would hurt if the model forgets, make the repo catch it. Layer boundary lint rules, tests that fail if DB access skips the repository, tenant isolation tests, CI checks for server-only env vars in client code, and a short security regression checklist before deploy.

Then a stale Claude session is annoying, but it is less dangerous. The model can forget the rule, hit a red build, and get pulled back into the architecture by the codebase itself.

A dedicated architecture context file has been the biggest unlock for me. I put the architecture decisions, the reasoning behind non-obvious choices, naming conventions, and key file paths in there. Claude reads it at session start and drift drops dramatically.

Also keeping a separate decisions log where I note every non-obvious choice. When Claude starts going sideways I paste the relevant entries in context and it self-corrects.

Still fighting the multi-session problem though — running 6-8 Claude sessions simultaneously means each has its own context window and they can diverge on the same codebase. Haven't fully solved that one.

This is real, but I think the fix is less “make the chat remember” and more “stop treating the chat as memory.” I’ve had better luck with a tiny root file the assistant must read every session: architecture rules, current focus, closed decisions. The closed-decisions bit matters. Otherwise the model keeps reopening the same raw SQL / thin controller / test coverage debates.

I think it's a good thing to build on top of existing coding models. A cron job that pushes the model to restore context from the ARCHITECRTUREmd or maybe analyze the diff.

I NEED A TRUSTED CRYPTO HACKER THAT CAN RESTORE LOST OR SCAMMED FUNDS.

Are you struggling to get back the money you lost? Every day, countless individuals face the devastating impact of scam operations that drain their hard-earned savings. But there’s good news – GEO COORDINATES RECOVERY HACKER are here to help you recover what’s rightfully yours. I lost my entire savings to a fake crypto investment scam while I was looking for a way to double my savings. After many weeks of trying to find a way to get my money back with no success, I finally came across a crypto recovery company GEO COORDINATES RECOVERY HACKER, a reliable and trustworthy crypto recovery company. I'm immensely grateful for his dedication, professionalism, and unwavering support. You can get in touch with them through below contact details

WhatsApp ; +1 ( 318 ) 203-3657

I had to send out my review also. They are indeed recommendable.

can't fully prevent it - sessions are stateless by design. what works is a persistent spec file that's included at every session start. I call mine constraints.md - keeps conventions in-window without relying on the model to remember.

The markdown source-of-truth approach is right, and I would add one layer to it: the constraints that actually survive are the ones the AI cannot ignore, not the ones it is asked to remember. A rule in a doc is a suggestion. The same rule as a lint error, a type boundary, or a failing test is enforced whether or not the model read the file that session. We learned this building our SaaS. Every architectural decision we cared about got encoded as a test or a lint rule, so a model that forgets it gets a red build and fixes it in the same loop. The other thing that helps more than people expect is smaller modules with hard boundaries. AI loses the plot in big tangled files because it has to hold too much at once. If each piece is small and the seams are explicit, you can hand it one slice and it stays on the rails. Treat context as infrastructure like you said, but make your tests and types the part of that infrastructure the model is forced to obey.

Mechanically, "context rot" is attention dilution: as a session grows, your early architecture rules become a tiny fraction of the tokens and get statistically drowned out by recent code. Re-pasting the full README fights volume with more volume, which is why it burns budget without sticking.

What's worked on my small iOS side project: a 15-line conventions file — not the whole README — re-fed at the start of each scoped session, plus keeping sessions narrow and starting a fresh chat per module. Treating that file as the source of truth and the chat as disposable killed the drift far better than longer prompts ever did.

I solved it forcing the AI to generate a wiki and tech docs of my projects. And then have a small README that tells the model "whay he can find in docs" just tables with simple links to docs.

I works like a charm and the AI starts to investigate before moving .

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.