Принёс новый GitHub-тренд для тех, кто работает с большими проектами - CodeGraph.

Идея простая: CodeGraph заранее строит для агента «карту проекта». Он индексирует репозиторий, вытаскивает функции, классы, импорты, вызовы и зависимости, складывает всё в локальную SQLite-базу, а потом отдаёт агентам через MCP.

То есть вместо привычного ритуала grep → read → grep → read → grep → read агент может запросить готовый граф кода.

Собственно, никакой магии тут нет, и польза весьма приземлённая. У больших проектов есть ощутимый налог на разведку: каждый новый агент сначала пытается понять, где что лежит, какие файлы важные, кто кого вызывает и где начинается нужный flow. Память и карта проекта в markdown тут не сильно спасает. Когда в репозитории сотни или тысячи файлов, агент может сжечь кучу токенов просто на то, чтобы осмотреться.

А раздутый контекст - это не только дороже и медленнее. Это ещё и лишний шум: модель тащит за собой мусор, который насобирала по пути. В итоге её «интеллект» внезапно начинает напоминать меня после третьего созвона подряд.

По собственным бенчмаркам автора на 7 open-source проектах CodeGraph дал примерно 35% экономии стоимости, 57% меньше токенов, 46% быстрее ответы и 71% меньше tool calls. Цифры красивые, но пока это именно авторский benchmark, а не независимое исследование.

Полноценных независимых исследований именно CodeGraph пока нет - инструмент свежий. Судя по релизам, он появился буквально в мае 2026 года и сейчас активно допиливается. Но сама идея не новая. Уже много лет существуют статические анализаторы, графы вызовов и графы зависимостей. Теперь этим всем пытаются научить пользоваться AI-агентов, потому что каждый лишний обход проекта - это токены, деньги и время.

Сразу задаюсь вопросом: почему это не стало мейнстримом раньше?

Думаю, основная причина в том, что раньше боль была слабее. AI и до этого умел писать код, объяснять файлы и помогать с рефакторингом, но чаще человек сам приносил ему контекст: вот файл, вот функция, вот ошибка. С агентами сценарий поменялся: теперь им всё чаще отдают задачу целиком - «разберись в проекте, найди нужную логику, измени её и проверь последствия».

И тут внезапно значимая часть работы уходит не на кодинг, а на разведку проекта. Поэтому старая идея code intelligence снова стала актуальной. Это привычные IDE-фичи вроде Go to definition, Find usages и Rename symbol, только теперь не для человека, а для агента. CodeGraph пытается дать ему не простыню файлов, а карту связей внутри проекта.

Но открытых вопросов всё ещё много. Как сделать такой граф универсальным, если в реальных проектах есть динамические импорты, DI-контейнеры, ORM, generated code и магия фреймворков? Как заставить агента действительно пользоваться графом, а не продолжать бегать через grep/read по привычке?

Похожие подходы уже проверяли в исследованиях. Например, в препринте про Codebase-Memory использовали похожую связку: Tree-sitter, knowledge graph и MCP. Результат ожидаемый: токенов уходит сильно меньше, tool calls тоже меньше, но качество ответов может просесть, если вопрос требует не карты проекта, а внимательного чтения конкретной реализации.

То есть это снова не «серебряная пуля» для разработки. Но инструмент может быть полезным для больших репозиториев.