Кросс-модельное ревью кода

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

Тезис практика

В посте русскоязычного Telegram-канала за сентябрь 2026 года описана конкретная реализация. Задачи по коду автор отдаёт DeepSeek-V4-Flash - она достаточно дешёвая, а её vision-вариант он к тому же запускает локально для ночных задач. Ревью кода и правку ошибок выполняет GLM-5.3. По его словам, эта связка хорошо справляется с его задачами и укладывается примерно в $200 в месяц, из которых $144 уходит на подписку GLM Max v2. В посте приводятся три аргумента, а в подтверждение двух последних цитируются шесть статей.

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

Второй аргумент - модель-автор не должна проверять сама себя. Модель, допустившая ошибку, или даже модели из того же семейства с высокой вероятностью пропустят её по тем же самым причинам, по которым её совершили. Собственные сравнения автора поста подтверждают это: ревью другой моделью почти всегда оказывается лучше самопроверки. Он отмечает, что самопроверку можно усилить, запустив её как целевой цикл ("повторное ревью не должно находить новых замечаний уровня must-fix или should-fix"), но это обходится значительно дороже по токенам, чем проверка другой моделью.

Третий аргумент - слабая модель должна писать, а сильная проверять, а не наоборот. Ошибки сильной модели в коде слишком неочевидны, чтобы их заметил слабый ревьюер, и тот будет в основном простаивать. Автор делает оговорку: понятие "слабая" относительно, и пишущая модель должна преодолевать порог качества, ниже которого ревью превращается в переписывание большей части изменений. Этот порог зависит от задач, предметной области и стека.

Что на самом деле измеряют цитируемые статьи

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

• llm-self-verification-limits (2024): GPT-4 критикует собственные ответы в цикле на головоломках и задачах планирования в сравнении с надёжным внешним верификатором.
• reviewer-capability-rejection-targeting (2026): фиксированный исполнитель с самопроверкой, ревьюером из другого семейства и слабым ревьюером на 100 олимпиадных математических задачах.
• verification-dynamics-llms (2025/2026): 15 моделей в роли генераторов и верификаторов на бенчмарках по математике, знаниям и логике.
• strong-weak-model-collaboration-codegen (2025): способы разделения исправления багов в SWE-bench Lite между сильной и слабой моделями.
• small-model-code-judges (2026): небольшие дообученные судьи, выбирающие варианты Java-кода, предложенные малым генератором.
• swr-bench-code-review (2025/2026): ревью кода с помощью LLM на 1000 реальных pull request'ов, написанных людьми.

Самопроверка

Обе статьи, исследовавшие самопроверку, приходят к выводу, что она даёт слабый результат, что подтверждает вывод поста. Однако механизм, описанный в посте, не подтверждается ни в одной из них. В исследовании 2024 года на базе GPT-4 критика самой себя терпела неудачу в основном из-за того, что отвергала правильные ответы и генерировала выдуманные замечания, из-за чего точность падала ниже исходной первой догадки. В пилотном исследовании 2026 года самопроверка показала наивысший recall среди всех ревьюеров (0.85): модель действительно находила собственные ошибки. Но при этом она забраковала 35% изначально верных ответов, смогла исправить лишь 15% отклонённых вариантов и дала незначимый прирост в +6 процентных пунктов, тогда как ревьюер из другого семейства добавил 12 пунктов без какого-либо ущерба.

Эта разница важна для идеи с целевым циклом. Ревьюер, который слишком часто бракует код при самопроверке, безвреден лишь до тех пор, пока пишущая модель игнорирует его замечания. В пилотном эксперименте исполнитель согласился с 3 из 18 ложных отклонений, и во всех 3 случаях ответы стали ошибочными; полное же согласие со всеми замечаниями опустило бы точность ниже уровня работы вовсе без ревью. Цикл, который заставляет модель переделывать код до полного удовлетворения ревьюера, гарантирует согласие со всеми замечаниями. В итоге целевой режим лишь тратит лишние токены на проверки того ревьюера, чьим вердиктам можно доверять меньше всего.

Тезис о неэффективности моделей из одного семейства ни в одной из шести статей напрямую не проверяется. В исследовании верификации 2025 года цитируется параллельная работа (Lu et al.), где утверждается, что верификация моделью из другого семейства особенно эффективна, но этой статьи в vault нет. llm-cross-entropy-similarity показывает, что модели одной лаборатории пишут похоже, что подкрепляет интуицию автора, но измеряет стиль текста, а не общие слепые зоны.

SWR-Bench вносит уточнение: объединение результатов десяти проходов ревью от одной и той же модели подняло F1 на 43.67%, а recall - на 118.83%. То есть повторный запуск той же модели не бесполезен, когда она ревьюит чужой код. Но это принципиально отличается от проверки собственного результата.

Сильнее автор или сильнее ревьюер

Лучшее подтверждение тезиса "слабая пишет, сильная проверяет" даёт verification-dynamics-llms. Ошибки более сильных генераторов находить значительно труднее: Qwen2.5-72B отклонила 68% неверных математических ответов от Llama-3.1-8B и лишь 17% - от Qwen3-32B. Причина в том, что слабые модели совершают поверхностные ошибки, тогда как сильные выстраивают логичные цепочки рассуждений, опираясь на ранний неверный шаг. С верификатором на базе GPT-4o более слабые генераторы сократили отставание от сильных на 30-50% в разных областях. А на выборке из 181 математической задачи Qwen3-4B с верификатором GPT-4o набрала 0.954 против 0.952 у одиночной генерации GPT-4o, потратив в 2.5 раза меньше токенов GPT-4o. Слабый ревьюер из пилотного исследования, не способный решать задачи сам, не изменил ни одного из 100 ответов при удвоении расхода токенов, что подтверждает тезис о простое слабого ревьюера.

Три результата вносят оговорки.

Статья о совместной работе, которую цитирует автор поста, вообще не тестирует сценарий с ревьюером. В strong-weak-model-collaboration-codegen наиболее качественное разделение труда достигается, когда сильная модель пишет патч, а слабая лишь исправляет форматирование - порядок, прямо противоположный схеме из поста. Вариант, где слабая модель выполняет большую часть работы, представляет собой бюджетный каскад, который мало что даёт, если слабая модель и так компетентна. В буквальном прочтении эта статья свидетельствует в пользу сильного автора.

Слабый проверяющий может работать эффективно, если его специально обучить. В small-model-code-judges малые модели в режиме zero-shot были практически бесполезны как судьи корректности Java-кода (каппа 0.00-0.35), но после fine-tuning модель на 3B параметров достигла показателя 0.57, обогнав GPT-4.1-mini. Генератор на 1-4B параметров в паре с таким судьёй сравнился со старшей моделью на 8-33B или превзошёл её в четырёх из пяти семейств. Судья не был сильнее генератора: он был специализирован и обучен на результатах генерации тех же самых моделей.

Преимущество сильного ревьюера исчезает именно там, где оно нужнее всего автору поста. Исследование верификации показало, что на сложных задачах и на коде сильных генераторов верификатор на 7B параметров и GPT-4o давали примерно одинаковый прирост (0.1 или меньше), поскольку ни один из них не мог поймать почти ничего. А полезный ревьюер в пилоте 2026 года был моделью среднего уровня из другого семейства и вовсе не превосходил исполнителя по силе.

Какие утверждения и когда остаются в силе

В сухом остатке подтверждаются четыре вывода, каждый со своим условием.

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

На роль ревьюера ставьте другую модель и следите, чтобы она сама была способна решить эту задачу. Ниже этого порога ревью лишь сжигает токены и ничего не меняет. Выше этого порога точность (precision) важнее полноты (recall): ревьюер, который бракует редко, но по делу, лучше того, который цепляется ко всему.

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

Там, где возможна строгая внешняя проверка, она превосходит любого модельного критика. Исследование 2024 года показало, что повторная генерация до прохождения строгой проверки сохраняет почти весь прирост точности вообще без текста критики. В коде это означает тесты, тайпчекеры и компиляторы, как в testing-heavy-no-review-workflow и neurosymbolic-ai. Модель-ревьюер нужна для того, что эти инструменты выразить не могут.

Всё это опирается на бенчмарки с эталонными ответами (в основном по математике), на модели 2023-2026 годов и в одном случае на пилотный тест из 100 задач, поэтому здесь действует llm-output-variance. Ни одна из шести статей не измеряет то, что реально делает автор поста: работу агента в настоящем репозитории с ревью и правками от второй модели. SWR-Bench, единственный бенчмарк на реальное ревью, очерчивает потолок: лучшие LLM-ревьюеры в один проход достигают лишь около 20% F1 на pull request'ах людей, главным образом из-за ложных срабатываний.

Связь с ревью человеком

Ревью моделями привлекательно тем, что человек-ревьюер не успевает за потоком: в code-review-throughput-limits и reviewing-ai-code приведены конкретные цифры. В cacm-code-review-ai-coding цитируется основатель компании, в пайплайн которой встроен отдельный проход состязательного ревью, а в llm-critics-are-right-use-anyway описаны состязательные субагенты, работающие до тех пор, пока не начнут выдумывать несуществующие проблемы. roborev позволяет назначать на роли проверяющего и исправляющего агентов разные модели. Напротив, laycock-review-by-exception утверждает, что AI-ревьюер, сохраняющий привычный гейт, лишь автоматизирует ритуал, и большая часть того, ради чего затевалось ревью, должна происходить ещё до написания кода. Разобранные выше статьи измеряют, находит ли вторая модель ошибки. Они не отвечают на вопрос, должно ли каждое изменение проходить через такой контроль. Выбор моделей в посте - deepseek для написания и GLM для ревью - это лишь конфигурация одного разработчика, а не общее научное открытие.