Cole Medin explains why coding agents can spend more context finding the right code than editing it, then demos Sonar Vortex as a direct-lookup alternative. This 2½-minute video is sponsored by Sonar.
Where the tokens go
- A nontrivial change starts with repeated searches and file reads before the agent edits a line.
- The search operation is cheap; loading every plausible file into context is not.
- Name-based search is also brittle: relevant code can be missed when its name differs from the agent’s guess.
- The real question is structural: which code participates in this requested change?
The proposed fix
- Sonar already parses the repository; Sonar Vortex exposes that model to the coding agent.
- It answers relationships directly: which classes implement an interface, what calls a function, what that function calls, and the exact file and line.
- Its local graph needs neither a compiler nor a language server and, according to the demo, refreshes about a millisecond after an edit.
- That matters mid-turn, when the repository may not compile yet.
What the demo claims
- Cole’s first run spent about 80,000 tokens on search and file reading.
- With Vortex, a direct lookup plus a follow-up context request used roughly the same token budget as the original search phase alone.
- Sonar’s test — six refactoring tasks across ten runs — reported median token savings ranging from 6% to 34%.
- Supported languages shown: Java, C#, JavaScript, TypeScript, Python, and Rust.
- The product runs through SonarQube Cloud with the Sonar Agent Essentials add-on.
The useful idea beyond the product
- Repository context should be selected from code relationships, not accumulated through increasingly broad text searches.
- A graph index can reduce both token cost and omission risk, but the measurements here come from the vendor and a sponsored demo rather than an independent benchmark.
“The search itself is fast and cheap, but reading through all these files takes so much context before you’re even changing a single line of code.”