Skip to content
GRPNR.

Codebase Knowledge Graph + Declarative Rewrite Engines

Codebase Knowledge Graph & Indexing App

Problem: agents exploring via raw text search + recursive file reads burn hundreds of thousands of tokens per session and strain context windows.

Solution: treat code structure as a queryable relational database exposed via MCP.

  • Tree-sitter parsers across all active languages → definitions of classes, methods, interface types, import paths, call sites.
  • Processed in memory with LZ4 compression → persistent local SQLite DB.
  • Cross-service linking: parse OpenAPI route definitions, gRPC protobufs, message-queue pub/sub channels (Kafka, RabbitMQ) across repos → map implicit network dependencies.
  • Blast-radius evaluation: agent queries DB via MCP tools instead of reading files. Caller hierarchies + cross-repo service call tracing in sub-millisecond queries.
  • Token economics: ~3,400 tokens/session vs ~412,000 with linear text search (~120× reduction).
  • Core-logic phase adds: SSA (Static Single Assignment) analysis, SQL AST parsing, DataDog monitoring APIs for dependency tracing → produces prioritized extraction order.

Declarative Code Rewrite App

Problem: processing 65M LOC of predictable boilerplate through generative LLMs = high inference cost + formatting inconsistencies.

Solution: replace probabilistic generation with deterministic, syntax-aware structural updates.

  • GritQL (AST-aware declarative language) finds/rewrites patterns across millions of LOC. Operates on syntax tree, not text — formatting variation, line breaks, comment placement don’t break matching.
  • Offline synthesis pipeline: high-capability LLM analyzes a small set of representative migration examples → compiles them into structured reusable transformation rules (“spell synthesis”).
  • Generated rules validated with local test frameworks to filter incorrect patterns BEFORE codebase-wide application.
  • Sweet spot: repetitive large-scale migrations — obsolete logging frameworks, standardized API parameter renames, sync→async DB transaction conversion.
  • Result: boilerplate migration at zero marginal token cost (LLM used once offline to synthesize rules, not per-file).

Why this matters vs batch-1 research

Batch 1 (docs 00–05) treated all edits as agent-executed. This batch splits the estate: 65M LOC boilerplate → deterministic AST rewrites (no LLM per-edit), 5M LOC core logic → guided agents. That split is the single biggest cost + safety lever — it removes ~93% of the estate from LLM token spend entirely.