Агент читает 20 файлов ради одной функции. Лечим это графом кода: CodeGraph vs Graphify и другие невиданные твари

• CodeGraph и Graphify решают разные задачи, хотя оба строят граф кода на tree-sitter. CodeGraph — лёгкий локальный индекс символов для рантайма агента. Graphify — граф знаний всего проекта, включая документы, PDF и медиа.

• CodeGraph работает 100% локально (SQLite + FTS5), без внешних API. Graphify код тоже парсит локально и бесплатно, а токены тратит только на документы и медиа — и то через модель твоей IDE-сессии, без отдельных ключей.

• Их бенчмарки CodeGraph: −57% токенов, −71% tool calls, −46% времени на 7 репозиториях. Это их цифры на их выборке, я не воспроизводил. Своё ощущение — заметно быстрее и точнее, но замеров не делал, честно.

• Модель хранения — следствие архитектуры. Индекс CodeGraph (.codegraph/) — это кэш, производный от кода: его регенерируют, а не шарят через git. graph.json у Graphify — текстовый артефакт, его авторы прямо предлагают коммитить.

• Рынок шире двух полюсов. Рядом — Gortex (мультирепо, 256 языков, тоже локально), Sourcegraph MCP (enterprise, cross-repo) и Cognee (долговременная память агента, а не навигация по коду). В статье — карта, кому что подходит.

• Индексация — это не про экономию токенов, а про точность, скорость и качество поиска. Токены — приятный бонус. Отказываться от индекса, потому что «подписки хватает», — то же самое, что отказаться от индексов в БД, потому что «сервер мощный».

---

Раньше думал в духе: «У меня Max-подписка, токенов вагон — зачем ты городишь индексацию кода? Дай агенту grep и не выпендривайся». Полгода назад я бы согласился. Сейчас — нет, и к концу статьи объясню почему. Спойлер: дело вообще не в токенах, но и их в последнее время начало сильно не хватать, особенно с последними глюками всех подписок по сжиганию токенов…

Тут всё по классике — даю задачу: «найди, где обрабатывается авторизация, и поправь логику отказа». Агент честно идёт искать. Спавнит эксплорацию (или даже отдельного агента для этого), грепает по ключевым словам, читает пятнадцать-двадцать файлов целиком, чтобы понять, что с чем связано. Каждый read — это весь файл в контекст. На среднем по размеру репозитории это сотни тысяч токенов и десятки tool calls только на то, чтобы понять, где вообще лежит ответ. А половину времени он ещё и промахивается: прочитал не те файлы, сделал вывод, пошёл чинить не там или что-то не учёл/не увидел.

Проблема не в модели. Проблема в способе поиска. Агент делает full table scan по кодовой базе там, где должен делать запрос по индексу.

Что вообще такое «граф кода»

Идея простая, и она не новая. tree-sitter парсит исходники в AST и вынимает из них две вещи: узлы (функции, классы, методы) и рёбра (кто кого вызывает, кто что импортирует, кто от кого наследуется). Получается граф. Дальше агент вместо «прочитай двадцать файлов и догадайся» задаёт точечный вопрос: «кто вызывает validateToken», «где определён класс AuthGuard», «что сломается, если я трону вот эту функцию». Один запрос вместо веера чтений.

(Кстати, это ровно та же история, что индексы в базе данных. Можно гонять SELECT по миллиону строк full scan-ом, а можно построить индекс и доставать нужное за миллисекунды. Никто в здравом уме не спорит, что индексы в БД не нужны, «раз сервер мощный». С кодом для агента — та же логика, просто мы к ней ещё не привыкли.)

Вокруг этой идеи и выросли обе системы, которые я хочу сравнить. И вот тут интересное: при одинаковом фундаменте они оказались про совершенно разные вещи.

CodeGraph: лёгкий индекс, который я сейчас и гоняю

CodeGraph — это символьный граф кода и ничего лишнего. Функции, классы, вызовы, импорты, наследование. Всё работает 100% локально: парсинг на tree-sitter, хранение в SQLite с полнотекстовым поиском FTS5 в папке .codegraph/. Никаких внешних API, ничего не уезжает наружу. Авто-синхронизация висит на нативных файловых вотчерах (FSEvents/inotify) с дебаунсом в пару секунд — поправил файл, индекс догнался сам.

Для агента он поднимается как MCP-сервер и отдаёт инструменты вроде codegraph_search, codegraph_context, codegraph_trace. То есть агент больше не грепает — он спрашивает у индекса.

Ставится буднично:

npx @colbymchenry/codegraphcodegraph init      # первичная индексация проектаcodegraph search "validateToken"

Главная грабля у меня была не в установке, а во встраивании всего этого в текущий harness. Codex — мой основной инструмент, и заставить агента реально ходить в индекс, а не игнорировать MCP-сервер и по привычке грепать, оказалось не вопросом одной галочки. Пришлось повозиться с MCP-настройкой и, главное, с тем, как именно агенту подаётся инструкция предпочитать индекс файловому поиску — без явного промпта он по привычке лезет грепать. В итоге сделал, работает.

Честно про эффект: своих замеров я не делал. По субъективному ощущению — заметно быстрее и точнее, агент перестал залезать в десяток лишних файлов. Но это ощущение, а не график зато цифры есть у авторов: на семи open-source репозиториях они заявляют −35% стоимости, −57% токенов, −46% времени и −71% tool calls на медианном прогоне, а на чём-то крупном вроде VS Code экономия по tool calls доходит до −80%. Это их цифры на их выборке, я их не воспроизводил. Но порядок мне кажется правдоподобным: на большом репозитории веер из двадцати чтений действительно схлопывается в один запрос, и tool calls режутся в разы.

Graphify: не индекс для агента, а карта всего проекта

А вот Graphify — про другое, хотя на первый взгляд кажется тем же самым. Это не индекс символов для рантайма, а граф знаний всего проекта целиком: код плюс документация, PDF, изображения, видео. Код он, как и CodeGraph, парсит локально через tree-sitter. А вот документы и медиа отправляет в LLM на семантическую экстракцию — вытаскивает оттуда сущности и связи и вплетает их в общий граф.

На выходе — не база для запросов агента, а артефакты для человека: graph.html с интерактивной визуализацией, GRAPH_REPORT.md с «god-нодами» и неожиданными связями, плюс graph.json как машиночитаемый граф. Есть даже PR-triage. То есть это инструмент, чтобы понять проект — особенно чужой или легаси, где знание размазано между кодом и кучей документов.

И вот ключевой нюанс, в котором я по докам разбирался (потому что сам ещё не гонял). Сам код Graphify, как и CodeGraph, парсит локально через tree-sitter — на код токены не тратятся вообще. Платишь только за документы, PDF и медиа: их Graphify скармливает модели на семантическую экстракцию. И тут важная деталь, которую легко переврать. Если запускать его через skill /graphify прямо в IDE, отдельные API-ключи не нужны — он берёт модель из твоей сессии (Claude Code, Codex, Cursor), и расход идёт с твоей же подписки, а не с какой-то отдельной квоты. Отдельные ключи (Gemini, Anthropic, OpenAI и далее по списку) нужны только для headless-режима graphify extract вне IDE. А если совсем не хочешь тратить токены — можно запустить индексацию только по коду (graphify extract --no-cluster): чистый AST-граф, ноль обращений к модели, и Graphify в этом режиме по сути превращается в тот же CodeGraph. Подчеркну: это моё чтение доков плюс проверка, а не боевой опыт. Если кто-то гонял Graphify всерьёз и понял экономику точнее — поправьте, мне правда интересно.

Получается интересная развилка. CodeGraph экономит токены в рантайме агента. Graphify на код их не тратит вовсе, но как только подключаешь документы и медиа — платишь за них вызовами модели. Это и есть его цена за то, что он знает про проект больше, чем только код. Но с другой стороны, если это можно делать на подписке, то я думаю, что это себя окупит. Но надо тестировать.

Где это хранить — и почему ответ разный

Тут была моя вторая грабля. Я работаю с нескольких компьютеров и часто с командой. Первый рефлекс — раз индекс полезный, давайте положим его куда-нибудь общее: в git, в облако, на сетевой диск. Чтобы у всех был и не надо было пересобирать.

Не делайте так с CodeGraph. Во-первых, .codegraph/codegraph.db — это SQLite, а SQLite на сетевых шарах и в WSL2 ловит блокировки базы (у CodeGraph это прямо отмечено для старых версий). Во-вторых, бинарный файл в git — это конфликты при каждом коммите и распухание истории.

Правильная модель в голове: граф CodeGraph — это кэш, производный от кода, а не артефакт. Source of truth — это код в git. Индекс детерминированно строится из него за секунды. Значит:

# индекс не коммитим — он восстанавливается из кода.codegraph/

Каждый разработчик делает у себя codegraph init один раз, дальше вотчер держит индекс актуальным. Пересел за другую машину — переиндексировал, это быстро. Команда синхронизирует код, а не индекс. Никаких блокировок, никаких конфликтов.

А вот Graphify устроен наоборот, и это снова следствие архитектуры. Его graph.json — текстовый, и авторы прямо предлагают коммитить его в git. Что логично: построение графа стоит токенов, и пересобирать его у каждого на каждой машине — дорого. Собрал один раз, закоммитил, вся команда пользуется готовым.

То есть выбор «хранить локально или шарить» — это не вопрос вкуса, а прямое следствие того, что вы построили: дешёвый детерминированный кэш регенерируют, а дорогой LLM-артефакт — шарят через git.

Коротко в таблицу

Так что брать

Не «или-или». Это разные инструменты, и их легко держать оба.

• Берите CodeGraph, если ваша боль — «агент жжёт токены и время на эксплорацию кода, и всё равно промахивается». Ежедневная работа агента, чистый локальный пайплайн без внешних вызовов, command-line. Это рабочая лошадка для рантайма.

• Берите Graphify, если ваша боль — «не понимаю проект целиком, знание размазано между кодом, документацией и дизайном». Онбординг в незнакомый или легаси-проект, архитектурный обзор, визуализация связей, разбор PR. Это инструмент понимания, а не ускорения.

Сам я сейчас на CodeGraph как на постоянном индексе для агента, а Graphify планирую попробовать именно для периодического обзора проектов — собрать карту, посмотреть god-ноды и неожиданные связи. По ощущению, в одной голове они уживаются без конфликта: один работает каждый день в фоне, второй достаёшь, когда надо охватить картину.

Но это не вся полка

Будет нечестно сделать вид, что мир сошёлся на этих двух. CodeGraph и Graphify я взял как два полюса — лёгкий индекс символов против богатого графа знаний, — но рядом стоит ещё несколько инструментов, и если ваша задача чуть в стороне, смотреть стоит на них. Сразу оговорюсь: всё, что ниже, — это то, что я изучал по докам и репозиториям, гонял сам пока только CodeGraph.

Если упёрлись в потолок CodeGraph по языкам или по мультирепозиторности — рядом лежит Gortex. Тот же принцип (граф кода через MCP, 100% локально), но размашистее: in-memory граф, 256 языков, мультирепо со сквозным разрешением символов между репозиториями, один бинарь без внешних зависимостей. Автор заявляет до ~94% экономии токенов, один вызов smart_context вместо пяти-десяти чтений файлов, а индексация чего-то размером с VS Code занимает около минуты. По описанию это «CodeGraph на стероидах», и если бы я работал с десятком связанных репозиториев, начал бы смотреть именно туда. Минус ровно один и тот же, что у всех чистых код-графов: это всё ещё только про код, не про код плюс решения плюс документацию.

Есть и CodeGraphContext — тоже MCP плюс CLI, тоже граф кода, но он индексирует не в SQLite, а в полноценную graph-базу. Мощнее по запросам к графу, но платишь за это тем, что graph-БД надо поднять и обслуживать — прощай идиллия «поставил и забыл», которая мне в CodeGraph и нравится.

Отдельная весовая категория — Sourcegraph MCP. Это уже не «библиотека на ноутбуке», а enterprise-инструмент для больших организаций с кучей репозиториев: точный SCIP-индекс, переход к определению и поиск ссылок через границы репозиториев, история, ownership, и главное — непрерывно поддерживаемый граф, общий для всех людей и агентов в компании. У них свой бенчмарк CodeScaleBench с цифрами уровня −30% стоимости и кратного роста точности выборки (снова — их цифры). Минус очевиден: это платный Enterprise-план, не локальная история для соло-разработчика или небольшой команды.

И последнее, что важно не спутать с индексацией кода. Cognee — это уже не про навигацию по коду, а про долговременную память агента: graph плюс vector, постоянная, общая память между клиентами, плагин для Claude Code. Она решает другую задачу — «помнить решения, факты и контекст проекта», а не «быстро найти, кто вызывает эту функцию». Полезная штука, но если вам нужен просто индекс кода, Cognee — это из пушки по воробьям: вы поднимаете память-платформу с vector- и graph-бэкендами там, где хватило бы лёгкого локального индекса. А на другом конце спектра — связки вроде Obsidian или Logseq плюс MCP-мост: отличная база знаний, если вы ведёте её руками. Ключевое «если»: обычно не ведёте, и я в том числе.

Если свести всё это к одной мысли: я сознательно не гонюсь за «самым мощным». Для ежедневной работы выигрывает простота — поставил, забыл, всё локально. Gortex держу на заметке на случай мультирепо, Sourcegraph — это про другой масштаб компании, Cognee — вообще про другую задачу. Полку полезно знать целиком, но брать с неё стоит ровно то, что закрывает вашу боль, а не то, у чего больше звёзд.

Возвращаясь к «А зачем, если токенов хватает»

Даже если токенов в подписке хватает. И всё равно я считаю отказ от индексации ошибкой — потому что экономия токенов тут вообще не главное.

Главное — точность, скорость и качество поиска. Агент с индексом находит нужное с первого запроса, а не читает двадцать файлов и строит гипотезу на половине из них. Он реже промахивается, а значит реже чинит не то и реже заставляет меня перепроверять. Я экономлю своё время и получаю результат лучше.

Отказываться от этого, потому что «подписки и так хватает» — ровно та же логика, что «у меня мощный сервер, зачем индексы в базе». Хватать-то хватает. Просто можно сделать быстрее, точнее и дешевле одновременно — и я не вижу причины этого не делать.

А ещё — мой маленький setup-skill в довесок

Тут важно сразу развести две вещи, чтобы не было путаницы. У самого Graphify есть здоровенный runtime-skill на тысячу с лишним строк, который ставится командой graphify install (называется просто graphify). Он делает всю боевую работу: агент по триггеру /graphify поднимает pipeline — детект файлов, AST + семантическая экстракция через сабагенты, кластеризация, отчёт, query/path/explain, обновление через --update, MCP-сервер, Neo4j-экспорт, --watch. Это операционный слой — как агенту запускать Graphify в работе.

В дополнение к этому я положу в Telegram свой graphify-project — но это про совсем другое. Он маленький, около 150 строк, и решает узкую задачу: однажды правильно поставить Graphify в репозиторий и не дать агенту втихую сжечь токены через внешний backend. Это не runtime, это setup-обёртка с safety-rules. Внутри:

• Codex PreToolUse hook — короткое напоминание агенту заглянуть в граф перед широким Bash-вызовом, чтобы он не лез грепать по привычке. Один блок в .codex/hooks.json.

• Fallback на zig-cc — если на машине нет gcc, нативная зависимость tree-sitter-* не соберётся, и установка тихо упадёт. Skill в этом случае ставит Zig как пользовательский компилятор и продолжает без sudo. Я сам на это напоролся, поэтому в skill зашито.

• Опциональная интеграция с .codex/orchestrator.toml — компактная секция [knowledge_graph] с командами refresh/query, политикой хуков и closeout-маркером. Если у вас свой оркестратор-конфиг (у меня свой), skill встраивается без боли.

• Явное разделение режимов — code/local graph vs full semantic vs blocked/deferred semantic, с правилом «не запускать платный backend без явного разрешения». Это спасает, когда агент видит чьи-то API-ключи в env и решает, что ему «можно».

То есть это не «лучше стокового», это рядом. Стоковый graphify вы ставите через graphify install, он работает в рантайме. Мой graphify-project — маленький админский слой, который может пригодиться, если вы работаете в Codex с оркестрацией и хотя бы раз ловили падающую сборку tree-sitter. У меня они уживаются в одной голове без конфликта: стоковый делает запуск, мой — настройку.

Skill для CodeGraph я отдельно не делал — там логика проще, и текстового промпта хватает.

---

Graphify я, повторюсь, ещё не гонял на боевом — это в планах. Если кто-то уже сравнивал обе на реальном проекте, замерял экономику Graphify или нашёл что-то третье поинтереснее — напишите в комментариях, очень интересно, кто чем индексирует код для агентов. Можно и не в комментариях: ссылки на обе системы, команды установки, два готовых промпта внедрения (копируешь в агента — он сам разворачивает инструмент и прописывает себе правило ходить в граф, а не грепать) и тот самый skill graphify-project я выложу в Telegram-канале — туда же заходите обсудить, если формат комментариев не ваш. Для прямой связи — @maslennikovig.