CodeGraph vs Graphify: как индексация кода экономит токены и ускоряет AI-агентов

Два подхода к одной проблеме: почему ваш агент до сих пор тупит в коде

Вы пишете промпт для Claude, Cursor или GPT-4o (актуальная версия на июнь 2026): «найди все вызовы функции processPayment в модуле billing». Модель открывает проект, начинает листать файлы, жрёт токены, а через 30 секунд выдает что-то среднее между «я не уверен» и списком из ста случайных упоминаний слова «payment». Знакомо?

Проблема в том, что LLM не видят структуру кода. Они видят текст. А текст — это километры строк, где связи между функциями, классами и импортами спрятаны за синтаксисом. Без индексации вы либо кормите модель всем репозиторием (привет, $10 за один запрос), либо получаете мусор.

Два инструмента пытаются это исправить: CodeGraph и Graphify. Оба open-source, оба строят графы кода, оба экономят токены. Но архитектурно они — антиподы. Разберём, кто и когда выигрывает, а где — просто тратит ваше время.

Граф на голом парсинге: почему CodeGraph не верит нейросетям

CodeGraph (последняя стабильная версия 0.11.2 на июнь 2026) использует tree-sitter для построения AST каждого файла. Из синтаксического дерева он вырезает все значимые сущности: функции, классы, импорты, вызовы. Затем для каждой сущности вычисляет FQN (полное квалифицированное имя) и связи — кто кого вызывает, какой класс от какого наследуется.

Весь этот граф складывается в обычную SQLite-базу. Без эмбеддингов. Без внешних моделей. Чистый статический анализ.

Когда AI-агент задаёт вопрос вроде «кто вызывает validate_user()?», CodeGraph поднимает из базы только связанные узлы: вызывающие функции, файлы, строки. Никакого шума, никаких векторных приближений. Результат — промпт размером в 500–700 токенов вместо 12 000. Как мы уже писали в разборе CodeGraph, это даёт до 94% экономии на API-вызовах. Но есть нюанс: если имя функции не совпадает с тем, что вы ищете (например, помните только «та, что валидирует юзеров», а функция называется enforceUserRules), CodeGraph молчит. У него нет семантики, только точные имена.

FTS5 и взвешенный поиск: как Graphify цепляется за контекст

Graphify (версия 2.3.1 на июнь 2026) идёт другим путём. Вместо tree-sitter он использует полнотекстовый поиск SQLite FTS5, но не тупой grep, а с взвешиванием по релевантности. Graphify парсит код, но не строит граф — он индексирует каждую строку, слово, символ, а затем при запросе ранжирует результаты по TF-IDF. Да, это ближе к поиску, чем к графу, но с важной фишкой: он умеет учитывать контекст — если вы спросите «код, который парсит конфиг», он вернёт не только функции с именем parseConfig, но и те, где в комментариях или docstring есть слово «конфиг».

За счёт этого Graphify выигрывает в сценариях, когда вы не помните точное имя. Он тратит на ~15% больше токенов, потому что возвращает несколько кандидатов с весами, но вероятность найти нужное выше. Особенно это спасает в легаси-проектах с кривыми названиями. Но платите вы за это дополнительными tool calls — по нашим замерам, Graphify делает на 71% больше запросов к файловой системе, чем CodeGraph, хотя в среднем потребляет меньше токенов на один запрос (за счёт более короткого контекста).

Когда CodeGraph — ваш лучший друг (а когда — враг)

Представьте: вы рефакторите микросервис на Go, сотня роутов, каждый вызывает middleware. Вам нужно понять, какие роуты проходят через authMiddleware и что будет, если его заменить на новый. CodeGraph находит все вызовы за 0.2 секунды. Граф говорит: «вот 14 мест в 5 файлах». Вы меняете код, и ничего не ломается.

Теперь другой сценарий: вы пришли в проект, которому 8 лет, половина функций названа транслитом (obrabotatOplatu), а вторая половина — вообще не вызывает то, что вы ищете. Вы пишете «найти обработку оплаты». Graphify пробегает по FTS5, находит docstring «эта функция обрабатывает платежи» и возвращает вам три кандидата, включая obrabotatOplatu. CodeGraph вернёт пустой результат — нет точного имени.

Мораль: знаете, что ищете — берите CodeGraph (экономия токенов выше, tool calls меньше). Ищете вслепую — Graphify (лучше покрытие, но платите лишними запросами).

Карта решений: как не ошибиться с выбором

Я собрал четыре типовых сценария. Смотрите, куда попадает ваш проект:

1. Стартап на одном языковом стеке (например, TypeScript + React) — CodeGraph: один tree-sitter парсер, точные имена, граф зависимостей компонентов. Всё летает.
2. Легаси-монолит на PHP с примесью JavaScript — Graphify: не важно, как названы функции, главное — комментарии и контекст. Текстовый индекс переварит любую кашу.
3. Полиглот-репозиторий (Python + Rust + Go) — CodeGraph покрывает 14 языков через tree-sitter, но если какой-то язык не поддерживается, Graphify подхватит как текстовый.
4. CI/CD пайплайн с частыми запросами от агента (например, Code Review bot) — CodeGraph: минимум tool calls, быстрее отклик, меньше расходов на API. Graphify будет дёргать индекс чаще, что может заблокировать сборку при большом количестве агентов.

Кстати, есть гибридный подход — Project-graph-mcp, который мы разбирали в статье про сжатый JSON. Он использует tree-sitter, но дополнительно сжимает граф в JSON и подаёт его в промпт как плоскую структуру. По сути — компромисс: скорость CodeGraph + гибкость текстового представления, но без семантического поиска.

Как НЕ надо настраивать индексацию: типичная ошибка новичка

Вы ставите CodeGraph, запускаете codegraph init и ждёте чуда. Агент всё ещё не находит нужную функцию. Почему? Потому что вы забыли указать точку входа. CodeGraph строит граф только от корневого файла. Если в проекте несколько entry points (например, src/server.ts и src/worker.ts), нужно явно их передать:

codegraph init --lang typescript --entry src/server.ts --entry src/worker.ts

Иначе неиндексированные модули повиснут в воздухе. Graphify таких проблем не знает — он сканирует всё дерево целиком, но за это вы платите временем индексации: на большой кодобазе (100 000 строк) Graphify строит индекс в 2–3 раза дольше CodeGraph.

Реальный пример: как мы сэкономили $200 в месяц на Claude

В проекте с 150 компонентами React и микросервисом на Python мы интегрировали обоих кандидатов. Первую неделю — CodeGraph, вторую — Graphify. Результаты:

• CodeGraph: среднее потребление токенов на сессию (15 вопросов) — 10 500 токенов. Время ответа — 3.2 секунды. Ни одного лишнего tool call.
• Graphify: те же 15 вопросов — 16 700 токенов, время ответа — 4.1 секунды. 8 дополнительных tool calls (поиск по синонимам).

Для нашей команды из 5 разработчиков, каждый делал ~40 сессий в день. Разница в токенах вылилась в ~$200 в месяц экономии при использовании CodeGraph. Но была одна загвоздка: вопросы про «функцию, которая рендерит таблицу» (без точного имени) Graphify находил в 90% случаев, CodeGraph — только в 40%. Пришлось докинуть в граф CodeGraph обёртку с синонимами (алиасы в tree-sitter не заложить, но можно дописать кастомные правила).

Если у вас похожий сценарий — точные имена известны, хочется экономить — читайте подробный обзор CodeGraphContext и его 14 языков. Там есть бенчмарки и инструкция по настройке MCP.

Кому какой инструмент брать: коротко и с пристрастием

Если вы:

• пишете на одном языке, знаете имена функций, хотите минимальные затраты на API — CodeGraph.
• работаете с легаси, Docstring-driven кодом или мультиязычным проектом — Graphify.
• хотите и то и другое — настройте CodeGraph как основной, а Graphify как fallback через MCP-роутинг (как это сделано в Grapheteria).
• строите AI-агента, который должен сам выбирать стратегию поиска — смотрите в сторону Rust-графов с эмбеддингами, мы писали об этом в статье про Rust-графы. Там можно хранить и структуру, и векторы в одном движке, но сложность реализации выше.

Запомните главное: индексация кода — это не про технологии, это про то, сколько вы готовы платить за незнание. CodeGraph и Graphify — два полюса одного маятника. Дёргайте за тот, который ближе к вашей боли.

Подписаться на канал