Коротко (TL;DR)
Адверсариальное мульти-агентное ревью — это когда один ИИ пишет код (генератор), а другой или несколько других целенаправленно пытаются его сломать (критики), после чего вердикты сводятся голосованием. Ключевое слово — адверсариальный: критик не «улучшает», а атакует, его задача — найти дыру и доказать её, а не похвалить и согласиться.
Зачем это нужно: один ИИ-ревьюер повторяет те же искажения, что и генератор, — они обучены на похожих данных и ошибаются коррелированно. Несколько независимых критиков, желательно из разных модельных семейств, ловят именно те баги, которые одна модель уверенно пропускает.
Что важно понять сразу:
- Единогласие критиков — это не всегда хороший знак. Оно может означать общий тренировочный bias, а не истину. Есть задокументированный случай, где 80 с лишним агентов единогласно подтвердили несуществующую уязвимость, а убил её один эмпирический тест.
- Это стоит денег. Диапазон реальных цифр — от иллюстративных центов до 15–25 долларов за ревью в проде и десятков долларов за найденную уязвимость.
- Паттерн не серебряная пуля: у него свой набор провалов — подхалимаж в дебатах, продавливание большинством, слепота к запретам.
Разберём механику, почему это работает, сколько стоит и как собрать такое ревью в Claude Code вручную — с честной оценкой того, где паттерн реально помогает, а где превращается в дорогой генератор шума.
Генератор и критик: адверсариальный, а не улучшающий
В основе — паттерн, который Anthropic называет evaluator-optimizer: генератор выдаёт результат, критик его оценивает, цикл повторяется. Но есть важная развилка в роли критика.
«Улучшающий» критик работает в связке: подскажи, как сделать лучше, — и генератор дорабатывает. Адверсариальный критик работает иначе: его инструктируют с kill-mandate — не улучшить, а опровергнуть. Найти контрпример, сломать логику, доказать, что код неверен. Это принципиально меняет поведение: критик с мандатом «улучшай» склонен соглашаться, а критик с мандатом «сломай» активно ищет дыры.
По сути это перенос в мир ИИ старой инженерной идеи — N-version programming из 1970-х, где одну задачу независимо решают несколько команд, чтобы их ошибки не совпадали. Только теперь «команды» — это агенты, и цена их запуска несопоставимо ниже. Идея та же: если два независимых исполнителя ошибаются в разных местах, их совместная проверка ловит больше, чем удвоенное усилие одного. Проблема ИИ в том, что «независимость» здесь обманчива — две модели одного семейства обучены похоже и ошибаются похоже, поэтому просто «запустить проверку дважды» той же моделью почти ничего не даёт. Настоящая независимость требует либо разных семейств, либо разных ролей-линз, либо и того и другого.
N скептиков и голосование
Один критик — это уже лучше, чем ничего, но настоящая сила в нескольких независимых. Механика простая: N критиков смотрят код параллельно, каждый выносит вердикт, а итог определяется голосованием (majority vote) или отдельным агентом-арбитром (Judge), который сводит мнения.
Критический нюанс — из каких семейств эти критики. Если все они одной модели, они склонны ошибаться одинаково. Отсюда идея Cross-Model Critic: брать критиков из РАЗНЫХ модельных семейств. Обоснование не умозрительное: по данным Kim et al. (на них ссылается тот же Refute-or-Promote), две языковые модели соглашаются друг с другом примерно в 60% случаев именно тогда, когда обе неправы. То есть согласие одномодельных критиков — слабый сигнал. Разнообразие семейств бьёт по этому напрямую; при желании роль критика можно отдать даже отдельной локальной модели другого семейства, чтобы гарантированно развести обучающие данные.
Отсюда же контринтуитивный принцип: единогласие — событие с низким сигналом. Когда все критики согласны, это может значить и «код точно хорош», и «все они одинаково слепы». Разногласие критиков часто ценнее их согласия: именно точка, где мнения расходятся, чаще всего указывает на реальную проблему или на неоднозначное место в коде, которое стоит разобрать вручную.
Практически голосование можно устроить по-разному. Простейший вариант — большинство: баг засчитывается, если его отметили хотя бы двое из трёх. Строже — консенсус с воспроизведением: находка идёт в дело, только если её удаётся подтвердить объективно (тестом, запуском). Мягкий вариант с одним «за» даёт много ложных срабатываний и обычно не стоит внимания разработчика. Выбор порога — это выбор между «пропустить баг» и «утопить разработчика в шуме», и он важнее, чем само число критиков.
Разные линзы вместо одного длинного промпта
Ещё один рычаг — перспективное разнообразие. Вместо одного критика с гигантским промптом «проверь всё» лучше три специализированных, каждый со своей линзой:
- критик безопасности — ищет уязвимости, инъекции, утечки;
- критик производительности — узкие места, лишние аллокации, сложность;
- критик корректности — краевые случаи, логические ошибки, контракты.
Три узких взгляда ловят больше, чем один широкий, по той же причине, по какой context engineering советует не перегружать окно: агент с чётко очерченной задачей работает точнее, чем агент, которого просят держать в голове десять разных критериев сразу. Когда одному критику дают промпт «проверь безопасность, производительность, стиль, логику и краевые случаи», он распыляется и поверхностно скользит по каждому пункту. Специализированный критик безопасности, наоборот, копает вглубь именно своей темы — и находит то, что универсальный проглядел бы. Разделение по линзам — это применение принципа «одна задача на агента» к самому ревью.
Почему адверсариальный проход ловит больше
У картины две стороны. С одной стороны, есть исследование (Refute-or-Promote, одна полевая кампания за 31 день — данные единичные, не воспроизведённые независимо), где адверсариальное ревью «убивало» около 79–83% ложных находок. С другой — то же исследование дало отрезвляющий кейс Bleichenbacher: более 80 агентов и 10 выделенных ревьюеров единогласно подтвердили уязвимость, которой не было. Опроверг её не ещё один агент, а один эмпирический тест — код просто запустили.
Вывод двоякий. Адверсариальные критики из разных семейств действительно ловят баги, которые пропускает консенсус одной модели (в том же исследовании кросс-семейный критик поймал ошибки, которые пропустили свои, примерно в 16% случаев). Но никакое количество агентов не заменяет объективную проверку — запуск, тест, воспроизведение. Ревью моделями сужает пространство ошибок, а не устраняет его.
Механизм, почему это работает, проще на бытовой аналогии. Представьте, что текст вычитывает автор и его коллега, учившийся по тем же учебникам: они пропустят одни и те же привычные ошибки, потому что у них общие слепые пятна. А редактор из другой школы заметит то, что оба считают нормой. С ИИ ровно так же: критик того же семейства, что и генератор, — это «коллега по учебникам», а критик другого семейства — «редактор со стороны». Именно поэтому cross-family проверка даёт непропорционально много по сравнению с простым увеличением числа одинаковых критиков.
Сколько это стоит
Экономика — то, о чём евангелисты паттерна умалчивают. Собранные из разных источников цифры дают широкий диапазон:Кейс Стоимость Что это Иллюстративный ~$0,31, менее 4 минут единичный блог-пример 3-агентного ревью Продакшн (Anthropic) $15–25 за ревью по заявлению компании о своём Code Review Научная кампания ~$250 всего, ~$62 за найденную уязвимость одно полевое исследование
Anthropic отдельно подчёркивает, что ревью тарифицируется по расходу токенов (billed on token usage), то есть его стоимость растёт вместе с размером PR — чем больше кода, тем дороже проход. На своём Code Review компания приводит и другие цифры: доля PR с содержательным ревью выросла с 16% до 54%, на крупных PR система находила заметно больше проблем, чем на мелких, а долю ложных срабатываний компания оценивает менее чем в 1% (данные на 9 марта 2026 года). Здесь нужна оговорка: это внутренний самоотчёт, и он расходится с независимым индустриальным ориентиром — для типичных однопроходных ИИ-ревьюеров базовый уровень ложных срабатываний обычно оценивают в 5–15%. То есть «меньше 1%» — заявление о конкретной адверсариально-верифицированной системе, а не универсальная норма для «ИИ-ревью вообще».
Мини-фреймворк «когда N агентов стоят своих денег»: адверсариальное ревью оправдано там, где цена пропущенного бага высока (безопасность, деньги, необратимые действия) и где код достаточно сложен, чтобы один проход его не покрыл. На тривиальных изменениях N критиков — дорогая игрушка: стоимость растёт линейно с числом агентов, а находки — нет.
Риски и провалы паттерна
Многоагентность приносит собственные болезни, которых нет у одиночного ревью:
- Подхалимаж в дебатах (sycophancy). Когда критики «спорят» несколько раундов, они склонны подстраиваться под уверенное мнение, а не отстаивать своё. Групповая точность при этом может не расти, а падать с числом раундов.
- Продавливание большинством. Один уверенно ошибающийся агент способен склонить остальных — консенсус смещается не к истине, а к самой напористой позиции.
- Слепота к отрицаниям. Критики слабее всего именно там, где правило сформулировано как запрет — «система НЕ должна делать X». Это устойчивое свойство, а не случайность.
- Ложный консенсус. Тот самый кейс Bleichenbacher: единогласие критиков само по себе ничего не гарантирует.
Практики это подтверждают на своём опыте: в обсуждениях реальный процент ложных срабатываний у самодельных мультиагентных ревьюеров расходится на порядок — от единиц процентов до почти сплошного шума. Разница — не в идее «N агентов», а в качестве арбитража: как именно сводятся вердикты и кто выносит финальное решение. Плохой арбитр превращает три полезных мнения в кашу, а слишком мягкий пропускает всё подряд как «возможную проблему», заваливая разработчика ложными срабатываниями.
Отсюда практическое следствие: наращивать число критиков без хорошего арбитража бессмысленно. Пять агентов с плохим сведением вердиктов дадут больше шума, чем два с чётким правилом «баг засчитывается только при воспроизводимом контрпримере». Ценность паттерна создаётся не количеством голосов, а строгостью того, что считается подтверждённой находкой.
Как собрать это в Claude Code
Базовую схему можно собрать вручную через субагентов. Логика такая:
- Генератор пишет код (обычная сессия или субагент-исполнитель).
- Критики по ролям — отдельные субагенты, каждому в промпте задаётся линза (безопасность / производительность / корректность) и kill-mandate: «твоя задача — найти, где это сломается, а не похвалить».
- Изоляция контекста — критики не должны видеть рассуждений генератора, иначе заразятся его логикой; каждый смотрит только на результат.
- Арбитр сводит вердикты и решает, что действительно баг, а что шум.
Инструменты вроде Cursor и другие ИИ-редакторы двигаются в ту же сторону встроенными ревью-механизмами — и если не хотите собирать связку вручную, встроенное ревью Cursor работает «из коробки» (в том числе на моделях Claude). Но собственная сборка даёт контроль над ролями и, главное, над разнообразием семейств — ключевым фактором, который встроенные однопроходные ревью обычно не обеспечивают.
Не переусердствуйте с масштабом. Начать стоит с минимальной работающей связки: генератор плюс два-три критика по ключевым линзам плюс строгий арбитр, засчитывающий только воспроизводимые находки. Такая схема уже ловит заметно больше одного прохода и при этом не разоряет по токенам. Наращивать число критиков и раунды дебатов имеет смысл только тогда, когда вы видите, что находки продолжают появляться, а не когда «чем больше агентов, тем солиднее». И держите в контуре человека на финальном решении: адверсариальное ревью сужает список подозрений, но принимает или отклоняет их всё равно инженер — особенно там, где цена ошибки высока.
FAQ
Чем адверсариальный критик отличается от обычного код-ревью ИИ? Обычный ИИ-ревьюер часто «улучшает» и склонен соглашаться. Адверсариальный критик получает мандат сломать код — найти контрпример, дыру, краевой случай. Это меняет поведение: он ищет проблемы активно, а не подтверждает, что всё хорошо.
Почему нельзя обойтись одним умным агентом? Один агент повторяет искажения своей модели: он и генерирует, и проверяет с одними и теми же слепыми пятнами. Несколько независимых критиков, особенно из разных семейств, ошибаются по-разному — и ловят то, что один пропускает единогласно с генератором.
Значит, если все критики согласны, код точно хорош? Нет. Единогласие — сигнал низкой ценности: оно может означать общий тренировочный bias. Есть реальный случай, где десятки агентов единогласно подтвердили несуществующую уязвимость. Финальную проверку даёт запуск и тест, а не консенсус моделей — воспроизводимый контрпример весит больше десятка согласных мнений.
Когда это оправдано по деньгам? Когда цена пропущенного бага высока (безопасность, финансы, необратимые операции) и код сложен. Стоимость растёт линейно с числом агентов, поэтому на мелких и простых изменениях многоагентное ревью — лишние траты.
Можно ли доверять цифре «меньше 1% ложных срабатываний»? Это самоотчёт конкретной компании о своей системе, и он расходится с независимым ориентиром в 5–15% для типичных однопроходных ревьюеров. Воспринимайте её как заявление вендора о конкретной реализации, а не как универсальную характеристику ИИ-ревью.
Сколько критиков оптимально? Универсального числа нет, но начинать разумно с двух-трёх по разным линзам (безопасность, производительность, корректность) плюс арбитр. Дальше решает не количество, а строгость арбитража и разнообразие семейств. Пять одинаковых критиков с мягким сведением вердиктов хуже трёх разных со строгим правилом «баг только при воспроизводимом контрпримере».
Заменяет ли это человека-ревьюера? Нет. Адверсариальное ревью сужает список подозрительных мест и ловит то, что пропустил бы один проход, но финальное решение — принять находку или отклонить — остаётся за инженером. Особенно там, где цена ошибки высока: модели могут ошибаться и единогласно, а ответственность несёт человек.
Курс «Claude Code с нуля до продакшена» · модуль «PRO: автономность и дисциплина». Полная программа и два маршрута обучения — на странице курса.
Предыдущий урок: Test-Driven Development с ИИ
