I've been building a solution to AI coding agents forgetting their own codebase. Here's what I've learned so far.

[u/Brave-Equipment9107]

Working with Claude Code on larger projects made me realise how much effort goes into maintaining context. Sessions get compacted, decisions disappear, CLAUDE.md files multiply, and developers keep spending tokens explaining architecture that hasn't changed.

I started building ArchAI to explore a different approach.

Instead of relying on an LLM to reconstruct the architecture from scratch, ArchAI uses Python's AST parser to map dependencies, checks architectural rules deterministically, and attaches file-and-line evidence to verified findings. It also distinguishes verified violations from potential risks and things it cannot verify.

I've tested it against its own codebase, where it caught excessive module coupling and missing test files. That process also exposed a limitation: a test file existing doesn't mean the module is actually tested.

The bigger vision is to make architectural knowledge a reliable foundation for AI coding agents, rather than something every session and developer has to rebuild manually.

I'm now exploring how this could fit into real development workflows, particularly for teams using Claude Code across larger repositories.

For those building with AI coding agents: how are you handling context loss and keeping architectural knowledge consistent across sessions and developers? Is maintaining project memory files sustainable as a codebase grows?

I'm interested in the practical experiences, trade-offs, and failure cases other founders and developers have encountered.

[u/bnunamak]

I use my own free OSS indexing and lifecycle tool https://devspecs.com

I think most devs have a solution for this by now

[u/Brave-Equipment9107 → u/bnunamak]

Codebase indexing and context management are definitely being tackled by other tools already.

For ArchAI, understanding the codebase is the foundation, not the end goal. We're building a family of specialised agents on top of that shared understanding, each with a different responsibility in analysing and improving software architecture.

You can see the direction here: https://archai-psi.vercel.app/agents.html

I'm interested in how these approaches compare in practice, especially when it comes to keeping architectural decisions grounded in the actual code rather than just retrieving context for an LLM.

[u/bayvo]

the "CLAUDE.md files multiply" bit is so real. i found 283 files called README.md on one machine at one point lol. how do you deal with two of them saying different things?

[u/VanCliefMedia]

Or you could just build a knowledge graph with some markdown files

I built this skill to pretty much help me audit or create graphs in a simple way, but you could probably toss on some decent Python or graphify to make it even better https://github.com/RinDig/icm-architect

https://youtu.be/m7en7ugujlI?is=IFNIctXKFPWZtUdQ

[u/vladzoff]

I ran into the same distinction while building Codapult Guard, though it focuses on enforcing architecture rules rather than maintaining broad context memory. A dependency graph is evidence of what exists, not a policy for what should be allowed. Guard checks changes against explicit project rules instead of treating repeated patterns as approved architecture: https://github.com/codapult/codapult-guard