Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 9
ладно, убедили, пошел тестить
UPD
сходу хочу сказать что не хватает md-индексации
у меня в обсидиане целая цивилизация и с кодовым агентом удобно там грестись - векторный mcp стал бы вообще манной небесной
потыкал по разному, посмотрел исходный код и вот отчет:
прикольно но не для всех так сказать. Растягивать на весь диск небезопасно да и ресурсоемко. А по проектам это нужно каждый раз руками запускать, индексировать, подключать mcp и так далее. На пробу поэкспериментировал с созданием скила что бы кодовый агент сам запускал, подключал, трекал и тд но получается фигня (в теории скил можно вылизать что бы оно все само, но то уже заниматься надо)
как оно индексирует я так до конца и не понял - на сложном го проекте с vendor, replace и внешними либами оно очень криво определяло что может либа и какой метод сюда б подтянуть и использовать
большие вещи ложат намертво - один из моих рабочих репозиториев 52гб чисто кода с гит-историей так вот его я так и не дождался индексации и кильнул раньше
в целом пока разбирался, по коду выглядит не слишком сложно как по мне. Может когда-то как очередной пет-проект попробую что то подобное сделать но уже на чистом Го или Расте (там векторных баз данных хватает классных)
буду ли я использовать? нет. родного mcp от jetbrains хватает с головой для работы с лексическим деревом проекта а все остальное агент погрепает сам. Преимущества работы "из коробки" перекрывают все преимущества тех процентов улучшения поиска.
52гб чисто кода с гит-историей
А за счёт чего такие цифры, если не секрет?
Спасибо, что не просто потыкали, а реально полезли в код и в граничные кейсы — такой фидбэк ценнее всего.
Сначала про рамку, она тут ключевая. graphlens — это библиотека/движок, а не продукт «поставил и работает». Это не отговорка, это зафиксированная область применения: в доке есть отдельный раздел Scope & Non-goals, где прямо перечислено, чего он сознательно не делает — https://neko1313.github.io/graphlens/docs/#scope--non-goals. Его задача — отдать структурный IR, а слой «само запускается, подключается, трекает» — ровно то, что строится сверху. Так что бóльшая часть трения, которое вы словили (ручной запуск, ручной MCP, скил-обвязка), — это отсутствующий продуктовый слой, и претензия честная. Скил — правильное направление, его надо вылизывать, и это отдельная работа, которую я пока не сделал.
По конкретике:
— «на весь диск»: оно индексирует не диск, а путь, который вы дали (graphlens analyze ./repo). Но да — то, что это надо запускать руками на каждый проект и потом руками цеплять MCP, реальное неудобство, спорить не с чем.
— Go с vendor / replace / внешними либами: честно слабое место. Type-aware рёбра резолвит gopls, и на vendored-зависимостях с replace в go.mod он требует правильно настроенного окружения, иначе кросс-модульные ссылки разрешаются криво — что вы и увидели. Если не лень, киньте issue с минимальным репро (go.mod с replace + vendor) — это прям полезный кейс, чтобы пофиксить настройку резолвера.
— 52 ГБ репо: это сильно за пределами того, на что оно сейчас рассчитано — граф целиком держится в памяти (для superset это ~170 МБ, у вас был бы порядок гигабайтов), так что «легло намертво» ожидаемо. Отдельно: индексируется дерево исходников, а не история гита; если оно реально полезло в .git — это баг и тоже повод для issue.
— про векторные БД: вот тут поправлю, это частое недопонимание. В graphlens нет ни вектора, ни эмбеддингов, ни семантического поиска — это даже вынесено отдельным пунктом в тот же раздел Non-goals по ссылке выше («not a vector index»). Внутри только tree-sitter (парсинг в CST) и LSP-резолверы, которые дают точные рёбра по типам, а не «похожие по смыслу». Если соберёте пет-проект на Го/Расте с векторной БД — это будет другой инструмент, решающий другую задачу (семантический поиск). Здесь вектора нет принципиально, и не из-за языка.
А теперь главное — про «не буду использовать, jetbrains-mcp + греп хватает». Вы пришли ровно к тому выводу, который я измерял отдельным бенчмарком — https://github.com/Neko1313/agent-context-bench. Там я специально разделял результаты по типу задач: на простых («где определён», «от чего наследуется») все инструменты, включая греп, равны по точности, и удобство «из коробки» спокойно перекрывает пару процентов на поиске. Структурный граф окупается только на тяжёлых вопросах — радиус поражения, наборы переопределений, разрешение одноимённых методов; нет такой работы — родного тулинга правда достаточно. Так что это не «вы не оценили», а «вы независимо подтвердили числа». За это спасибо.
И раз код показался несложным — он таким и задуман: минимальное ядро это фича, а не недоработка, на нём проще строить. Контракт и IR под MIT, так что если дойдёт до пет-проекта на Расте — переиспользуйте без зазрения совести.
могло и не полезть в гит, а хватить чисто кода раз все только в память выгружается причем с оверхедом на графовость как я понимаю
за минимальное репо я даже хз, это исследовать надо, будет время сделаю. но не обещаю
учитывая что оно все в память тянет - весь диск на такое и не затянуть, а жаль. Все же пересечения с либами тоже важны и которые агенты тем и хороши что сразу смотрят либу локально, а не гуглят или галюцинируют как оно может быть
Чем бы дитя не тешилось …
Берем нормальный компилируемый язык. Меняем метод. Запускаем билд. Билд валится с сообщением об ошибке. Правим, запускаем билд. Повторяем. Агенту надо сделать два действия провести замену в одни месту и пересобрать проект.
далее у нас же есть тесты?
Запускаем тесты если валятся правим.
Если у вас нет нормального компилятора с проверкой типов и нет тестов, то АИ вас все равно не спасет - нет шанса проверить что он поменял то что надо и как надо.
По сути верно: строгий компилятор + плотные тесты — лучший оракул, что правка не сломала типы. Граф с этим не конкурирует.
Два момента, которые этот цикл не закрывает. Компилятор отвечает после правки и только про типовые поломки — а агенту надо понять, что и где менять, до (часто согласованно в N местах), и куча влияющих изменений компилируется чисто (смена семантики при той же сигнатуре, дефолты, сайд-эффекты). И жёсткие задачи в бенчмарке были на Python, где падающего билда на переименованный метод нет в принципе — там граф и выигрывал, потому что компилятора-оракула просто не существует.
Ну и граф ≠ «вместо компилятора». Find usages в вашей IDE — это и есть call-граф на LSP; вы ходите им по коду до правки, а не ломаете билд ради чтения ошибок. graphlens просто даёт агенту тот же find-usages, чтобы он не крутил build-fix-loop и не грепал.
Очень вовремя наткнулся на это сравнение. Как раз ломаю голову, как лучше организовать контекст для агента, который работает с кодовой базой сложного Telegram-бота: десятки обработчиков, цепочки состояний, мидлвари — глазу зацепиться непросто. Ваш вывод про зависимость от типа задачи выглядит логично: условно, для точечных правок grep’а хватит, а для рефакторинга цепочки диалогов хочется, чтобы агент видел структурный граф и семантику. Есть ли среди этих «рук» конфигурация, которую вы бы посоветовали для проектов с глубоко вложенной событийной логикой (FSM, вебхуки, очереди)? Или пока универсального рецепта нет, и под каждый класс задач — свой сервер?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сколько стоит контекст для кодового агента: grep vs граф vs LSP на большом проекте (936 прогонов)