u/FightingBear11

▲ 2 r/cursor

How are we dealing with docs/context for codebases

What is the solution everyone’s using for context management for their codebases ? Is it literally just creating a chat and telling it to create and fill a docs folder with context on the existing codebase. And then just telling whatever agent you’re using to develop to document all changes at the end of each session?

Have been doing this for a bit and it constantly seems to fall apart and the docs folder becomes useless and agents are just constantly indexing the codebases instead anyways. Gotten to the point where I’m at 30-40% context immediately just getting new chat loaded on context for whatever I’m doing next

reddit.com
u/FightingBear11 — 1 day ago
▲ 3 r/cursor

docs/context in cursor and vibe coding in general is pretty broken

been in this sub for a while, basically I’m someone who’s non technical that’s been building a product for the last few months that involves taking messy unstructured data from a bunch of different APIs and turns it into a single user-facing product. so a bunch of rankings, processing pipelines etc. ,there's a lot going on architecturally under the surface.

I knew from the beginning that documentation and context management is massive and probably the biggest lever you can pull in terms of reducing failure modes in dev, bugs and just generally making it easier to start a new chat and do smth in my repo. And so i do what most ppl do which is tell cursor to document everything at the end of each chat, updating architecture docs, logging decisions. I even go further and every couple weeks open a fresh agent to go through the whole docs folder and clean up stale stuff. and despite all that it just keeps devolving into 50+ files of stuff that's mostly useless. old session notes, checkpoint logs from weeks ago, architecture descriptions that don't match the current codebase. Its all fairly actively maintained and it still degrades almost instantly. 

the core issue I've realized is the execution agent doing the coding literally cannot be the thing that maintains your documentation. it's not in its prerogative to look at the doc structure from a meta level. it just appends or writes new files. it doesn't ask "is this still useful, is this stale, does this structure even make sense anymore." so you end up with this massive docs folder that's technically comprehensive but practically useless.

and I eventually realized I'm burning like 40% of my context window every session just bootstrapping. and I've noticed cursor often just reads raw code files anyway bc the docs are stale. the real irony is if you had a correct living bootstrap of your project it would make all the indexing and searching 10x more effective bc the agent already knows where things are. instead it's brute-forcing from scratch every time.

The thing that acc made me think abt all this is when I architected my openclaw agent (which I basically set up with a multi layer memory system itself, every session is indexed by sonnet into a session synthesis, added to a 5d and 30d timeline, and categorized into a category based overview doc (so one for my startup, one for school etc.). And the memory system works by breaking these into layers, timelines at the top so they are fetched first, then category docs, than specific synthesis from sessions referenced in those docs or artefacts created regarding an analysis or research that was done, then the raw transcripts, then a full semantically indexed database of all my chatgpt chats from the last 9 months .

The agent only retrieves context from the next layer if the context from the one above isn't sufficient for the request and it works beautifully. and the thing i immediately thought was how have i created a more effective context management system than what exists for my literal codebase.

Did research online, everything is either built for enterprises and is way too pro/team focused, and what exists at the consumer level for ai-assisted builders is largely around memory management and remembering what happened in the last chat, but why would you need that if you’re working in a codebase/project that has a coherent docs structure and is consistently and faithfully updated so that memory is filed in the right place. Basically saying ppl arent just using cursor for random shit, they’re working in the context of an app or project they’re building, why are we building memory before project-level context that actually solves the problem of whats being built, what was done last, rather than just what was just done in the last chat in isolation. 

so I've started building it myself cus why not. separate agent that i invoke at the end of each cursor session, looks at the chat transcript + git diffs and properly adds it to the doc structure its created and maintains because it’s actually able to hold those changes as an input and hold it in one hand and the whole project context in the other and understand where this acc goes in the docs and why and what needs to be changed. I also realized that I'm using an agent to design the structure of my docs folder anyways so why not fold that into it as well, so it not only correctly files the content of what has been done into the right place in the docs structure but asks as the codebase grows, is the docs structure itself correct for this project or should it be tweaked at a meta level.

I’m tryna figure out if im just being stupid and there’s a better way to do project level context management or if i should keep building my system bc its working pretty well tbh, at least so far lol

reddit.com
u/FightingBear11 — 2 days ago