Как ускорить ревью и навигацию в огромных кодовых базах с помощью AI: кейс локального code intelligence графа
Я — Denis Shokhirev, Agentic AI Systems Architect из Фрайбурга, управляю DennisCraft AI Studio и работаю со стеком Claude, Supabase, n8n, Doppler, локальный Postgres. Недавно пришлось разбирать 110K+ строк кода для проекта промышленной автоматизации в Германии. Найти, где меняется один бизнес-правило, оказалось сложнее, чем убедить заказчика интегрировать новую модель. Типовой стек поиска ("ctrl+f", IDE, поверхностные LLM-подсказки) перестал справляться — ревью затягиваются, баги пролетают в про
Я — Denis Shokhirev, Agentic AI Systems Architect из Фрайбурга, управляю DennisCraft AI Studio и работаю со стеком Claude, Supabase, n8n, Doppler, локальный Postgres. Недавно пришлось разбирать 110K+ строк кода для проекта промышленной автоматизации в Германии. Найти, где меняется один бизнес-правило, оказалось сложнее, чем убедить заказчика интегрировать новую модель. Типовой стек поиска ("ctrl+f", IDE, поверхностные LLM-подсказки) перестал справляться — ревью затягиваются, баги пролетают в прод.
Проблема: ревью и навигация по кодовой базе в реальном проде
Когда кодовая база уходит за 100K строк, теряется ощущение контроля. Даже если код покрыт тестами и есть CI/CD. Мой опыт показывает: даже в командах с дисциплиной и хорошими привычками ревью находит максимум 60% критичных изменений. Оставшиеся 40% — это скользкие баги на стыке сервисов, дефолты, забытые side effects. Стандартные инструменты, вроде поиска по репозиторию или базовых линтеров, не помогают, когда архитектура сложная, много генерации и агентного кода.
Решение: локальный code intelligence граф поверх продакшн-кода
Я отказался от облачных решений, которые индексируют репозиторий на стороне SaaS — слишком много вопросов по безопасности и GDPR. Вместо этого — локальный code intelligence граф, который строится по всем рабочим веткам. Такой граф — это нечто среднее между статическим анализатором и knowledge graph: он фиксирует все связи между функциями, переменными, вызовами, external API, env-переменными, конфигами.
Как я собираю граф
Использую связку:
- semgrep — для сбора синтаксических связей (https://semgrep.dev/)
- Скрипты на Python (open-source AST-парсеры + NetworkX для построения графа)
- Postgres — для хранения связей и быстрых запросов
- n8n — для автоматизации обновления графа при каждом push
- Claude Code — для семантических подсказок, но только поверх локального графа
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
Все связи выгружаются в Postgres с быстрым поиском по цепочкам зависимостей.
Что это дает ревьюеру и разработчику
1. Локальный instant impact map
Перед ревью — сразу вижу, где возможно затронута логика (какие функции, сервисы, API реально связаны с изменяемым модулем, а не только те, что по surface-level импорту).
2. Semgrep + agent review
semgrep ловит паттерны (например, неочевидные SQL-инъекции), которые часто пропускают LLM-подсказки. На трех последних деплойментах нашёл одни и те же проблемы с небезопасной генерацией SQL-запросов в Python-слое. Обработка поверх графа позволяет показать узкие места, куда LLM-агенту стоит смотреть пристальнее.
3. Быстрый поиск по сложным цепочкам изменений
С Postgres-запросами можно за 1-2 секунды получить все места, где, например, переменная, доставшаяся из ENV, реально используется в бизнес-логике, а не просто передаётся по цепочке.
SELECT source, target
FROM code_graph
WHERE source LIKE '%ENV%'
AND target LIKE '%business_logic_%';
Обеспечение безопасности и комплаенс
В Европе и DACH нельзя отдавать исходники за пределы защищенного контура. Локальный граф строится только внутри корпоративной сети. Дополнительно:
- Права доступа разграничиваются через Supabase RLS
- Doppler хранит секреты и переменные окружения отдельно, не попадая в граф напрямую
- Все агенты (Claude Code) работают только с локальными данными — ни одна строчка кода не уходит в облако
Это соответствует требованиям GDPR, а также рекомендациям BSI Grundschutz по контролю утечек (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Grundschutz/grundschutz_node.html).
Сравнение подходов
| Метод | Скорость поиска | Безопасность | Глубина анализа |
|---|---|---|---|
| IDE + ctrl+f | Медленно | Локально | Только поверхностно |
| Облачные code search | Быстро | Рискованно | Средне |
| Локальный code graph | Быстро | Максимальная | Глубоко (AST + связи) |
FAQ
Как быстро перестраивается граф при больших пушах?
На 110K строк — около 2 минут на полную перестройку. Инкрементально — до 10 секунд на ветку.
Можно ли интегрировать с существующим CI/CD?
Да, через n8n: workflow можно триггерить rebuild графа и запускать проверки сразу после push или PR.
Как ограничить доступ к графу?
Supabase RLS позволяет выдавать права только ревьюерам или отдельным агентам. Настраивается через policy.
Можно ли использовать LLM-агентов поверх этого графа?
Да, но агент видит только локальные узлы, запросы идут через ограниченный API, никакой передачи кода наружу.
Как ловить уязвимости?
semgrep + bandit для Python, gitleaks для анализа секретов.
В вашем проде ревью реально ловит критические ошибки или просто "проходит по чеклисту"? На каком этапе вы чаще всего ловите баги: статический анализ, runtime sandbox или ручной просмотр? Я провожу бесплатный 30-мин аудит стека для DACH-команд, кто строит AI в регулированных рынках. Напишите в LinkedIn или в @ger_dennis_ai.
Превратить процесс в систему, которая работает
Продакшн-качество, а не демо.