QodeLoc: Open Source self-hosted AI-ассистент

Если ваша компания работает в оборонке, банках, промышленной автоматизации, телекоме или просто держит проприетарный код под замком, эта история про вас.

Я занимаюсь разработкой и архитектурой больше двадцати лет. Последние несколько лет значительную часть времени провожу внутри крупных кодовых баз в закрытых корпоративных контурах.

Наблюдать за тем, как разработчики работают в таких условиях, одновременно интересно и болезненно. Умные люди, сложный продукт, накопленная годами кодовая база на сотни тысяч строк. И при этом навигация по коду выглядит примерно так: grep, чтение заголовочных файлов, вопросы коллегам, Confluence с устаревшей документацией.

Параллельно я наблюдал, как команды в открытых компаниях получили Codex, Copilot, Cursor, Sourcegraph и прочее. Инструменты, которые за секунды отвечают на вопросы «что делает этот класс», «кто вызывает эту функцию», «где мне нужно внести изменение чтобы добавить новый тип события». Инструменты, которые сократили онбординг с месяцев до недель.

Разрыв очевидный. И закрыть его нечем.

Codex, GitHub Copilot, Cursor, Sourcegraph Cody работают через облако. Для команд с требованиями к безопасности это не опция. Не потому что инструменты плохие. Потому что исходный код нельзя отправлять за периметр. Политика безопасности, регуляторные требования, здравый смысл.

Существующие self-hosted альтернативы, Tabby, FauxPilot, закрывают только completion. Они не понимают архитектуру кодовой базы, не строят граф зависимостей, плохо справляются с C++. По сути это grep с языковой моделью поверх.

Я решил построить то, чего не было.

QodeLoc - это self-hosted AI-ассистент по кодовой базе, который работает полностью внутри вашей сети. Без облака, без передачи данных за периметр, без подписки.

Разработчик подключается через любой MCP-совместимый клиент прямо в своей IDE и задаёт вопросы на естественном языке. Система отвечает с учётом реальной архитектуры кодовой базы, а не просто ищет совпадения по тексту.

Принципиальное отличие от поискового подхода: QodeLoc воспринимает кодовую базу как граф знаний, а не как набор текстовых файлов. Функция - это не чанк текста. Это узел графа с вызывающими, вызываемыми, наследованием и принадлежностью к модулю. Именно это позволяет отвечать на вопросы, которые grep никогда не закроет.

В основе лежит RAG-архитектура, но адаптированная под код. Классический RAG режет документы на текстовые чанки фиксированного размера. Для кода это катастрофа: функция, разрезанная посередине, теряет смысл. Поэтому единица индексации в QodeLoc - семантическая единица кода: функция, класс, метод, пространство имён.

Индексирование. При первом запуске система обходит репозиторий. Каждый файл парсится через tree-sitter, инструмент статического анализа, который строит точное синтаксическое дерево без запуска компилятора. Из дерева извлекаются символы с метаданными: тип, полностью квалифицированное имя, диапазон строк, сигнатура.

Для каждого символа выполняется три операции: векторизация через локальную embedding-модель, построение графа зависимостей (вызовы, наследование, включения заголовков), запись в хранилища.

Индекс строится иерархически: репозиторий, модуль, символ. Это критично для больших кодовых баз с десятками тысяч символов, без иерархии точность поиска деградирует.

Инкрементальное обновление. После git pull система автоматически переиндексирует только изменившиеся файлы. Полная переиндексация не нужна. Время обновления пропорционально числу изменённых файлов, не размеру кодовой базы.

Поиск. При запросе от разработчика система выполняет гибридный поиск: ANN-поиск по векторам в Qdrant возвращает семантически похожие символы, затем DuckDB обогащает результаты графом зависимостей. К найденному символу добавляются его вызывающие, вызываемые и архитектурный контекст. Всё это передаётся в локальную языковую модель, которая формирует ответ.

Ветки и локальные изменения. Сервер держит стабильный индекс базовой ветки. Разработчик на feature-ветке передаёт содержимое своих открытых изменённых файлов напрямую в контекст запроса через MCP-параметр. Языковая модель получает одновременно архитектурный контекст из индекса и локальные правки разработчика.

Стек. C++23 для core engine, tree-sitter для AST-парсинга, Qdrant для векторного поиска, DuckDB для графа зависимостей, llama.cpp для локального запуска моделей, LiteLLM для маршрутизации между моделями, TypeScript MCP-сервер для интеграции с IDE. Всё open source, без лицензионных отчислений.

Целевая аудитория очевидна: любая команда разработки, которой политика безопасности запрещает отправлять код в облако.

Оборонно-промышленный комплекс и государственные заказчики. Банки и финансовые организации. Промышленная автоматизация и SCADA. Телеком. Медицинское ПО. Вендоры ERP, VMS, встроенных систем. Компании, работающие по требованиям 152-ФЗ, ГОСТ Р 57580, и другим регуляторным стандартам, которые фактически означают «никакого облака».

Решение принимается не разработчиком. Его принимает CTO или CISO, когда отвечает на вопрос «как дать команде AI-инструменты, не нарушая требования безопасности». До сих пор ответа не было. Теперь есть.

Несколько причин.

Во-первых, доверие. Инструмент для работы с проприетарным кодом в закрытом контуре обязан быть прозрачным. Закрытый self-hosted продукт вызывает у CISO закономерный вопрос: а что он делает внутри? Открытый исходный код этот вопрос снимает.

Во-вторых, скорость. Я хочу получить обратную связь от реальных команд, которые работают с реальными кодовыми базами, как можно быстрее. Это единственный способ понять, что работает, а что нет.

В-третьих, экосистема. MCP как протокол, Continue.dev как клиент, llama.cpp как runtime - весь стек строится на открытых компонентах. Логично быть частью этой экосистемы, а не надстраивать над ней закрытый слой.

Проект на стадии активной разработки. Первый PoC идёт на реальной production кодовой базе прямо сейчас.

Репозиторий открыт:

Там же архитектурная документация, инструкция по развёртыванию и описание всех компонентов.

Если вы работаете в команде с закрытым контуром и узнали в описании свою боль, напишите. Интересует любая обратная связь: какие сценарии наиболее болезненные, какой стек используете, какие ограничения накладывает ваша среда.

Если вы разработчик и хотите поучаствовать в проекте, ещё лучше. Issues и PR открыты.

Инструмент строится для людей, которые не могут позволить себе облако. Было бы странно строить его без них.