Когда я начал активно использовать ИИ-агентов для разработки, у меня быстро появилось странное ощущение - c одной стороны, это действительно впечатляет. Агент быстро читает код, находит нужные места, предлагает исправления, пишет тесты и очень уверенно объясняет, что он сделал. С другой стороны, именно эта уверенность иногда и пугает.
Агент может найти функцию, изменить несколько строк и сказать:
Готово, я исправил обработку данных.
Но как разработчик я хочу знать другое:
он точно смотрел в тот репозиторий?
он нашёл именно нужную функцию, а не похожее имя?
кто ещё вызывает эту функцию?
какие сценарии выполнения затронуты?
какие тесты надо запустить?
не изменил ли он лишние файлы?
Обычный поиск по коду на эти вопросы не отвечает.
Так появился OntoIndex (как форк GitNexus для поддержки кодовых баз , где более 10 тыс файлов).
OntoIndex — это локальный граф кода для ИИ-агентов. Он индексирует репозиторий, строит связи между файлами, функциями, классами, вызовами, тестами и документацией, а затем отдаёт этот контекст через MCP, командную строку и веб-интерфейс. Главная идея простая: агент должен не просто находить код. Он должен понимать, что с этим кодом связано.
Почему поиска уже мало
Я люблю простые инструменты. grep и ripgrep прекрасны. Когда нужно быстро найти строку в проекте, они делают это идеально. Но поиск отвечает только на вопрос:
Где это написано?
А в реальной разработке чаще важнее другой вопрос:
Что от этого зависит?
Представьте электрика в старом доме. Он нашёл нужный провод в стене и говорит: «Вот он, сейчас перережу».
Формально он нашёл провод. Но хороший электрик сначала проверит, куда он идёт: не запитан ли от него другой этаж, холодильник, сервер или сигнализация.
С кодом то же самое.
Функция — это не просто текст в файле. Её могут вызывать другие модули. Через неё может проходить важный сценарий. На неё может опираться тест. Её поведение может быть описано в документации. Если ИИ-агент меняет такую функцию, ему мало знать, где она лежит. Ему нужна карта связей. Ошибка не всегда в модели Ошибки ИИ-агентов часто называют «галлюцинациями». Но в разработке проблема нередко другая: агент рассуждает логично, но по плохому контексту.
Типичный сценарий выглядит так:
найти файл изменить код запустить один тест уверенно объяснить результат
Для маленького проекта это иногда работает. Для большого репозитория — это уже риск. Перед изменением агент должен пройти хотя бы минимальную проверку:
я в правильном репозитории? индекс свежий? символ найден точно? кто от него зависит? какие файлы изменились? какие тесты подтверждают правку? можно ли фиксировать изменения?
Это не бюрократия. Это обычная инженерная гигиена. OntoIndex нужен именно для этого: дать агенту локальную карту проекта и набор проверок перед тем, как он начнёт менять код.
Что делает OntoIndex - он строит граф кода внутри проекта.
В граф попадают:
файлы функции классы методы вызовы маршруты тесты документация
И связи между ними:
файл определяет функцию функция вызывает другую функцию тест проверяет поведение документация описывает требование изменение затрагивает сценарий выполнения
После этого проект перестаёт быть для агента просто папкой с файлами. Он становится картой. Агент может спросить не только «где встречается это имя», но и:
кто вызывает эту функцию;
какие места зависят от этого класса;
какие тесты связаны с изменённым кодом;
какие документы могут устареть;
какие изменения оказались неожиданными.
Для меня это ключевой момент: не заставлять модель лучше угадывать, а дать ей возможность проверять себя.
Почему важен локальный граф
Я сознательно делал OntoIndex как локальный инструмент. Код остаётся у разработчика. Индекс строится рядом с проектом. Агент получает доступ к структуре через локальный слой, без необходимости отправлять весь репозиторий во внешний сервис. Для личных проектов это удобно. Для корпоративной разработки это принципиально.
Команды часто хотят использовать ИИ, но быстро упираются в вопросы безопасности:
куда уйдёт код;
где будет храниться индекс;
можно ли подключать закрытые репозитории;
что скажет служба безопасности.
Локальный граф не решает все организационные вопросы, но делает архитектуру спокойнее и понятнее.
60+ MCP-функций поверх графа кода
OntoIndex — это не одна большая команда «найди мне код». Поверх локального графа есть набор MCP-функций, из которых агент может собрать нормальный инженерный маршрут.
Например:
gn_ensure_fresh— проверить, что индекс не устарел;gn_safe_edit_check— оценить риск перед изменением кода;gn_find_related— найти связанные места;gn_verify_diff— проверить, что изменилось именно то, что ожидалось;gn_test_gap— понять, хватает ли тестового подтверждения;gn_pre_commit_audit— проверить изменения перед фиксацией.
Смысл не в количестве функций.
Смысл в том, что агент получает привычку проверять работу по шагам.
Не просто:
я нашёл файл и изменил код
А так:
я проверил репозиторийя проверил свежесть индексая нашёл точный символя оценил влияниея изменил ожидаемые файлыя проверил набор измененийя связал правку с тестами
Это уже ближе к нормальному инженерному процессу.
Где здесь другие решения
Сейчас появляется много инструментов вокруг графов кода и MCP: Graphify, Serena, CodeGraphContext, CodeGPT Deep Graph MCP и другие. Я не думаю, что здесь будет один победитель. У этих решений разные акценты.
Graphify полезен, когда нужно строить широкий граф знаний по разным материалам проекта.
Serena сильна в точной символической навигации и операциях, похожих на возможности среды разработки.
CodeGraphContext тоже работает в области локального графового контекста по коду.
CodeGPT Deep Graph MCP больше подходит, если граф уже живёт во внешней платформе.
OntoIndex я делаю с другим акцентом: локальный граф кода как проверочный слой для ИИ-агента перед изменением, проверкой и фиксацией результата.
То есть главный вопрос не «где находится код», а:
Что изменится, если агент его тронет?
Я не верю, что безопасность ИИ-разработки появится сама собой только потому, что модели станут мощнее. Более сильная модель будет быстрее писать код. Но это не значит, что она автоматически будет лучше понимать границы изменения. Нам нужны не только умные агенты.
Нам нужны агенты, которые умеют проверять себя.
OntoIndex — моя попытка дать агенту такую возможность: локальную карту проекта, понимание связей и набор проверок перед тем, как изменения попадут в репозиторий.
Он не заменяет разработчика.
Он не заменяет тесты.
Он не заменяет проверку кода человеком.
Но он добавляет то, чего ИИ-агенту обычно не хватает: проверяемый контекст.
Подробности, установка, список MCP-функций и примеры использования — на странице проекта OntoIndex.
