How to Speed Up Code Reviews and Navigation in Large Codebases with AI: Local Code Intelligence Graph in Action
I'm Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany. At DennisCraft AI Studio, I ship agent-based AI for DACH B2B clients using Claude, Supabase, n8n, Doppler, and self-hosted Postgres. Last quarter, I had to review a logistics codebase that had grown beyond 120,000 lines, with five languages and more LLM-generated code than I'd like to admit. The pain: even with solid test coverage and code review rituals, critical changes were slipping through—especially at integ
I'm Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany. At DennisCraft AI Studio, I ship agent-based AI for DACH B2B clients using Claude, Supabase, n8n, Doppler, and self-hosted Postgres. Last quarter, I had to review a logistics codebase that had grown beyond 120,000 lines, with five languages and more LLM-generated code than I'd like to admit. The pain: even with solid test coverage and code review rituals, critical changes were slipping through—especially at integration points and dynamic code segments. Standard search and LLM code search tools were missing context, and the review cycle ballooned from hours to days.
The Reality: Code Reviews at Scale Are Broken
In any codebase over 100K lines, traditional navigation—IDEs, basic grep, or even cloud code search—start to fail. The real bottleneck isn't just finding the right file; it's understanding the impact of a change across dynamic, cross-cutting logic. In my experience, even mature engineering teams catch only about 60% of critical issues in review, with the rest surfacing as production bugs or slow-moving regressions. Cloud-based intelligence tools often break compliance, especially for regulated European clients—GDPR, BSI Grundschutz, and internal audit all raise flags if code leaves the perimeter.
Pattern: Building a Local Code Intelligence Graph
The solution that finally scaled for me: assembling a local, queryable code intelligence graph. This isn't just static analysis—it's a graph that records all function calls, environment variable uses, inter-service links, and external API invocations, built and queried entirely inside the secure perimeter. No lines of code leave the server; no SaaS vendor touches the source.
How I Build and Operate the Graph
- semgrep for syntax pattern extraction (see semgrep.dev)
- Custom Python scripts using
astandnetworkxfor AST walking and graph assembly - Postgres as the graph backend, with optimized dependency queries
- n8n for workflow automation—rebuilding the graph on every push or PR
- Claude Code (Anthropic SDK) as a semantic layer, but limited to local graph context only
import ast
import networkx as nx
import psycopg2
def build_graph_from_files(files):
g = nx.DiGraph()
for file in files:
with open(file) as f:
tree = ast.parse(f.read())
for node in ast.walk(tree):
if isinstance(node, ast.FunctionDef):
g.add_node(node.name)
for call in [n for n in ast.walk(node) if isinstance(n, ast.Call)]:
if hasattr(call.func, 'id'):
g.add_edge(node.name, call.func.id)
return g
The graph is dumped into Postgres for fast, recursive queries across dependency chains.
What Does This Unlock for Reviewers and Devs?
1. Instant Impact Mapping
Before code review, I can instantly see which functions, services, or APIs are actually touched by a given PR—not just direct imports, but real dependency chains. This surfaces unexpected side effects and integration leaks before they hit production.
2. Static Pattern + Agent Review
semgrep reliably surfaces patterns that LLMs often miss—especially around insecure SQL generation and forgotten input validation. On three recent agent deployments, I caught the same vulnerable SQL pattern in the data access layer. The graph highlights where LLM review agents should focus, reducing false positives and missed context.
3. Fast Deep Chain Search
With Postgres, I can query all usages of, say, an ENV variable that actually flow into business logic—not just where they're referenced, but real execution paths.
SELECT source, target
FROM code_graph
WHERE source LIKE '%ENV%'
AND target LIKE '%business_logic_%';
Compliance and Security: No Code Leaves the Perimeter
For regulated clients (GDPR, BSI Grundschutz), all code stays on-site. The intelligence graph is built and queried locally. Security stack:
- Supabase RLS restricts who can query the graph
- Doppler manages secrets/environment variables—these never enter the graph directly
- Claude Code agents only see the local knowledge base via controlled APIs
This matches GDPR and BSI security requirements (see BSI Grundschutz).
Comparing Approaches
| Method | Query Speed | Security | Analysis Depth |
|---|---|---|---|
| IDE/Grep | Slow | Local | Shallow |
| Cloud code search | Fast | Risky | Medium |
| Local code graph | Fast | Maximum | Deep (AST+relations) |
FAQ
How fast does the graph rebuild on large pushes?
On 120,000 lines, a full rebuild takes about 2 minutes. Incremental updates per branch: under 10 seconds.
Can this plug into existing CI/CD?
Yes—n8n triggers graph rebuilds and agent checks automatically after each push or PR.
How do you restrict graph access?
Supabase RLS enforces per-user or per-agent policies. Only reviewers or trusted agents get query rights.
Can LLM agents use the graph?
Yes, but they only see local nodes via a restricted API—no code leaves the secure perimeter.
How do you catch vulnerabilities?
semgrep plus bandit for Python, gitleaks for secret scanning. See semgrep.dev and bandit docs.
In your production stack, which stage actually catches the most critical issues: static analysis, runtime sandbox, or human review? I'd genuinely like to know. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.
Turn your process into an AI system
Production quality. DACH B2B focus.