GLM-5, Qwen3 Coder Next и Kimi 2.5 сейчас выглядят довольно перспективно для задач анализа кода. Я пока не успел протестировать их в рамках этого эксперимента, но это хороший кандидат для следующего сравнения моделей.

Думаю попробовать провести ещё один эксперимент и добавить туда больше моделей, чтобы посмотреть, как они ведут себя на реальных Pull Request и насколько отличаются по глубине анализа и качеству предложенных исправлений.

Спасибо за предложение - обязательно возьму их в список для следующей статьи)

В моём случае RAG реализован через комбинацию локальных эмбеддингов, векторной базы данных и алгоритма BM25. Если кратко описать процесс:

1. При первом запуске инструмент читает файлы репозитория, разбивает их на фрагменты и строит для них векторные представления (embeddings).

2. Эти данные индексируются и кешируются, чтобы при последующих запусках не перегружать ПК или сервер повторной обработкой всей кодовой базы.

3. Когда модели нужен дополнительный контекст, выполняется поиск по индексу: используется комбинация семантического поиска по эмбеддингам и BM25, чтобы находить наиболее релевантные куски кода.

4. Найденные фрагменты затем передаются модели как дополнительный контекст для анализа PR.

По сути это гибридный поиск: частично семантический, частично текстовый, чтобы лучше находить нужные участки кода.

Если честно, вся реализация получилась довольно объёмной, и, пожалуй, это тема для отдельной статьи, где можно подробно разобрать архитектуру RAG в проекте и все нюансы его работы.

Поэтому в статье используется несколько метрик: accuracy, depth, hallucination, practical fixes и human acceptance rate. Я смотрел не только на количество комментариев, но и на то, насколько они реальны, аргументированы и полезны разработчику.

Например, модель может написать 27 комментариев, но если половина из них - поверхностные замечания или ложные срабатывания, то такое ревью не обязательно будет лучше, чем 9 более точных и полезных комментариев.

Поэтому итоговая оценка складывается из качества замечаний, их применимости и вероятности того, что разработчик действительно воспользуется рекомендациями.

Пока это скорее практическое наблюдение, а не формализованная метрика - я не проводил отдельного замера времени ревью «до/после» или количества багфиксов после мержа. Но идея очень интересная: можно попробовать сделать более системный эксперимент и замерить такие показатели.

Спасибо за идею - это действительно может стать хорошим продолжением статьи)

Добавить чтение диффа между ветками технически несложно, это логичный следующий шаг для нашего CLI. Учтем этот момент и добавим соответствующие аргументы в следующей версии. Спасибо за идею!

Часто разработчики используют тяжелые IDE (например, продукты JetBrains) параллельно с другими редакторами ради AI-плагинов. Это создает постоянное неудобство из-за переключения окон и контекста.

Наш CLI решает эту проблему: вы просто пишете одну команду в привычном терминале прямо перед коммитом и получаете быстрый аудит диффа, независимо от того, в чем вы писали код

Наша цель - сделать open-source инструмент, который:

1. может работать внутри изолированного контура (On-Premise);

2. поддерживает локальные модели вроде Ollama;

3. и понимает контекст проекта через RAG.

Кстати, а какие из существующих ботов вы пробовали на практике?
Буду признателен, если поделитесь, что в них понравилось, а что раздражало - это сильно поможет нам не наступить на чужие грабли 🙂

Во-первых, мы не привязаны к одной LLM. В конфиге можно переключиться на Gemini или любой API через OpenRouter (GPT-4, Claude и т.д.), где с длиной контекста проблем нет.

Во-вторых, RAG не предназначен для загрузки “больших данных” в контекст. Его задача - точно извлечь релевантные куски.

В нашем случае это обычно 2–3 файла, связанные с Merge Request.

Для пре-коммит ревью этого более чем достаточно, чтобы ловить реальные баги, а не считать ножки у птичек 🙂

В версии Alpha 0.3.5 мы отказались от обязательного использования флага --command. Теперь работа с CLI стала интуитивнее и быстрее.

❌ Было: codefox --command scan

✅ Стало: codefox scan (и codefox init соответственно).

Чтобы обновиться до актуальной версии, выполните:
pip install --upgrade codefox

или

uv tool upgrade codefox

Позвольте пояснить, как это исправить прямо сейчас:

1. Запрос токена: Команда init просит токен, так как мы заложили поддержку облака Ollama Cloud. Но для работы строго локально этот шаг нужно просто пропустить (ввести null ). Вы правы, для локального инструмента это сбивает с толку. В следующем минорном патче я сделаю локальный режим дефолтным, чтобы токен запрашивался только при явном выборе облака.

2. Ошибка 404 (model not found): Эта ошибка от самой Ollama означает, что на вашем жестком диске еще нет весов этой модели. CodeFox пока не умеет скачивать их автоматически. Чтобы всё заработало, нужно предварительно выполнить в терминале: ollama pull gemma3:12b (или имя той модели, которую вы выбрали).

Посмотреть скачанные у вас модели можно командой codefox --command list (или на локальной машине через команду ollama list).

В следующий версии обязательно добавим авто-скачивание моделей и уберу обязательный вопрос про токен в новой Alpha-версии. Будем рады, если дадите инструменту второй шанс!