Deep repo knowledge for an on-site agent — without a vector database
For two dozen repos, pre-written docs beat embeddings: index once into a handful of LLM-authored documents (architecture, stack, per-module dives), then let the agent read titles and fetch whole docs on demand.
The default answer to 'make the assistant know my code' is RAG: chunk the repo, embed the chunks, retrieve top-k at question time. For a portfolio assistant covering ~24 repos, that stack is mostly overhead — embedding infra, chunk-boundary artifacts, and retrieved fragments that lack the context to answer architectural questions anyway.
The alternative that shipped: at index time, an LLM reads the repo's README, manifests, file tree and sampled sources, and writes a small set of named documents — an architecture overview, a tech-stack digest, and a deep-dive per major module. The agent's retrieval tool is then just get_doc(title): it sees the table of contents and requests whole documents.
This inverts where the intelligence sits. RAG puts it at query time (find relevant fragments); this puts it at index time (write coherent documents once). For codebases, coherence wins: 'how does the scheduler work' is answered by a document about the scheduler, not by seven 400-token fragments that mention it.
The failure mode is staleness — docs describe the repo as of indexing. For a portfolio that's fine (projects are milestones, not moving targets); for active development it would need re-index triggers on push. The other cost is honesty: the indexing prompt has to demand evidence-based writing, because a summarizing LLM will otherwise happily describe the architecture the README promises rather than the one the file tree shows.
Where this stops scaling: hundreds of repos or monorepos too large to sample meaningfully. At that point chunked retrieval earns its complexity back — but the doc layer is still worth keeping as the first hop.