Author here. I've been building CV-Git for the past year — it models codebases as knowledge graphs (FalkorDB + Qdrant) instead of bolting metadata onto Git commits. Entire's $60M raise last week validated the market, but I think their architecture (capturing prompts alongside commits) fundamentally misses the point. The relationships between code entities: calls, dependencies, causal chains; are where the real understanding lives, and you can't capture those in prompt logs. The blog post walks through five specific queries that are trivial on a knowledge graph and impossible on text search over conversation transcripts: impact analysis, multi-agent conflict detection, design decision archaeology, safety boundary detection, and causal tracing. The empirical results are honest: graph-augmented retrieval helps high-coupling systems (+4.1% dependency coverage) but actually hurts utility libraries (-5.2%). It's not universally better, it's better when the code has structural complexity worth modeling. CV-Git is open source (MIT): https://github.com/controlVector/cv-git Happy to answer questions about the architecture, the tradeoffs, or why I think the "adapter vs. native architecture" pattern applies here.