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:
- Calls
LSP.touchFile() to warm up the language server
- Waits for diagnostics to settle
- 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)
- 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
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:
LSP.touchFile()to warm up the language serverThis creates a tight feedback loop: edit → see errors → fix errors → verify, without needing to run the code.
LSP Tool
Kilocode has a full
LspToolwith these operations:goToDefinition— Find where a symbol is definedfindReferences— Find all usages of a symbolhover— Get type information and documentationdocumentSymbol— List all symbols in a fileworkspaceSymbol— Search symbols across the projectgoToImplementation— Find interface implementationsprepareCallHierarchy— Get function call hierarchyincomingCalls/outgoingCalls— Navigate call graphCurrent Hermes Approach
After
patchorwrite_file, Hermes runs basic syntax checks:This catches syntax errors but not:
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:
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_inteltool using tree-sitter for language-agnostic operations: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:
Pros & Cons
Pros
Cons
References
tools/file_operations.py— Current syntax check integration