How Egonex-AI Uses Tree-sitter and LLMs for Code Analysis: Architecture Deep Dive

Egonex-AI's Understand-Anything platform fuses Tree-sitter's incremental concrete syntax tree parsing with LLM-based semantic enrichment to generate interactive, human-readable knowledge graphs from any codebase.

The Egonex-AI Understand-Anything repository demonstrates a production-grade implementation of hybrid code analysis, leveraging the speed and precision of Tree-sitter alongside the reasoning capabilities of large language models. This architecture extracts structural metadata through deterministic parsing while using AI to infer intent, design patterns, and cross-file relationships that pure syntactic analysis cannot capture.

Three-Stage Architecture for Tree-sitter and LLM Integration

The platform processes source code through a rigidly defined pipeline that separates syntactic extraction from semantic interpretation.

Stage 1: Tree-sitter Parsing via WebAssembly

The analysis begins in packages/core/src/plugins/tree-sitter-plugin.ts, where the Tree-sitter plugin invokes the WebAssembly build of Tree-sitter (web-tree-sitter). This component parses each source file into a language-specific concrete syntax tree (CST) with guaranteed syntactic fidelity.

The parser supports incremental re-parsing, meaning only changed fragments are processed when files update. Language grammars are registered dynamically through packages/core/src/languages/language-registry.ts, enabling support for JavaScript, TypeScript, Python, Java, Kotlin, and other languages without modifying core logic.

Stage 2: Knowledge Graph Construction

Once parsed, the CST is walked by packages/core/src/analyzer/graph-builder.ts to extract nodes, edges, and code metadata including identifiers, scopes, and import relationships.

The Graph Builder normalizes these language-specific structures into a unified schema defined in packages/core/src/types.ts. This abstraction layer ensures that downstream components remain language-agnostic, treating Python classes and JavaScript functions as equivalent node types in the knowledge graph.

Stage 3: LLM Semantic Enrichment

The partially constructed graph flows into packages/core/src/analyzer/llm-analyzer.ts, where the LLM Analyzer serializes CST fragments and graph topology into prompts. Using few-shot prompting techniques, the LLM infers higher-level concepts—such as identifying React components, security-critical entry points, or design patterns—and generates human-readable summaries.

The LLM's output is stitched back into the graph as semantic tags, summaries, and confidence scores, transforming raw syntax into actionable intelligence. The platform batches these calls and sends only changed sub-trees during incremental updates, minimizing token usage while maintaining analysis freshness.

Why Tree-sitter and LLMs Complement Each Other

This dual-approach architecture delivers specific advantages that neither technique achieves in isolation:

• Exact Syntactic Fidelity: Tree-sitter guarantees correct CST generation for every supported language, eliminating hallucinated structure that could mislead the LLM.
• Semantic Understanding: The LLM supplies intent recognition, cross-file relationship mapping, and contextual interpretation that deterministic parsers cannot provide.
• Incremental Performance: Tree-sitter's ability to re-parse only changed fragments enables real-time updates, while selective LLM prompting on modified sub-graphs controls computational costs.
• Language-Agnostic Core: The plugin registry isolates language-specific grammars, while prompt templates remain generic—the LLM interprets the normalized CST format regardless of source language.

End-to-End Data Flow Pipeline

The complete analysis lifecycle follows five sequential steps orchestrated by the core engine:

1. Discovery: plugins/discovery.ts scans the project root for files matching registered language patterns.

2. Parsing: tree-sitter-plugin.ts loads the appropriate WASM grammar, generates CSTs, and emits Tree-sitter AST events.

3. Normalization: normalize-graph.ts transforms raw ASTs into the language-neutral graph schema, resolving cross-references and scope chains.

4. LLM Enrichment: llm-analyzer.ts formats graph nodes into structured prompts, executes LLM calls, and augments each node with tags, summary, and confidence fields.

5. Persistence and Validation: The enriched graph passes through packages/core/src/schema.ts for structural validation before serialization to knowledge-graph.json, which the dashboard consumes via browser-safe sub-path exports (./search, ./types, ./schema).

Programmatic Implementation Example

The following TypeScript example demonstrates invoking the complete analysis pipeline (requires Node.js >= 22 and PNPM workspace):

import { analyzeProject } from '@understand-anything/core';

(async () => {
  // Point to the absolute repository root
  const repoRoot = '/path/to/your/project';

  // Execute full pipeline: discovery → parsing → graph building → LLM enrichment
  const graph = await analyzeProject(repoRoot, {
    llm: { model: 'gpt-4o-mini', temperature: 0.0 },
    languages: ['javascript', 'typescript', 'java'],
  });

  // Access enriched nodes with LLM-generated metadata
  console.log('First node summary:', graph.nodes[0].summary);

  // Persist for dashboard consumption
  await writeFile(
    `${repoRoot}/.understand-anything/knowledge-graph.json`,
    JSON.stringify(graph, null, 2)
  );
})();

To visualize results, build the core package and launch the dashboard:

pnpm --filter @understand-anything/core build
pnpm --filter @understand-anything/dashboard dev

The dashboard reads the validated knowledge-graph.json and renders an interactive interface where each node displays LLM-generated explanations, enabling features like automated code tours and diff explanations.

Summary

• Tree-sitter provides the foundation: The tree-sitter-plugin.ts implementation delivers fast, incremental CST parsing across multiple languages via WebAssembly.
• LLMs add semantic layer: The llm-analyzer.ts component enriches structural graphs with human-readable summaries, tags, and inferred relationships using few-shot prompting.
• Graph-builder bridges both worlds: graph-builder.ts normalizes language-specific CSTs into a unified schema that the LLM can process generically.
• Architecture prioritizes performance: Incremental parsing and selective LLM prompting on changed sub-trees enable real-time analysis of large codebases.
• Validation ensures reliability: schema.ts validates graph integrity before UI consumption, while browser-safe exports prevent heavy WASM bundles from loading in the client.

Frequently Asked Questions

What makes Tree-sitter specifically suitable for this code analysis pipeline?

Tree-sitter's incremental parsing capability allows the platform to update only modified code fragments rather than re-parsing entire files, which is essential for real-time analysis. According to the source code in tree-sitter-plugin.ts, the WebAssembly implementation provides deterministic, error-resistant parsing across dozens of languages while maintaining the speed required for interactive developer tools.

How does the LLM analyzer manage token costs when processing large repositories?

The llm-analyzer.ts implementation batches LLM calls and leverages Tree-sitter's change tracking to send only modified sub-trees for enrichment during updates. This selective prompting strategy minimizes token usage by avoiding redundant analysis of unchanged code, while the graph structure allows the LLM to process semantically relevant fragments rather than entire files.

Can developers extend the platform to support languages not included in Tree-sitter's default grammars?

Yes, the architecture supports extension through packages/core/src/languages/language-registry.ts, which registers grammars dynamically. Developers can add new Tree-sitter grammars to the registry without modifying core analysis logic, and the LLM prompts remain effective because they operate on the normalized graph schema rather than language-specific syntax.

How does the system prevent the heavyweight Tree-sitter WASM bundle from impacting dashboard performance?

The dashboard imports only browser-safe sub-path exports (./search, ./types, ./schema) as implemented in the package structure, ensuring the Tree-sitter WASM bundle never executes in the browser. The heavyweight parsing occurs during the backend analysis phase, with the dashboard consuming only the serialized, validated knowledge-graph.json produced by schema.ts and the persistence layer.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}