С недавних пор AI-инструменты стали важной частью разработки.
Такие решения, как Cursor, Codex и Claude Code позволяют разработчикам генерировать код, ускорять написание функций и автоматизировать рутинные задачи.
Это существенно повышает скорость разработки. Однако у такого подхода есть и обратная сторона: код начинает появляться быстрее, чем команды успевают его качественно проверять.
В результате нагрузка на процесс code review растёт. Именно поэтому всё чаще возникает вопрос: могут ли сами LLM помогать разработчикам проверять код?
В этой статье я решил проверить, насколько хорошо облачные модели из Ollama справляются с задачами code review, и сравнить их ответы на реальных Pull Request.

Содержание


Цель статьи

Проверить, насколько современные LLM, доступные через Ollama, способны выполнять качественный code review на реальных Pull Request и какие модели показывают лучшие результаты.


Существующие решения и их проблемы

Перед тем как перейти к тестированию моделей, кратко рассмотрим существующие решения, их ограничения и почему для эксперимента был выбран Ollama.
На сегодняшний день уже существует несколько инструментов для AI-code review: CodeRabbit, Claude Review, QoDo. Это облачные сервисы, которые интегрируются с GitHub, GitLab или IDE и автоматически анализируют изменения в Pull Request.

Как правило, такие инструменты выполняют несколько основных задач:

  • анализируют diff в Pull Request;

  • ищут потенциальные баги, security-уязвимости и плохие практики;

  • оставляют комментарии непосредственно в Pull Request;

  • предлагают возможные исправления.

Например, CodeRabbit может выступать в роли «первого ревьюера», автоматически проверяя код и указывая на потенциальные проблемы ещё до того, как Pull Request посмотрит человек.

Такие инструменты хорошо вписываются в workflow разработчика и могут существенно ускорить процесс code review. Однако у большинства из них есть несколько общих ограничений:

  1. Стоимость. Большинство подобных решений являются платными сервисами, а при активном использовании стоимость может заметно расти вместе с количеством Pull Request.

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

  3. Ограниченная кастомизация. Во многих сервисах невозможно полностью настроить модель под конкретный проект: задать собственные правила ревью, архитектурные ограничения или корпоративные coding guidelines.

  4. Ограниченный контекст анализа. Часто модели анализируют только diff Pull Request и не имеют доступа к дополнительному контексту - документации, ADR (Architecture Decision Records) или архитектуре проекта. Это может снижать точность и глубину анализа.

  5. Отсутствие поддержки локальных моделей. В большинстве перечисленных решений нельзя использовать собственные или локально развернутые модели, что ограничивает гибкость и возможность экспериментировать с различными LLM.

Таким образом, главная проблема заключается не только в цене или инфраструктуре, а в другом вопросе: какая модель действительно умеет делать качественный code review.
Именно это я и решил проверить на практике - сравнив несколько моделей на реальных Pull Request.


Почему именно Ollama Cloud?

Но возникает логичный вопрос: почему для тестирования я выбрал именно Ollama Cloud?

Основная причина заключается в том, что Ollama предоставляет удобный способ работать сразу с несколькими моделями. Это позволяет сравнивать разные LLM в одинаковых условиях и получать более объективные результаты.

Кроме того, Ollama позволяет:

  • быстро переключаться между моделями;

  • использовать как облачные, так и локальные LLM;

  • строить собственные инструменты поверх API;

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

Именно поэтому Ollama оказался удобной платформой для проведения сравнительного тестирования моделей в задачах code review.


Критерии оценки и модели

Для оценки качества AI-code review я буду использовать 5-балльную шкалу для каждой метрики.
Всего будет оцениваться 6 метрик, отражающих разные аспекты качества анализа кода.

Метрика

Описание

Accuracy

Насколько точно модель находит реальные проблемы в коде

Security awareness

Способность модели выявлять потенциальные уязвимости и security-риски

Hallucination

Склонность модели придумывать несуществующие проблемы

Depth

Глубина анализа и понимание контекста изменений

Practical fixes

Предлагает ли модель реальные и применимые исправления

Human acceptance rate

Доля комментариев, которые разработчики действительно принимают или используют

Для тестирования я выбрал три модели, доступные через Ollama:

  • Qwen 3.5 - это семейство больших языковых моделей от Alibaba, ориентированных на задачи программирования, reasoning и построение AI-агентов. Модель считается одной из самых сильных открытых LLM в своём классе и активно используется для генерации и анализа кода.

  • GPT-OSS - это открытая языковая модель, ориентированная на задачи программирования и анализа кода. Она предназначена для использования в разработке инструментов для генерации кода, автоматизации разработки и AI-code review.

  • DeepSeek v3.1 - это большая языковая модель от компании DeepSeek, ориентированная на задачи программирования, анализа кода и сложного reasoning. Модель является развитием семейства DeepSeek и предназначена для использования в developer-инструментах и AI-ассистентах.

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


Условия тестирования

Для тестирования на реальных Pull Request я буду использовать свой репозиторий четырёхлетней давности с легаси-проектом на Python.
У каждой модели будет отдельный Pull Request, однако для всех будет использоваться одинаковый промпт, чтобы сравнение было максимально корректным.
Все модели также будут использовать инструмент RAG, чтобы при необходимости получать дополнительный контекст из файлов проекта.

Все модели запускались в одинаковых условиях, с одинаковым промптом и доступом к одному и тому же контексту проекта.
Ниже приведена конфигурация, использованная для каждой модели.
Ссылки на репозиторий и инструмент, использованные в тестировании, будут приведены в конце статьи.

Qwen3.5
provider: ollama
model:
  name: qwen3.5:397b
  base_url: https://ollama.com
  temperature: 0.2
  max_tokens: 4000
review:
  severity: high
  max_issues: null
  suggest_fixes: true
  tools: true
  diff_only: false
baseline:
  enable: true
ruler:
  security: true
  performance: true
  style: true
prompt:
  system: null
  extra: null
  strict_facts: true
GPT-OSS
provider: ollama
model:
  name: gpt-oss:120b
  base_url: https://ollama.com
  temperature: 0.2
  max_tokens: 4000
review:
  severity: high
  max_issues: null
  suggest_fixes: true
  tools: true
  diff_only: false
baseline:
  enable: true
ruler:
  security: true
  performance: true
  style: true
prompt:
  system: null
  extra: null
  strict_facts: true
DeepSeek v3.1
provider: ollama
model:
  name: deepseek-v3.1:671b
  base_url: https://ollama.com
  temperature: 0.2
  think_mode: true
  max_tokens: 4000
review:
  severity: high
  max_issues: null
  suggest_fixes: true
  tools: true
  diff_only: false
baseline:
  enable: true
ruler:
  security: true
  performance: true
  style: true
prompt:
  system: null
  extra: null
  strict_facts: true

Тестовые Pull Request-ы

Из предисловия мы наконец переходим к самой интересной части - практическому тестированию моделей.

Qwen 3.5

Первой на очереди будет Qwen 3.5.
Pull Request:
Qwen3.5 code review #2

Ниже приведена таблица с итоговыми оценками.

Метрика

Оценка

Комментарий

Accuracy

4 / 5

Модель находит реальные проблемы в коде. Большинство замечаний корректны и привязаны к конкретным строкам diff.

Security awareness

3.5 / 5

Некоторые security-риски замечены, однако покрытие не полное. Отсутствует системный анализ потенциальных уязвимостей.

Hallucination

4 / 5

Низкая склонность к выдуманным проблемам. Комментарии в основном основаны на фактическом коде.

Depth

3.5 / 5

Анализ выходит за рамки поверхностного lint-ревью, однако архитектурный контекст рассматривается ограниченно.

Practical fixes

4 / 5

В ряде комментариев предложены конкретные и применимые исправления.

Human acceptance rate

4 / 5

Большинство комментариев конструктивны и связаны с реальными проблемами. Часть замечаний носит рекомендательный характер (style / refactor), поэтому разработчик может их проигнорировать.

Итоговая оценка: 3.8 балла.

От себя отмечу, что модель приятно удивила: она не только указывала на проблемы в коде, но и часто предлагала конкретные варианты исправлений, а комментарии в целом были конструктивными и полезными для разработчика.
Из недостатков можно отметить лишь то, что глубина анализа иногда могла бы быть выше. Кроме того, хотелось бы, чтобы Qwen 3.5 чаще использовала доступные инструменты для получения дополнительного контекста, что могло бы улучшить качество ревью.

GPT-OSS

Вторая на очереди будет GPT-OSS.
Pull Request:
GPT-OSS code review #3

Ниже приведена таблица с итоговыми оценками.

Метрика

Оценка (1–5)

Комментарий

Accuracy

3 / 5

Часть найденных проблем корректна, но присутствуют менее точные замечания и обобщения. Некоторые комментарии не полностью привязаны к конкретным изменениям в diff.

Security awareness

3 / 5

Базовые security-аспекты замечаются, однако анализ поверхностный. Нет системной проверки потенциальных уязвимостей (например, input validation, secrets, permission issues).

Hallucination

2.5 / 5

Иногда модель делает предположения о поведении кода без достаточного контекста. Появляются замечания, которые не всегда подтверждаются изменениями в PR.

Depth

3 / 5

Анализ в основном локальный и довольно поверхностный. Модель редко рассматривает архитектурные последствия изменений.

Practical fixes

3 / 5

Исправления предлагаются, но они чаще носят общий характер и не всегда содержат конкретный код.

Human acceptance rate

3 / 5

Часть комментариев может быть полезна разработчику, но значительная доля вероятно будет проигнорирована из-за обобщённости или слабой аргументации.

Итоговая оценка: 2.9 балла.

От себя отмечу, что результат работы модели оказался довольно разочаровывающим. Значительная часть комментариев носит общий характер и не всегда помогает разработчику принять конкретное решение по исправлению кода.
Кроме того, модель практически не предложила конкретных auto-fix, ограничившись лишь общими рекомендациями по возможным улучшениям. Это снижает практическую ценность такого ревью.
Из положительных сторон можно отметить неплохой стиль комментария - он написаны достаточно понятно и структурировано. Однако в целом хотелось бы увидеть более глубокий анализ и более конкретные предложения по исправлению проблем.

DeepSeek v3.1

Третий на очереди будет DeepSeek v3.1.
Pull Request:
DeepSeek-v3.1 code review #5

Примечание: сразу хочу отметить, что я снизил итоговую оценку DeepSeek v3.1 на 1 балл, поскольку модель не смогла использовать инструмент без включённого режима think.

Ниже приведена таблица с итоговыми оценками.

Метрика

Оценка (1–5)

Комментарий

Accuracy

4.5 / 5

Модель находит реальные проблемы и довольно точно объясняет причины. Замечания привязаны к конкретным строкам и логике кода.

Security awareness

4 / 5

Хорошо замечает security-риски (например управление секретами, небезопасные операции, потенциальные утечки). Не всегда проводит полный threat-analysis, но уровень выше среднего.

Hallucination

4 / 5

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

Depth

4.5 / 5

Глубокий анализ: объясняет причину проблемы, последствия и контекст изменения. Часто рассматривает эксплуатационный сценарий.

Practical fixes

4.5 / 5

Предлагает конкретные исправления и иногда пример кода. Fix-предложения применимы и инженерно корректны.

Human acceptance rate

4 / 5

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

Итоговая оценка: 3.25 (4.25) балла.

От себя отмечу, что DeepSeek v3.1 показала наиболее качественный анализ среди протестированных моделей. Комментарии получились достаточно лаконичными и при этом содержательными: модель объясняет причину проблемы, предлагает рекомендации и нередко приводит конкретные варианты исправлений (auto-fix), что для разработчика особенно полезно.
Из минусов можно отметить необходимость использования режима think, чтобы модель могла корректно работать с инструментами. Без него часть функциональности оказалась недоступной.
Тем не менее, даже с учётом этого ограничения DeepSeek v3.1 продемонстрировала самый глубокий и практичный code review среди протестированных моделей.


Итоговая сравнительная таблица

Модель

Accuracy

Security awareness

Hallucination

Depth

Practical fixes

Human acceptance rate

Итого

Qwen 3.5

4

3.5

4

3.5

4

4

3.8

GPT-OSS

3

3

2.5

3

3

3

2.9

DeepSeek v3.1

4.5

4

4

4.5

4.5

4

3.25 (4.25)


Вывод

Подводя итоги тестирования, можно сделать несколько наблюдений.

Во-первых, облачные модели через Ollama действительно можно использовать для задач code review, однако качество результата сильно зависит от выбранной модели и конфигурации инструмента. Некоторые модели показывают довольно поверхностный анализ, тогда как другие способны проводить достаточно глубокое ревью и даже предлагать конкретные исправления.

Во-вторых, важную роль играет настройка контекста и инструментов. При правильной конфигурации (например, использование RAG и доступ к файлам проекта) модели начинают лучше понимать кодовую базу и давать более точные рекомендации.

Когда стоит использовать Ollama для code review?

  • если проект содержит чувствительный код или ограничения NDA;

  • если важно, чтобы код не покидал инфраструктуру компании;

  • если есть возможность запускать модели локально на мощном сервере или рабочей станции.

В таких сценариях использование локальных моделей может стать хорошей альтернативой SaaS-решениям.

Когда Ollama может быть не лучшим выбором?
Если ограничения по безопасности отсутствуют и бюджет не является критичным фактором, то специализированные сервисы вроде CodeRabbit, Claude Review или QoDo могут обеспечить более стабильное качество ревью «из коробки», поскольку они используют собственные пайплайны анализа кода и дополнительные модели.

Тем не менее, проведённый эксперимент показал, что при правильной настройке инструмента и выборе подходящей модели LLM уже сегодня могут выступать полезным помощником в процессе code review.

Все эксперименты в статье проводились с помощью моего CLI-инструмента для AI-ревью - CodeFox-CLI, который позволяет подключать разные модели (не только Ollama), работать с контекстом проекта и автоматизировать анализ Pull Request.

Инструмент: CodeFox-CLI
Репозиторий: Demo-PR-Action

Комментарии (16)


  1. ToniDoni
    13.03.2026 20:40

    А какой контекст у моделей на ревью? Есть что то кроме дифа, и как она его получает, как он ей передается?
    К слову сейчас агенты могут по дифу найти всю необходимую информацию по проекту. Так что то, какой кодинг агент используется, не менее важно, чем модель.
    Если это просто послать по апишке модели в облако диф + RAG - это уже пастген,


    1. CodeFoxAI Автор
      13.03.2026 20:40

      Помимо diff, как я писал в статье, я использовал RAG. Это позволяло моделям при необходимости получать дополнительный контекст из файлов репозитория и анализировать не только изменения в PR, но и связанные части кодовой базы


      1. Sol0Zon3
        13.03.2026 20:40

        Было было интересно почитать, как именно у вас устроен rag? Это некий grep по файлам + чтение файлов, или особый способ семантического поиска по символам, как например работает в vscode #functionName или @someVariable?


        1. CodeFoxAI Автор
          13.03.2026 20:40

          Спасибо за вопрос, на самом деле всё устроено немного сложнее, чем просто grep по файлам.

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

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

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

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

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

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

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


          1. Sol0Zon3
            13.03.2026 20:40

            Спасибо за ответ, я бы такую статью с радостью прочитал)


  1. annagle
    13.03.2026 20:40

    хорошо, что поставили эксперимент на реальных PR и ввели в оценку человеческий acceptance rate — это сильно ближе к практике, чем просто «модель нашла N багов».Было бы интересно увидеть продолжение: пробовали ли вы мерить влияние этих моделей на реальное время ревью (до/после) и на количество багфиксов после мержа, чтобы понять, где отдача от LLM‑ревью максимальна?


    1. CodeFoxAI Автор
      13.03.2026 20:40

      Спасибо за интересный вопрос. На практике я действительно ежедневно использую свой инструмент для этих целей на работе, и по наблюдениям количество багов, которые доходят до этапа ревью или продакшена, снизилось примерно в 1.5-2 раза.

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

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


  1. AppCrafter
    13.03.2026 20:40

    Модель находит реальные проблемы в коде

    Как вы это определяете? Если модель находит только одну проблему, это тоже засчитывается? Хотя может на самом деле проблем может быть несколько и модель их не увидела.

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


    1. CodeFoxAI Автор
      13.03.2026 20:40

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

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

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

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


  1. Sol0Zon3
    13.03.2026 20:40

    Интересно было бы посмотреть сравнение ещё этих:

    Glm5

    Qwen3 Coder Next

    Kimi2.5


    1. CodeFoxAI Автор
      13.03.2026 20:40

      Спасибо за идею, список действительно интересный.

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

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

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


      1. dkeiz
        13.03.2026 20:40

        тут интереснее почему v3.1 а не v3.2, который на голову лучше в том числе в колонне, но такое ощущение что продается в жутких квантах через ollama. Я бы предположил что у вас давнее тестирование, но новый qwen то присутствует. А уж если сравните с новеньким 27b по своей методике для релевантности - это прям отдельное спасибо.


        1. CodeFoxAI Автор
          13.03.2026 20:40

          Тут скорее сыграл человеческий фактор - честно говоря, я просто не заметил, что уже была доступна версия DeepSeek v3.2 на момент тестирования. Спасибо, что обратили внимание. Попробую прогнать её по той же методике и сравнить результаты.


  1. EriIaz
    13.03.2026 20:40

    Ollama предоставляет удобный способ работать

    Вы серьёзно? Чем конкретно удобный? Может хватит уже из каждого утюга форсить этот комбайн, выросший из частного и забагованного форка llamacpp?

    С какой точностью квантования работают модели их облачных провайдеров? У Ollama даже с локальными моделями по этой части есть проблемы, и что-то мне подсказывает, в облаке ничуть не лучше. Я бы не стал к этому цепляться, если бы в статье не было сравнения моделей, но оно есть, а без такой информации любое тестирование моделей имеет мало смысла, просто потому, что Qwen3.5-397B-A17B BF16 ≠ Qwen3.5-397B-A17B IQ1_S

    Когда стоит использовать Ollama для code review? если проект содержит чувствительный код или ограничения NDA;

    При локальном запуске - допустим. Не лучшее решение, поскольку llamacpp во всём будет лучше, но допустим. А В ОБЛАКЕ!? У вас же вся статья про ОБЛАЧНЫЙ сервис от Ollama! От заголовка до последней крупицы контента... Вы как к такому выводу вообще пришли!?

    Где можно почитать про провайдеров, которых задействует Ollama? Про политику сбора данных у этих провайдера? Сами то они пишут, "мы не собираем данные, мамой клянусь", а провайдер? Я очень сомневаюсь, что у Ollama есть свои собственные мощности для массового инференса крупных моделей, скорее всего они работают как посредник. И даже если допустить, что они не являются посредником, какие у вас могут быть причины доверять Ollama Cloud свои данные ПОД NDA?

    Чем облачная часть этого поделия лучше, чем старый добрый OpenRouter? Хочешь, пользуйся через API со своего фронтенда, хочешь на сайте. Там ещё есть огромный плюс, что ты платишь за токены, а не за подписку. И в USDT оплату принимают. И ВСЮ информацию предоставляют, какая только у них есть. Это, конечно, не повод пользоваться ими из под NDA, я думаю, вас за такое любой юрист нахлобучит. Но OpenRouter по крайней мере сразу говорят: вот этот провайдер декларирует отсутствие сбора данных, вот тот - как минимум хранит их 30 дней, а вооот этот даже обучает свои модели на ваших данных. И вы сами можете решить, насколько это согласуется с уровнем чувствительности ваших данных, в случаях, когда прямых обязательств о неразглашении нет. И с точностью тоже проблем нет - открыто и явно сообщают, что вот у этого провайдера вот эта конкретная модель запущена с точностью FP8, вот у этого INT4, а этот полновесную запускает.


    1. CodeFoxAI Автор
      13.03.2026 20:40

      По сути у вас есть несколько справедливых замечаний.
      Да, в статье стоило чётче разделить локальный Ollama и Ollama Cloud: аргумент про NDA относится именно к локальному запуску, а не должен автоматически переноситься на облачный сервис.
      Да, отсутствие данных о точности/квантовании - это ограничение сравнения, и его стоило обозначить явно.
      Моя цель была не доказать, что Ollama Cloud "лучше всех", а сравнить качество ответов моделей в конкретном интерфейсе и сценарии code review. Но замечание про прозрачность провайдеров и data policy для облака абсолютно уместно.


  1. Pusk1
    13.03.2026 20:40

    На этой неделе 2 дня посетил подобной задаче. У меня не было ограничений по выбору модели. Использовался Open Router.

    На реальных PR лучше всего показала себя архитектура, когда одна модель проверяет результаты другой модели. Число ложно положительных срабатываний уменьшается в 4 раза.

    Так же не получается использовать в лоб разные модели с одинаковыми параметрами. Например, при ограничении на число вызовов инструментов в 5 на диф Sonet пропускает очевидные вещи, а модели от Google отлично справляются.

    Моё резюме: дёрнуть API с похожими параметрами недостаточно, чтобы сравнить качество моделей для задачи. Ещё бы неплохо добавить стоимость и время. 2-6 USD и 15 минут могут выйти за ваши не функциональные требования. Особенно, если дифы генерятся LLM в огромном количестве.