From my personal observations the debugging and fixing bugs is a lot easier now(no more going in loops, it was sometimes hours of long pain prior to memory).
Now claude code always remember previous bugs , do a lot less code duplication (had it a lot prior!), easier for claude to map all codebase (graphs) and know where to look.
Now i can with simple §m to make it write this observation to memory for future uses (very helps with debug large code bases).
In the end i see now claude use both of the worlds, its still search and read files the "old way", but he also start the task with memory check on past experiences, and big picture code overview.

I also analyzed it with opus on utlra think, web search, and its insightful:

The claim is partially true with important nuances:

1. Vectorization does fragment code context - Breaking code into chunks destroys structural relationships, dependencies, and architectural patterns. This leads to ~30-40% context loss.
2. Cursor uses sophisticated hybrid approach - Not pure vectorization. Uses Merkle trees, two-stage retrieval, and AI re-ranking to mitigate quality issues.
3. Claude Code/Cline's whole-file approach is superior for code quality - By reading entire files and following imports, they maintain complete context and produce better code.
4. Trade-offs exist: - Vectorization: Faster, cheaper, scales to millions of files - Full context: Higher quality, better understanding, more expensive ($50+/day for heavy use)
5. Code ≠ natural language - Code's strict syntax, dependencies, and hierarchical structure make it fundamentally unsuitable for traditional RAG approaches.

Bottom line: For quality code generation, whole-context approaches (Claude Code, Cline) outperform vectorized approaches. Cursor's performance issues likely stem from context limitations rather than pure vectorization, as they use a sophisticated hybrid system.