Usage clarification: What's the benefit of CRG when for an AI Agent that already uses LSP

[robert-zaremba]

Most of the AI CLI coding Agents has LSP integrations. For example, OpenCode has builtin LSP integrations and tree-sitter integration.
For a project that has builtin LSP support in OpenCode, what's the benefit of adding CRG to OpenCode? Isn't it an overhead?

[robert-zaremba]

I've asked chatgpt about it:

Desn't LSP already solve the "addition: code-review-graph" ?

That's the key question, and my answer is: partially, but not completely.
A modern LSP already solves much more than many people realize.
For example, TypeScript's language server can provide:

• Definition graph
• Reference graph
• Call hierarchy
• Type hierarchy
• Workspace symbols
• Incoming calls
• Outgoing calls
• Diagnostics
• Dependency information (indirectly)

For a TypeScript codebase, that's already enough to answer:

"What calls this function?"
"Where is this interface used?"
"What implementations exist?"

which are core graph operations.

Where LSP is actually very strong

Suppose the agent changes:

function authenticate(token: string)

An LSP can immediately find:

• all references
• all callers
• all overrides
• all implementations

In many cases, that's effectively a blast-radius analysis.
For TypeScript specifically, I'd argue LSP is the authoritative source.

Where graph systems go beyond LSP

The difference is usually aggregation and workflow.
LSP gives primitives:

findReferences()
incomingCalls()
outgoingCalls()

Graph systems often provide:

affectedFiles(change)
relatedTests(change)
architecturalNeighbors(change)
criticalPath(change)
subsystemBoundary(change)

Those are derived analyses built on top of lower-level relationships.

Example

Imagine you modify:

src/auth/token.ts

LSP can tell you:

token.ts
  -> called by session.ts
  -> called by middleware.ts

Graph layer might tell you:

Impact:
- 14 files affected
- 3 packages affected
- 7 tests likely relevant
- touches Authentication subsystem
- reaches Billing API through SessionManager

The latter is not usually available directly from LSP.

For OpenCode specifically

If your OpenCode agent already exposes:

• definitions
• references
• call hierarchy
• workspace symbols

through MCP tools, then I think code-review-graph is much less important than I initially suggested. In fact, I'd revise my ranking:

Addition	Incremental value beyond TS LSP
Semantic index (LanceDB)	High
code-review-graph	Medium
CodeRLM	Low

The reason is simple: LSP already knows named relationships. What it does not know is semantic intent. A user asks:

"Where is rate limiting implemented?"

There may be no symbol named rateLimit. LSP struggles. Semantic retrieval excels.

[Huaian666]

read through the source code over the weekend. some genuinely clever solutions in there. the kind of code you learn from.

[robert-zaremba]

@Huaian666 There is a lot of code there: https://github.com/tirth8205/code-review-graph/tree/main/code_review_graph
Probably it will be easier to ask AI to analyze it :D

For OpenCode there is also https://github.com/Helweg/opencode-codebase-index/