Девять LLM ревьюили код: как выбрать «вторую голову» в 2026

Что случилось

Разработчик проекта Charoite два месяца гонял код через мультимодельный ревью-конвейер и выложил сырые замеры. С 22 сентября набралось 1517 прогонов. В роли «второй головы» (модель, которая читает дифф перед мержем) успели побывать Codex, GLM, Gemini, DeepSeek, две локальные Qwen, MiMo, Sonnet и Opus. Вердикты Sonnet дополнительно перечитывает Haiku.

Для владельца SMB это не история про чужой пет-проект. Это готовая карта грабель для любого, кто хочет поставить ИИ-ревью в свой пайплайн и не утонуть в счетах и ложных тревогах.

Код Чароита я пишу в Claude Code. Каждое изменение до мержа читает другая модель и пишет вердикт.

Как устроена «голова» и почему это меняет требования к провайдеру

Голова — это вызов claude -p с подменённым ANTHROPIC_BASE_URL. Запрос уходит на совместимый эндпоинт стороннего провайдера. Инструменты у модели только на чтение: Read, Glob, Grep. Она видит чистый клон репозитория на нужном коммите, бриф приходит на вход, вердикт пишется в файл.

Отсюда первое жёсткое требование. OpenAI-совместимого API недостаточно. Нужен Anthropic Messages API с поддержкой tool use. Иначе модель не открывает файлы и судит по диффу вслепую — то есть вы покупаете не ревью, а угадывание.

OpenAI-совместимого API мало, нужен Anthropic Messages API с tool use. Без него голова не открывает файлы и судит по диффу вслепую.

Второй слой — оркестрация. Все круги идут через один скрипт: проверяет бриф, список разрешённых файлов и коммит клона, запускает головы параллельно и ждёт всех. Пустой или оборванный вердикт чистым не считается — модель, которая молча упала, уходит на перезапуск. «Замечаний нет» бывает только у полного вердикта.

Шкала у всех голов одна. Critical — сценарий отказа: вход или состояние, дающие неверный результат или падение. Important — дефект без такого сценария. Minor — гигиена.

Почему вторая голова вообще нужна: PR #381

Показательный пример — PR #381, гейты режима правки графа: скрытые пути, удаление, откат, карантин, замок. Пять кругов. На первом — один Critical в исходном коде. На втором — два Critical в правках по итогам первого круга. На третьем — ещё один Critical в той же правке. На четвёртом — снова Critical там же.

Круги 3 и 4 нашли Critical в одном и том же месте: поиск находил карантин удалённой встречи по префиксу минуты. Автор каждый раз чинил найденный случай и не видел соседний. Именно поэтому правила круга ужесточили: после второго Critical подряд в своей правке искать готовый механизм проекта, а не латать.

Вывод для бизнеса простой. Одна модель, один проход и «зелёный» статус — это не контроль качества. Это лотерея с ощущением процесса.

Хроника состава: кто пришёл и кто ушёл

Ниже — сводка по моделям и причинам ротации. Это и есть практический ответ на вопрос «какую модель брать».

• Codex (по подписке ChatGPT) — первая голова, находил хорошо: все Critical кругов 1–4 в PR #381 его. 16.08 упёрся в лимит usage до 22.08, потом вернулся; к 24.09 в составе его нет.
• GLM-5.3 на Z.ai — пришла 16.08 как замена Codex, Anthropic-эндпоинт, хватило второго env-файла. Во втором проходе нашла два Critical в собственных исправлениях автора. Лимит поинтов в пятичасовом окне (код 1308) пришлось обходить: два повтора, выход сразу по коду, не больше двух прогонов на ключ. В сентябре вернулась через Fireworks.
• DeepSeek V4 — Anthropic-эндпоинт, на старте 402, счёт пополнили, осталась. С 24.09 работает в паре с Sonnet.
• Gemini 3.7 Flash — быстрая, бесплатный тариф. Квота и 503 вывели её из кругов к 22.08.
• Qwen 3.6 35B локально — ради приватности закрытого кода. Снята 22.08 после ложных Critical.
• Qwen 3.8 27B локально — замена 3.6, снята тем же вечером: 15,6 ГБ памяти и более 40 минут без вердикта.
• Sonnet 5 — закрытые зоны, третья на публичном репозитории.
• MiMo-Pro через OpenRouter — кандидат на замену, дороже и медленнее.
• Haiku 5.5 — проверяет вердикт Sonnet, осталась.

Посредников перебрали три: Fireworks, OpenRouter, Nebius. Nebius отпал — нет Anthropic-эндпоинта, нужен переводящий прокси.

Кэш, лимиты и прочие деньги: где конвейер течёт

Самая дорогая ошибка в таких пайплайнах — считать бюджет по прайсу провайдера, не проверив, что кэш префикса промпта реально работает. Автор строил формулу с расчётом на кэш Z.ai: шапка байт в байт, бриф в конец. 23.08 замерил.

Эндпоинт принимает cache_control, но ноль во всех четырёх вызовах. Кэша нет.

Слагаемое за кэш из формулы убрали. Урок универсальный: перед тем как закладывать экономику мультимодельного ревью, прогоните собственный замер cache_read. Если ноль — считайте по полной цене входа.

Второй источник протечек — лимиты. Codex упёрся в usage посреди конвейера: пишешь, а проверить некому. У Z.ai лимит живёт часами, а Claude Code по умолчанию делает 10 повторов с паузами — то есть сам себе устраивает очередь в лимит. Настройка повторов и ранний выход по коду ошибки здесь не косметика, а условие работоспособности.

Третий — скорость и стабильность. По замерам 19.10: GLM-5.3-Flash на Z.ai выдавала 69 tok/s при первом токене 2,77 с, официальный DeepSeek V4.1 Flash — 176 tok/s при первом токене 1,23 с. Разница в разы бьёт по времени ожидания в цикле «правка — ревью — правка».

Локальные модели: приватность против вердикта

У внешних голов есть граница: только публичный репозиторий. Закрытый код им не показывают. Отсюда идея локальной модели — лимитов нет, 503 нет, данные не уходят.

На практике Qwen 3.6 35B на том же диффе, где DeepSeek дала 10 находок, выдала 3 находки, из них 2 верных и 1 ложную. Ложная — Critical про двойной учёт секунд; DeepSeek разобрала тот же случай и отвергла, пути взаимоисключающие. Qwen промахнулась там, где надо держать в голове контракт трёх функций. 22.08 на двух PR вышло хуже: одна совпавшая находка против четырёх ложных Critical и Important.

Qwen 3.8 27B на дельте отработала чисто: Important совпал с находкой DeepSeek, один уникальный Minor, ложных ноль. Но первый боевой аудит зоны на 58 тыс. знаков кода закончился иначе: 15,6 ГБ памяти и более 40 минут без вердикта.

Вердикт по локальным моделям для SMB: как единственная голова — нет. Как дополнение для закрытого кода — только с предохранителями (отказ при слишком большом диффе вместо тихой обрезки) и с готовностью к тому, что машина занята.

Gemini: быстрая, но падает

На задаче с посеянным багом в одном файле Gemini 3.7 Flash отработала за 23 секунды против 184 у GLM-5.3, место и механика — точно, воспроизведение и фикс есть, ложных ноль. Условия разные: у GLM были инструменты, у Gemini файл целиком в промпте и thinking medium.

На задаче B — ревью пакета из трёх PR, 168 тыс. токенов на вход — Gemini выдала 7 находок за 56 секунд, все 7 реальных, ложных ноль, тяжесть завышена в 2 случаях. Одна находка оказалась дырой в гарантии: документация обещала сборку из зафиксированных версий, а pip install --upgrade pip тянул свежий pip с PyPI до установки из lock-файла. Её не нашли ни автор при написании, ни прежнее ревью.

Но в конвейер она не встала. thinkingLevel high давал 503 в четырёх запросах из четырёх, бесплатный тариф — 20 запросов в день, параллельный запрос во время большого — 429. Gemini CLI на машине не заработал: не ходит через прокси из окружения и получает отказ по региону. К 22.08 квота и 503 вывели её из кругов, 26.09 вопрос вернуть закрыли.

Таблица: требования к провайдеру и что реально решает выбор

Кому это нужно и как применить

Мультимодельное ревью имеет смысл, если у вас есть повторяемый цикл изменений и цена пропущенного Critical выше цены лишнего прогона. Типичные сценарии SMB: продуктовые команды на 3–15 разработчиков, аутсорс-студии с плотным потоком PR, команды, где один сильный ревьюер и он же бутылочное горлышко.

Практический порядок внедрения:

1. Сначала один провайдер с Anthropic-совместимым эндпоинтом и tool use. Проверьте, что модель реально читает файлы.
2. Замерьте cache_read на своих промптах. Нет кэша — пересчитайте бюджет.
3. Настройте повторы и ранний выход по кодам лимитов. Иначе конвейер будет стоять часами.
4. Введите шкалу Critical / Important / Minor и правило: круг повторяется только после Critical.
5. Добавьте вторую голову для перепроверки вердиктов (в проекте это Haiku поверх Sonnet).
6. Локальную модель — только для закрытого кода и только с предохранителями.

Ограничения и подвох

Все замеры — из одного проекта и одного стиля кода. Цифры tok/s и времени первого токена зависят от нагрузки на стороне провайдера и от вашего промпта. Ложные Critical у локальных моделей — не приговор всем локальным моделям, а сигнал, что на сложных контрактах между функциями они пока слабы.

Главный подвох в другом. Мультимодельный конвейер легко превращается в машину по производству ложных тревог, если не настроить шкалу и правила круга. Модель, которая «что-то нашла», без разбора Critical / Important / Minor — это шум, а не контроль качества.

Брать или подождать: вердикт за 30 секунд

Брать сейчас: Anthropic-совместимый провайдер с tool use как первая голова, вторая голова для перечитывания вердиктов, жёсткие правила круга. Это уже работает и экономит время на ревью.

Подождать: локальные модели как единственная голова на сложном коде. Qwen 3.6 дала ложные Critical, Qwen 3.8 не выдала вердикт за 40+ минут. Для закрытого кода — только как дополнение.

Не брать: провайдера без Anthropic-эндпоинта и без tool use. Это мусор в пайплайне: модель судит вслепую, а вы платите за уверенный тон.

FAQ

Можно ли обойтись одной моделью?

Можно, но тогда пропуски будут системными. В PR #381 круги 3 и 4 нашли Critical в одной и той же правке — то есть одна голова видела проблему, но не соседний случай. Вторая голова и правило «после второго Critical искать готовый механизм» закрывают именно этот класс ошибок.

Нужен ли свой скрипт-оркестратор?

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

Что делать с лимитами провайдера?

Настроить повторы и ранний выход по коду ошибки, ограничить число прогонов на ключ. У Z.ai лимит живёт часами, а стандартные 10 повторов только усугубляют простой.

Стоит ли рассчитывать на кэш промпта?

Только после собственного замера. У Z.ai эндпоинт принимал cache_control, но cache_read был ноль во всех четырёх вызовах.

Что делать дальше

Если вы уже платите за ИИ-ревью, начните с аудита: какие модели реально читают файлы, работает ли кэш, как ведёт себя конвейер на лимитах. Три замера закрывают большинство сюрпризов в счёте. Если только планируете — не покупайте «умную модель», покупайте совместимый эндпоинт, правила круга и вторую голову для перепроверки.

Сценарий внедрения: дорожная карта на первые недели

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

1. Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
2. Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
3. Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
4. Неделя 5+: масштабирование на смежные процессы и фиксация регламентов, чтобы качество держалось без геройства команды.

Формат “один главный результат на одну неделю” сохраняет темп и экономит управленческое внимание.

Шаблон балльной оценки (YAML — можно перенести в таблицу)

Веса согласованы со схемой в начале статьи. Фиксируйте баллы сразу после встречи, пока память свежая.

vendor_rubric:
  pilot_kpi: { max: 25, check: "число, дата первого замера, порог успеха" }
  integrations: { max: 20, check: "CRM/API, не отложенное 'потом'" }
  methodology: { max: 18, check: "имя ответственного инженера, не только сейлз" }
  cases: { max: 15, check: "проверяемый кейс, не под NDA-заглушкой" }
  security: { max: 12, check: "логи, доступы, ПДн" }
  support: { max: 10, check: "SLA после go-live" }
  review: "повторять после каждого созвона; ниже 55 — не подписывать крупный контракт"

Где заказчик сам себе усложняет выбор

• Нет единого владельца результата и бюджета — подрядчик гоняют по внутренним приоритетам.
• Доступы к CRM и тестовым средам «на потом» — без них интеграцию нельзя честно оценить.
• Смена KPI посреди пилота без переписывания условий.

Риски и как их снять заранее

• Запуск без baseline и недельной аналитики — самый дорогой вариант, потому что непонятно, что лечить.
• Смешивание многих задач одновременно — обычно увеличивает календарные сроки и бюджет сверх суммы задач по отдельности.
• Слабая интеграция с точками истины данных (CRM, биллинг, тикет-системы) даёт красивый интерфейс и плохой бизнес-эффект.

Что сделать дальше

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

Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.

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

• Обсудить применение под вашу задачу: Открыть форму контактов PrimeCoder
• Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI

FAQ по теме статьи

Как понять, что тема «Девять LLM ревьюили код: как выбрать «вторую голову» в 2026» подходит для AI, а не для обычной автоматизации?

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

Что нельзя обещать до замеров?

Нельзя обещать точный ROI, рост конверсии и экономию часов без baseline, доступа к данным и понимания, кто будет владельцем процесса.

Какой первый шаг сделать после статьи?

Выпишите один процесс, текущую метрику, цену ошибки и ограничение по данным. После этого уже можно выбирать инструмент или подрядчика.

Дальше по теме платформы: смежные материалы (Маркетинг и SEO-связки)

Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.

• ROI AI Boost Team: как считать
• AI для маркетинга: скорость контента
• Маркетинг под ключ — что входит