Редакция 23 июня 2026 г.

Сорок шесть репозиториев, один граф и вопрос, который задаёт каждый, кто кормит код агенту

Когда legacy-код размазан по десяткам репозиториев, соблазн простой: открыть чат с LLM и «дать ИИ прочитать код». Ryan Tsuji, CTO airCloset, в первой части серии на Dev.to объясняет, почему для production impact analysis этого мало — и как команда вместо сырого текста строит единый knowledge graph со статическим анализом и отдаёт его агентам через MCP.

Почему агенту недостаточно «прочитать все 46 репозиториев»

Задача звучит как классический сценарий для ИИ-ассистента: «покажи blast radius», «что сломается, если я поменяю вот это». Масштаб ломает наивную схему.

Сорок шесть репозиториев — тридцать семь на стороне air-closet (airCloset, Men's, WMS и другие сервисы) и девять у airCloset Mall — это не один монолит. Годы production-кода вперемешку с jQuery, AngularJS, Express, Koa, Fastify, NestJS, TypeORM и ещё десятком механизмов path-alias.

Даже если бы весь объём теоретически поместился в context window одного запроса, остаётся вторая проблема: извлечение связей между сервисами — это инференс. Модель склонна отвечать из того, что «увидела», а не признать пробел.

Для blast-radius анализа такие silent hallucinations неприемлемы: recall около 90% здесь бесполезен — десять процентов невидимого кода при multi-hop обходе превращаются в каскад ошибок (при пяти переходах точность падает примерно до 0,59).

Именно поэтому вместо «скорми файлы агенту» команда пошла в сторону верифицированной карты: статический анализ, граничные узлы и выдача структуры ИИ как инструмента, а не как сырого дампа.

Boundary nodes: что модель должна знать наверняка

Центральная идея code-graph — не перечислить каждую функцию, а зафиксировать границы, через которые репозитории реально связаны. Автор выделяет boundary nodes: API endpoints, таблицы БД, топики событий.

На них навешивают отдельные типы рёбер — среди двадцати одного типа в графе есть, например:

CALLS_API / HANDLES_API — HTTP-границы;
EMITS_TO / SUBSCRIBES_TO — события;
WRITES_TO / READS_FROM — кросс-репозиторный доступ к одной таблице.

Смысл для ИИ-слоя простой: вместо того чтобы угадывать, кто вызывает чей handler через границу сервисов, агент получает проверенный факт из графа. Boundary nodes физически сужают пространство, где модель может «додумать» связь.

Ежедневный cron boundary-analysis (07:00 JST) сверяет согласованность caller/handler на API, пар emitter/subscriber на событиях и cross-repo записей в БД. При падении connection rate больше чем на пять процентов срабатывает алерт в Grafana. Цель — connection rate выше 99%; прямой recall измерить нельзя, ground truth нет, поэтому смотрят на долю корректно соединённых границ.

Для запросов вроде «что затронет изменение в этом endpoint» это уже не промпт-магия, а опора на структуру, которую парсеры собрали до разговора с моделью.

Как собирали code-graph: три стадии парсинга и BigQuery под капотом

Проект внутри команды зовётся code-graph; активная разработка шла с января по март 2026, с опорой на git history этого периода — не на идеальную схему «с первого дня».

Базовый слой — tree-sitter: AST для TypeScript, JavaScript, Go и Dart (Flutter). Для цепочек field-access и разрешения типов поверх AST подключают TypeScript Compiler API, а динамические случаи, которые TSC не закрывает, добирают через Gemini. Цепочка: tree-sitter → TSC → Gemini. Граф складывают в BigQuery (коммит с graph builder датирован 15 января 2026).

Узлы — функции, методы, классы, поля плюс отдельный класс boundary nodes. Структурные связи (CALLS, EXTENDS, IMPLEMENTS и другие) дополняют граничные.

Зоопарк фреймворков не исчезает: для каждого нового паттерна нужен детектор в parser directory — их уже больше десяти custom extractors, и нагрузка на поддержку растёт.

Контрастный пример из той же компании — in-house проект cortex (больше сотни приложений в monorepo): там ушли в annotation-based knowledge graph с JSDoc-тегами, векторизацией intent и semantic search. Для сорока шести production-репозиториев с разными командами и смешанным стеком такой разметки «сразу на всё» нереалистично. Вывод: static analysis как база, поверх — дополнительные слои — анонсирован service-product-graph во второй части.

MCP как интерфейс: от восемнадцати инструментов к пяти

Граф имеет смысл для агента только если тот может им пользоваться без ручного SQL. В статье целевой паттерн сформулирован прямо: граф отдаётся ИИ через MCP.

15 февраля 2026 команда консолидировала восемнадцать MCP tools в пять с deep subgraph traversal — меньше шума в tool list, глубже обход подграфа.

Практический стек выглядит так:

search MCP — поиск по LIKE-подстрокам (ограничение, о котором ниже);
Git Server MCP — чтение файлов после того, как граф сузил кандидатов;
codebase-investigation tool — связка обоих слоёв: «сначала карта, потом первоисточник в репозитории».

Типичные формулировки запросов к ассистенту — «show me the blast radius», «tell me what breaks if I change this» — упираются в эту связку, а не в попытку загрузить все репозитории в один контекст.

Отдельные продукты вроде named IDE-агентов, файлов rules или конкретных промпт-шаблонов в Part 1 не названы; интеграция описана именно через MCP и сценарии расследования кода.

Три месяца trial and error: четыре проблемы, которые граф не закрыл

Ретроспектива честная: за январь–март 2026 подход evolved, а не был выброшен, но четыре боли остались на столе.

Semantic search. MCP search-tool умеет только LIKE по подстрокам. Баг описан словами на естественном языке — entry point в графе так не найти.

Node explosion. Наивное превращение AST в граф раздувает узлы: builtins, anonymous functions, helpers. Обход на несколько hops тащит лишнее; workaround stop_at=boundary помогает, но не решает корень.

Семантика функций. Граф отвечает на «что где» и cross-repo вызовы, но не на «что делает функция» — для этого всё равно нужен файл; позже связка с Git Server MCP как раз про сужение + чтение.

Стоимость парсеров. Каждый новый фреймворк или библиотека — новый детектор; parser directory уже переполнен кастомными extractors, и нагрузка на поддержку растёт.

Это не аргумент против графа, а карта того, что агентам всё ещё придётся обходить вручную или через следующий слой.

Что дальше: service-product-graph и вторая часть серии

Part 1 закрывает построение code-graph, болевые точки и оставшиеся дыры. Part 2 обещает service-product-graph (SPG) — слой поверх code-graph, который компенсирует то, что чистый статический анализ не вытягивает, в том числе ограничения semantic search и смысла функций. Детали SPG в первой части не раскрыты; заявлена эволюция подхода, а не отказ от статики.

Для команд, которые кормят LLM production-полирепо, урок скорее методический: контекст-инжиниринг для агентов здесь — не длина промпта, а структурированная карта с верифицированными границами и MCP-доступом. Остальное — в git history января–марта и в продолжении серии.

Источники

Ryan Tsuji — «Building One Knowledge Graph Across 46 Repositories With Static Analysis (Part 1)», Dev.to: Dev.to (дата публикации: 2026-06-22; дата доступа при обогащении: 2026-06-23)