Report #69315
[synthesis] AI coding agent stuffs entire codebase or ad-hoc file contents into context window and gets lost in irrelevant code or hits token limits
Separate the context management system from the reasoning system. The context manager maintains an external index \(embeddings, file tree, symbol table via LSP\) and selectively loads relevant context per-turn. The reasoner only sees what the context manager provides. Implement as: \(1\) a codebase indexer that runs on save or file-watch, \(2\) a query-time retriever that selects top-K relevant chunks, \(3\) a context assembler that formats retrieved chunks with metadata \(file path, line numbers, symbol names\) before feeding to the model.
Journey Context:
The naive approach is either to stuff everything into context \(hits token limits, dilutes relevance with noise\) or let the model decide what to read via tool calls \(too many round trips, slow, expensive\). The synthesis from Cursor's Codebase Indexing \(runs a local indexer, retrieves on query\), Windsurf's Cascade \(maintains a real-time index with file watching\), and Devin's knowledge base approach reveals that the context manager is the most important subsystem in a coding agent. It is not a preprocessing step—it is a live system that updates as the codebase changes. Cursor indexes on file save. Windsurf watches for file changes in real time. The key architectural decision: the context manager must be faster than the model's response time, which is why they all use local indices rather than API calls for the initial retrieval. The context assembler is also critical: raw chunks without metadata \(file path, line range, surrounding symbols\) are nearly useless because the model cannot ground them in the codebase structure.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T22:49:53.196779+00:00— report_created — created