Тут скорее сыграл человеческий фактор - честно говоря, я просто не заметил, что уже была доступна версия DeepSeek v3.2 на момент тестирования. Спасибо, что обратили внимание. Попробую прогнать её по той же методике и сравнить результаты.
По сути у вас есть несколько справедливых замечаний. Да, в статье стоило чётче разделить локальный Ollama и Ollama Cloud: аргумент про NDA относится именно к локальному запуску, а не должен автоматически переноситься на облачный сервис. Да, отсутствие данных о точности/квантовании - это ограничение сравнения, и его стоило обозначить явно. Моя цель была не доказать, что Ollama Cloud "лучше всех", а сравнить качество ответов моделей в конкретном интерфейсе и сценарии code review. Но замечание про прозрачность провайдеров и data policy для облака абсолютно уместно.
GLM-5, Qwen3 Coder Next и Kimi 2.5 сейчас выглядят довольно перспективно для задач анализа кода. Я пока не успел протестировать их в рамках этого эксперимента, но это хороший кандидат для следующего сравнения моделей.
Думаю попробовать провести ещё один эксперимент и добавить туда больше моделей, чтобы посмотреть, как они ведут себя на реальных Pull Request и насколько отличаются по глубине анализа и качеству предложенных исправлений.
Спасибо за предложение - обязательно возьму их в список для следующей статьи)
Спасибо за вопрос, на самом деле всё устроено немного сложнее, чем просто grep по файлам.
В моём случае RAG реализован через комбинацию локальных эмбеддингов, векторной базы данных и алгоритма BM25. Если кратко описать процесс:
При первом запуске инструмент читает файлы репозитория, разбивает их на фрагменты и строит для них векторные представления (embeddings).
Эти данные индексируются и кешируются, чтобы при последующих запусках не перегружать ПК или сервер повторной обработкой всей кодовой базы.
Когда модели нужен дополнительный контекст, выполняется поиск по индексу: используется комбинация семантического поиска по эмбеддингам и BM25, чтобы находить наиболее релевантные куски кода.
Найденные фрагменты затем передаются модели как дополнительный контекст для анализа PR.
По сути это гибридный поиск: частично семантический, частично текстовый, чтобы лучше находить нужные участки кода.
Если честно, вся реализация получилась довольно объёмной, и, пожалуй, это тема для отдельной статьи, где можно подробно разобрать архитектуру RAG в проекте и все нюансы его работы.
Хороший вопрос. Я не оценивал модели только по количеству найденных проблем, потому что это действительно может искажать результат. Если модель нашла одну проблему, это само по себе не означает, что ревью было качественным.
Поэтому в статье используется несколько метрик: accuracy, depth, hallucination, practical fixes и human acceptance rate. Я смотрел не только на количество комментариев, но и на то, насколько они реальны, аргументированы и полезны разработчику.
Например, модель может написать 27 комментариев, но если половина из них - поверхностные замечания или ложные срабатывания, то такое ревью не обязательно будет лучше, чем 9 более точных и полезных комментариев.
Поэтому итоговая оценка складывается из качества замечаний, их применимости и вероятности того, что разработчик действительно воспользуется рекомендациями.
Спасибо за интересный вопрос. На практике я действительно ежедневно использую свой инструмент для этих целей на работе, и по наблюдениям количество багов, которые доходят до этапа ревью или продакшена, снизилось примерно в 1.5-2 раза.
Пока это скорее практическое наблюдение, а не формализованная метрика - я не проводил отдельного замера времени ревью «до/после» или количества багфиксов после мержа. Но идея очень интересная: можно попробовать сделать более системный эксперимент и замерить такие показатели.
Спасибо за идею - это действительно может стать хорошим продолжением статьи)
Помимо diff, как я писал в статье, я использовал RAG. Это позволяло моделям при необходимости получать дополнительный контекст из файлов репозитория и анализировать не только изменения в PR, но и связанные части кодовой базы
Привет! Да, 100% согласны. Текущий вариант хорош для "самопроверки" (pre-commit), но для роли ревьюера нужно сравнивать ветки целиком.
Добавить чтение диффа между ветками технически несложно, это логичный следующий шаг для нашего CLI. Учтем этот момент и добавим соответствующие аргументы в следующей версии. Спасибо за идею!
Здравствуйте! Мы выбрали формат CLI по одной главной причине - независимость от среды разработки.
Часто разработчики используют тяжелые IDE (например, продукты JetBrains) параллельно с другими редакторами ради AI-плагинов. Это создает постоянное неудобство из-за переключения окон и контекста.
Наш CLI решает эту проблему: вы просто пишете одну команду в привычном терминале прямо перед коммитом и получаете быстрый аудит диффа, независимо от того, в чем вы писали код
Всё так, инструментов действительно много. Но большинство из них - либо платные SaaS-решения, либо довольно простые скрипты, которые требуют отправки кода во внешний API.
Наша цель - сделать open-source инструмент, который:
может работать внутри изолированного контура (On-Premise);
поддерживает локальные модели вроде Ollama;
и понимает контекст проекта через RAG.
Кстати, а какие из существующих ботов вы пробовали на практике? Буду признателен, если поделитесь, что в них понравилось, а что раздражало - это сильно поможет нам не наступить на чужие грабли 🙂
Справедливое замечание - если пытаться запихнуть весь проект в 7B модель. Но архитектура CodeFox работает иначе.
Во-первых, мы не привязаны к одной LLM. В конфиге можно переключиться на Gemini или любой API через OpenRouter (GPT-4, Claude и т.д.), где с длиной контекста проблем нет.
Во-вторых, RAG не предназначен для загрузки “больших данных” в контекст. Его задача - точно извлечь релевантные куски.
В нашем случае это обычно 2–3 файла, связанные с Merge Request.
Для пре-коммит ревью этого более чем достаточно, чтобы ловить реальные баги, а не считать ножки у птичек 🙂
Спасибо большое за развернутое пожелание! Да, мы как раз смотрим в эту сторону. Интеграция с MCP-серверами идеально ложится в нашу концепцию умного ревью. Одно дело - просто читать соседние файлы через RAG, и совсем другое - дать модели доступ к ADR и документации проекта при ревью Merge Request'ов. Это у нас уже есть в планах на следующие мажорные версии)
Добрый день! Да, 100% планируется! :-) Для пайплайнов мы готовим отдельную утилиту - это будут полноценные боты для GitLab CI и GitHub Actions, которые смогут делать ревью и писать inline-комментарии прямо в Merge Request
Добрый день! Спасибо за честный фидбек, вы абсолютно правы - сейчас этот шаг выглядит неинтуитивно, простите за путаницу! 🙏
Позвольте пояснить, как это исправить прямо сейчас:
Запрос токена: Команда init просит токен, так как мы заложили поддержку облака Ollama Cloud. Но для работы строго локально этот шаг нужно просто пропустить (ввести null ). Вы правы, для локального инструмента это сбивает с толку. В следующем минорном патче я сделаю локальный режим дефолтным, чтобы токен запрашивался только при явном выборе облака.
Ошибка 404 (model not found): Эта ошибка от самой Ollama означает, что на вашем жестком диске еще нет весов этой модели. CodeFox пока не умеет скачивать их автоматически. Чтобы всё заработало, нужно предварительно выполнить в терминале: ollama pull gemma3:12b (или имя той модели, которую вы выбрали).
Посмотреть скачанные у вас модели можно командой codefox --command list (или на локальной машине через команду ollama list).
В следующий версии обязательно добавим авто-скачивание моделей и уберу обязательный вопрос про токен в новой Alpha-версии. Будем рады, если дадите инструменту второй шанс!
Тут скорее сыграл человеческий фактор - честно говоря, я просто не заметил, что уже была доступна версия DeepSeek v3.2 на момент тестирования. Спасибо, что обратили внимание. Попробую прогнать её по той же методике и сравнить результаты.
По сути у вас есть несколько справедливых замечаний.
Да, в статье стоило чётче разделить локальный Ollama и Ollama Cloud: аргумент про NDA относится именно к локальному запуску, а не должен автоматически переноситься на облачный сервис.
Да, отсутствие данных о точности/квантовании - это ограничение сравнения, и его стоило обозначить явно.
Моя цель была не доказать, что Ollama Cloud "лучше всех", а сравнить качество ответов моделей в конкретном интерфейсе и сценарии code review. Но замечание про прозрачность провайдеров и data policy для облака абсолютно уместно.
Спасибо за идею, список действительно интересный.
GLM-5, Qwen3 Coder Next и Kimi 2.5 сейчас выглядят довольно перспективно для задач анализа кода. Я пока не успел протестировать их в рамках этого эксперимента, но это хороший кандидат для следующего сравнения моделей.
Думаю попробовать провести ещё один эксперимент и добавить туда больше моделей, чтобы посмотреть, как они ведут себя на реальных Pull Request и насколько отличаются по глубине анализа и качеству предложенных исправлений.
Спасибо за предложение - обязательно возьму их в список для следующей статьи)
Спасибо за вопрос, на самом деле всё устроено немного сложнее, чем просто
grepпо файлам.В моём случае RAG реализован через комбинацию локальных эмбеддингов, векторной базы данных и алгоритма BM25. Если кратко описать процесс:
При первом запуске инструмент читает файлы репозитория, разбивает их на фрагменты и строит для них векторные представления (embeddings).
Эти данные индексируются и кешируются, чтобы при последующих запусках не перегружать ПК или сервер повторной обработкой всей кодовой базы.
Когда модели нужен дополнительный контекст, выполняется поиск по индексу: используется комбинация семантического поиска по эмбеддингам и BM25, чтобы находить наиболее релевантные куски кода.
Найденные фрагменты затем передаются модели как дополнительный контекст для анализа PR.
По сути это гибридный поиск: частично семантический, частично текстовый, чтобы лучше находить нужные участки кода.
Если честно, вся реализация получилась довольно объёмной, и, пожалуй, это тема для отдельной статьи, где можно подробно разобрать архитектуру RAG в проекте и все нюансы его работы.
Хороший вопрос. Я не оценивал модели только по количеству найденных проблем, потому что это действительно может искажать результат. Если модель нашла одну проблему, это само по себе не означает, что ревью было качественным.
Поэтому в статье используется несколько метрик: accuracy, depth, hallucination, practical fixes и human acceptance rate. Я смотрел не только на количество комментариев, но и на то, насколько они реальны, аргументированы и полезны разработчику.
Например, модель может написать 27 комментариев, но если половина из них - поверхностные замечания или ложные срабатывания, то такое ревью не обязательно будет лучше, чем 9 более точных и полезных комментариев.
Поэтому итоговая оценка складывается из качества замечаний, их применимости и вероятности того, что разработчик действительно воспользуется рекомендациями.
Спасибо за интересный вопрос. На практике я действительно ежедневно использую свой инструмент для этих целей на работе, и по наблюдениям количество багов, которые доходят до этапа ревью или продакшена, снизилось примерно в 1.5-2 раза.
Пока это скорее практическое наблюдение, а не формализованная метрика - я не проводил отдельного замера времени ревью «до/после» или количества багфиксов после мержа. Но идея очень интересная: можно попробовать сделать более системный эксперимент и замерить такие показатели.
Спасибо за идею - это действительно может стать хорошим продолжением статьи)
Помимо diff, как я писал в статье, я использовал RAG. Это позволяло моделям при необходимости получать дополнительный контекст из файлов репозитория и анализировать не только изменения в PR, но и связанные части кодовой базы
Привет! Да, 100% согласны. Текущий вариант хорош для "самопроверки" (pre-commit), но для роли ревьюера нужно сравнивать ветки целиком.
Добавить чтение диффа между ветками технически несложно, это логичный следующий шаг для нашего CLI. Учтем этот момент и добавим соответствующие аргументы в следующей версии. Спасибо за идею!
Здравствуйте! Мы выбрали формат CLI по одной главной причине - независимость от среды разработки.
Часто разработчики используют тяжелые IDE (например, продукты JetBrains) параллельно с другими редакторами ради AI-плагинов. Это создает постоянное неудобство из-за переключения окон и контекста.
Наш CLI решает эту проблему: вы просто пишете одну команду в привычном терминале прямо перед коммитом и получаете быстрый аудит диффа, независимо от того, в чем вы писали код
Всё так, инструментов действительно много.
Но большинство из них - либо платные SaaS-решения, либо довольно простые скрипты, которые требуют отправки кода во внешний API.
Наша цель - сделать open-source инструмент, который:
может работать внутри изолированного контура (On-Premise);
поддерживает локальные модели вроде Ollama;
и понимает контекст проекта через RAG.
Кстати, а какие из существующих ботов вы пробовали на практике?
Буду признателен, если поделитесь, что в них понравилось, а что раздражало - это сильно поможет нам не наступить на чужие грабли 🙂
Справедливое замечание - если пытаться запихнуть весь проект в 7B модель.
Но архитектура CodeFox работает иначе.
Во-первых, мы не привязаны к одной LLM. В конфиге можно переключиться на Gemini или любой API через OpenRouter (GPT-4, Claude и т.д.), где с длиной контекста проблем нет.
Во-вторых, RAG не предназначен для загрузки “больших данных” в контекст. Его задача - точно извлечь релевантные куски.
В нашем случае это обычно 2–3 файла, связанные с Merge Request.
Для пре-коммит ревью этого более чем достаточно, чтобы ловить реальные баги, а не считать ножки у птичек 🙂
Спасибо большое за развернутое пожелание! Да, мы как раз смотрим в эту сторону. Интеграция с MCP-серверами идеально ложится в нашу концепцию умного ревью. Одно дело - просто читать соседние файлы через RAG, и совсем другое - дать модели доступ к ADR и документации проекта при ревью Merge Request'ов. Это у нас уже есть в планах на следующие мажорные версии)
Добрый день! Да, 100% планируется! :-)
Для пайплайнов мы готовим отдельную утилиту - это будут полноценные боты для GitLab CI и GitHub Actions, которые смогут делать ревью и писать inline-комментарии прямо в Merge Request
UPDATE (Alpha 0.3.5): Упростили синтаксис!
В версии Alpha 0.3.5 мы отказались от обязательного использования флага
--command. Теперь работа с CLI стала интуитивнее и быстрее.❌ Было:
codefox --command scan✅ Стало:
codefox scan(иcodefox initсоответственно).Чтобы обновиться до актуальной версии, выполните:
pip install --upgrade codefoxили
uv tool upgrade codefoxДобрый день! Спасибо за честный фидбек, вы абсолютно правы - сейчас этот шаг выглядит неинтуитивно, простите за путаницу! 🙏
Позвольте пояснить, как это исправить прямо сейчас:
Запрос токена: Команда
initпросит токен, так как мы заложили поддержку облака Ollama Cloud. Но для работы строго локально этот шаг нужно просто пропустить (ввестиnull). Вы правы, для локального инструмента это сбивает с толку. В следующем минорном патче я сделаю локальный режим дефолтным, чтобы токен запрашивался только при явном выборе облака.Ошибка 404 (model not found): Эта ошибка от самой Ollama означает, что на вашем жестком диске еще нет весов этой модели. CodeFox пока не умеет скачивать их автоматически. Чтобы всё заработало, нужно предварительно выполнить в терминале:
ollama pull gemma3:12b(или имя той модели, которую вы выбрали).Посмотреть скачанные у вас модели можно командой
codefox --command list(или на локальной машине через командуollama list).В следующий версии обязательно добавим авто-скачивание моделей и уберу обязательный вопрос про токен в новой Alpha-версии. Будем рады, если дадите инструменту второй шанс!