Skip to content

Feature: LSP Integration — Post-Edit Diagnostics and Code Intelligence Tools (inspired by Kilocode) #516

@teknium1

Description

@teknium1

Overview

Kilocode has deep Language Server Protocol (LSP) integration that gives the agent IDE-level code intelligence. After every file edit, LSP diagnostics are reported back in the tool result. The agent also has a dedicated LSP tool for go-to-definition, find-references, hover, and call hierarchy.

Hermes currently runs basic syntax checks after edits (py_compile, node --check, json.tool) but has no LSP integration. This means the agent can't see type errors, missing imports, or API misuse until it tries to run the code.

This is Kilocode's biggest advantage as a coding agent.


Research Findings

Post-Edit LSP Diagnostics

After every file write/edit, Kilocode:

  1. Calls LSP.touchFile() to warm up the language server
  2. Waits for diagnostics to settle
  3. Reports errors back in the tool result:
    File saved successfully.
    ⚠ 2 diagnostics:
      line 45: Expected ';' after expression (ts2304)
      line 89: Type 'string' is not assignable to 'number' (ts2322)
    
  4. Also reports diagnostics from OTHER files affected by the change (MAX_PROJECT_DIAGNOSTICS_FILES=5)

This creates a tight feedback loop: edit → see errors → fix errors → verify, without needing to run the code.

LSP Tool

Kilocode has a full LspTool with these operations:

  • goToDefinition — Find where a symbol is defined
  • findReferences — Find all usages of a symbol
  • hover — Get type information and documentation
  • documentSymbol — List all symbols in a file
  • workspaceSymbol — Search symbols across the project
  • goToImplementation — Find interface implementations
  • prepareCallHierarchy — Get function call hierarchy
  • incomingCalls / outgoingCalls — Navigate call graph

Current Hermes Approach

After patch or write_file, Hermes runs basic syntax checks:

# From file_operations.py
SYNTAX_CHECKS = {
    ".py": "python -m py_compile {file}",
    ".js": "node --check {file}",
    ".ts": "node --check {file}",
    ".json": "python -m json.tool {file}",
}

This catches syntax errors but not:

  • Type errors
  • Missing imports
  • API misuse / wrong signatures
  • Undefined variables
  • Unused imports
  • Cross-file dependency issues

Implementation Plan

Classification

This is a core codebase change (new tool + integration into existing edit tools). The LSP tool should be a new tool because it requires persistent server process management, binary protocol handling, and real-time event processing that can't go through the terminal.

Phased Rollout

Phase 1: Post-edit diagnostics via language server CLI tools

Instead of full LSP integration, use CLI-based diagnostic tools:

DIAGNOSTIC_COMMANDS = {
    ".py": "python -m pyflakes {file} 2>&1; python -m mypy --no-error-summary {file} 2>&1",
    ".ts": "npx tsc --noEmit {file} 2>&1",
    ".js": "npx eslint {file} 2>&1",
    ".rs": "cargo check --message-format=short 2>&1",
    ".go": "go vet {file} 2>&1",
}

Append diagnostic output to file edit tool results. This gives 80% of the value with 10% of the effort.

Phase 2: Code intelligence via tree-sitter

Add a code_intel tool using tree-sitter for language-agnostic operations:

  • Find symbol definition (tree-sitter query)
  • Find references (grep + tree-sitter validation)
  • List symbols in file (tree-sitter parse)

Tree-sitter is fast, doesn't require running a language server, and works for any language with a grammar.

Phase 3: Full LSP integration

Persistent language server processes with JSON-RPC:

  • TypeScript (tsserver), Python (pylsp/pyright), Rust (rust-analyzer)
  • Server lifecycle management, warm file tracking
  • Full LSP tool with all operations
  • Cross-file diagnostics

Pros & Cons

Pros

  • Dramatically reduces edit→test→fix cycles — agent sees errors immediately
  • Go-to-definition and find-references eliminate costly full-file reads
  • Cross-file diagnostics catch dependency issues early
  • Phase 1 (CLI tools) is very low effort and high value

Cons

  • Full LSP (Phase 3) is significant complexity — server lifecycle, protocol handling
  • Language server processes consume memory and CPU
  • Not all backends support persistent processes (Docker, Modal — would need adaptation)
  • Language servers need project configuration (tsconfig.json, pyproject.toml) to work well
  • Cross-platform concerns — LSP binary availability varies

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions