I’m a backend engineer working on a mature SaaS product with multiple services, shared dependencies, and years of accumulated architectural decisions.
My biggest issue with Codex is not code generation, but context loss. Every new session spends time rediscovering the architecture, important files, dependencies, and previous technical decisions.
I currently use AGENTS.md to document project conventions and important instructions. It helps, but it does not capture everything Codex learns while completing previous tasks, and it can become outdated as the project changes.
For developers using Codex on large production codebases:
- What information do you keep in AGENTS.md?
- How do you preserve knowledge learned during previous tasks?
- Do you use session summaries, Skills, MCP, RAG, code graphs, or another approach?
- How do you prevent outdated context from misleading Codex?
I’m especially interested in workflows that have been used for several months on mature projects.
What does your actual setup look like, and what approaches did not work for you?
What I found is that splitting up the application into an immutable core with modules and a shared db works pretty well.
This way the model doesn’t need to see all the modules .. just the small core + db + maybe ui core and the module you work on and maybe also connected modules .. but it reduces the effective code for the context it needs by alot.
on the other hand what you can do is using an AST parser like treesitter and write an AST into for example neo4j and then use a vectordb to find the community in the graph .. then use a script that cuts the flesh from the code skeleton because interface or doc blocks with params and return values are often enough to understand most of the code…
I mean there are tools out there for that. I think context7 is one .. but I don’t use them.. I build stuff by myself and for the immutable core + modules way you don’t really need it (it could save token I suppose)
That makes sense. In our case, we already use microservices with separate databases, so the code and data boundaries are relatively clear. The harder part is cross-service changes, where the model needs to understand API contracts, events, data flow, and the dependencies between several services.
I like your distinction between reducing context through architecture and dynamically selecting context through AST or graph-based retrieval. For changes that span multiple services, do you think service boundaries and interface definitions are usually enough, or is that where a code graph becomes genuinely useful?
What is your stack if I may ask?
Sure. We mainly use .NET in a microservices architecture. Each service has its own database, and the services communicate primarily through gRPC.
That’s why cross-service context is more difficult for us than understanding a single service.