Комментарии 6
ладно, убедили, пошел тестить
UPD
сходу хочу сказать что не хватает md-индексации
у меня в обсидиане целая цивилизация и с кодовым агентом удобно там грестись - векторный mcp стал бы вообще манной небесной
потыкал по разному, посмотрел исходный код и вот отчет:
прикольно но не для всех так сказать. Растягивать на весь диск небезопасно да и ресурсоемко. А по проектам это нужно каждый раз руками запускать, индексировать, подключать mcp и так далее. На пробу поэкспериментировал с созданием скила что бы кодовый агент сам запускал, подключал, трекал и тд но получается фигня (в теории скил можно вылизать что бы оно все само, но то уже заниматься надо)
как оно индексирует я так до конца и не понял - на сложном го проекте с vendor, replace и внешними либами оно очень криво определяло что может либа и какой метод сюда б подтянуть и использовать
большие вещи ложат намертво - один из моих рабочих репозиториев 52гб чисто кода с гит-историей так вот его я так и не дождался индексации и кильнул раньше
в целом пока разбирался, по коду выглядит не слишком сложно как по мне. Может когда-то как очередной пет-проект попробую что то подобное сделать но уже на чистом Го или Расте (там векторных баз данных хватает классных)
буду ли я использовать? нет. родного mcp от jetbrains хватает с головой для работы с лексическим деревом проекта а все остальное агент погрепает сам. Преимущества работы "из коробки" перекрывают все преимущества тех процентов улучшения поиска.
Чем бы дитя не тешилось …
Берем нормальный компилируемый язык. Меняем метод. Запускаем билд. Билд валится с сообщением об ошибке. Правим, запускаем билд. Повторяем. Агенту надо сделать два действия провести замену в одни месту и пересобрать проект.
далее у нас же есть тесты?
Запускаем тесты если валятся правим.
Если у вас нет нормального компилятора с проверкой типов и нет тестов, то АИ вас все равно не спасет - нет шанса проверить что он поменял то что надо и как надо.
Очень вовремя наткнулся на это сравнение. Как раз ломаю голову, как лучше организовать контекст для агента, который работает с кодовой базой сложного Telegram-бота: десятки обработчиков, цепочки состояний, мидлвари — глазу зацепиться непросто. Ваш вывод про зависимость от типа задачи выглядит логично: условно, для точечных правок grep’а хватит, а для рефакторинга цепочки диалогов хочется, чтобы агент видел структурный граф и семантику. Есть ли среди этих «рук» конфигурация, которую вы бы посоветовали для проектов с глубоко вложенной событийной логикой (FSM, вебхуки, очереди)? Или пока универсального рецепта нет, и под каждый класс задач — свой сервер?

Сколько стоит контекст для кодового агента: grep vs граф vs LSP на большом проекте (936 прогонов)