Wie Sie Code-Reviews und Navigation in großen Codebasen mit KI beschleunigen: Praxis mit lokalem Code-Intelligence-Graph

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem DennisCraft AI Studio liefere ich produktive Agentensysteme für DACH-B2B-Kunden – Stack: Claude, Supabase, n8n, Doppler, Postgres on-premise. Vor kurzem stand ich vor der Aufgabe, eine Codebasis mit über 115.000 Zeilen in der Industrieautomatisierung zu prüfen. Trotz guter Testabdeckung und Review-Prozessen wurden kritische Auswirkungen von Änderungen – vor allem an Schnittstellen und bei generiertem Code – oft erst im Produktivbetrieb sichtbar. Sicherheits- und Compliance-Bedenken verbieten Cloud-Indexierung. Die klassische Tools (IDE, grep, LLM-Suche) reichen für diese Größenordnung nicht mehr aus.

Herausforderung: Code-Reviews und Navigation in regulierten, großen Systemen

Jenseits von 100.000 Zeilen Code verlieren Reviewer schnell das Gesamtbild. Die zentrale Frage: Welcher Change beeinflusst welche Kette von Services, Variablen, APIs? Laut meiner Erfahrung werden in europäischen Enterprise-Teams maximal 60% aller kritischen Fehler im Review erkannt – der Rest bleibt „versteckt“ im komplexen Zusammenspiel. Zugleich untersagen DSGVO, BSI Grundschutz und oft auch NIS2 ein Auslagern von Quellcode oder Metadaten an SaaS-Anbieter.

Ansatz: Lokaler Code-Intelligence-Graph als Navigations- und Prüfschicht

Statt einer Cloud-Lösung baue ich einen lokalen Code-Intelligence-Graphen, der alle Abhängigkeiten, Aufrufe, Variablen, externe APIs und Umgebungsvariablen erfasst – vollständig lokal, ohne Datenabfluss. Dieses Muster verbindet statische Analyse mit Graphdatenbanken und Knowledge-Graph-Prinzipien – mit klarer Trennung zwischen Produktiv- und Entwicklungsumgebung.

Technische Realisierung

• semgrep zur Extraktion von Mustern und Sicherheitsprüfungen (semgrep.dev)
• Python-Skripte (AST-Parser, networkx für Graphmodellierung)
• Postgres als persistente, performant abfragbare Graphdatenbank
• n8n für Workflow-Automatisierung bei jedem Push/Merge
• Claude Code als semantische Schicht, aber ausschließlich auf lokale Graphdaten zugreifend

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

Die Kanten und Knoten werden in Postgres abgelegt. Komplexe Abhängigkeitsketten sind so mit SQL direkt auffindbar.

Nutzen für Reviewer und Entwickler

1. Impact-Mapping vor jedem Review

Vor jedem Review ist sofort sichtbar, welche Funktionen, Services und APIs tatsächlich direkt oder indirekt betroffen sind – nicht nur per Import, sondern entlang der realen Ausführungsketten. Das minimiert „blinde Flecken“ bei Integrationspunkten.

2. Semgrep und Agenten-Analyse

semgrep erkennt Muster, die LLMs oft übersehen – z.B. fehlerhafte SQL-Generierung oder fehlende Input-Validierung. Auf mehreren Produktiv-Einführungen entdeckte ich wiederholt dieselbe SQL-Verwundbarkeit im Python-Layer. Der Graph zeigt, wo menschliche Reviewer oder Agenten gezielt prüfen sollten.

3. Schnelle Abfrage tiefer Abhängigkeitsketten

Mit Postgres lassen sich alle Stellen finden, an denen eine ENV-Variable tatsächlich in die Geschäftslogik einfließt – nicht nur Referenzen, sondern reale Ausführungspfade.

SELECT source, target
FROM code_graph
WHERE source LIKE '%ENV%'
AND target LIKE '%business_logic_%';

Sicherheits- und Compliance-Aspekte

Der Graph wird ausschließlich lokal erzeugt und abgefragt. Sensible Daten (Secrets, ENV) verwaltet Doppler außerhalb des Graphen. Supabase RLS regelt fein granular, wer auf den Graphen zugreifen darf. Claude Code-Agenten greifen nur über restriktive lokale APIs auf die Graphdaten zu – kein Quellcode verlässt das Firmennetz.

Damit ist die Lösung konform zu DSGVO, BSI Grundschutz (BSI Grundschutz), NIS2 und ISO 27001.

Vergleich der Methoden

FAQ

Wie lange dauert ein Rebuild des Graphen bei großen Änderungen?

Für 115.000 Zeilen benötigt ein kompletter Neuaufbau ca. 2 Minuten. Inkrementelle Aktualisierung pro Branch: unter 10 Sekunden.

Lässt sich das in bestehende CI/CD-Pipelines einbinden?

Ja, via n8n werden Graphaufbau und Agenten-Prüfungen nach jedem Push/Merge automatisiert durchgeführt.

Wie wird der Zugriff auf den Graphen gesteuert?

Mit Supabase RLS können Rechte pro Reviewer oder Agent granular vergeben werden.

Können LLM-Agenten auf den Graphen zugreifen?

Nur über restriktive API, ausschließlich auf lokale Graphdaten – kein Export ins externe Netzwerk.

Wie werden Verwundbarkeiten erkannt?

semgrep plus bandit für Python, gitleaks für Secrets-Scanning. Dokumentation: semgrep.dev, Bandit.

In welchem Stadium Ihrer Pipeline erkennen Sie die meisten kritischen Fehler im Produktivbetrieb: statische Analyse, Laufzeitsandbox oder manuelles Review? Ich biete einen kostenfreien 30-min Stack-Check für DACH-Teams in regulierten Märkten an. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.