Коротко (TL;DR)
Адверсаріальне мультиагентне рев’ю — це коли один ШІ пише код (генератор), а інший або кілька інших цілеспрямовано намагаються його зламати (критики), після чого вердикти зводяться голосуванням. Ключове слово — адверсаріальний: критик не «покращує», а атакує, його завдання — знайти дірку й довести її, а не похвалити та погодитися.
Навіщо це потрібно: один ШІ-рев’юер повторює ті самі викривлення, що й генератор, — вони навчені на схожих даних і помиляються корельовано. Кілька незалежних критиків, бажано з різних модельних сімейств, ловлять саме ті баги, які одна модель упевнено пропускає. По суті це і є мультиагентна перевірка коду ШІ, де сила — не в кількості голосів, а в різноманітності поглядів.
Що важливо зрозуміти одразу:
- Одностайність критиків — це не завжди добрий знак. Вона може означати спільний тренувальний bias, а не істину. Є задокументований випадок, де понад 80 агентів одностайно підтвердили вразливість, якої не існує, а вбив її один емпіричний тест.
- Це коштує грошей. Діапазон реальних цифр — від ілюстративних центів до 15–25 доларів за рев’ю в проді й десятків доларів за знайдену вразливість.
- Патерн не срібна куля: у нього свій набір провалів — підлабузництво в дебатах, продавлювання більшістю, сліпота до заборон.
Розберемо механіку, чому адверсаріальна перевірка коду ШІ працює, скільки коштує і як зібрати таке рев’ю в Claude Code вручну — з чесною оцінкою того, де патерн реально допомагає, а де перетворюється на дорогий генератор шуму.
Генератор і критик: адверсаріальний, а не покращувальний
В основі — патерн, який Anthropic називає evaluator-optimizer: генератор видає результат, критик його оцінює, цикл повторюється. Але є важлива розвилка в ролі критика.
«Покращувальний» критик працює у зв’язці: підкажи, як зробити краще, — і генератор доопрацьовує. Адверсаріальний критик працює інакше: його інструктують із kill-mandate — не покращити, а спростувати. Знайти контрприклад, зламати логіку, довести, що код неправильний. Це принципово змінює поведінку: критик з мандатом «покращуй» схильний погоджуватися, а критик з мандатом «зламай» активно шукає дірки. Саме тому зв’язка агентів генератор і критик у код-рев’ю дає інший результат, ніж звичайний асистент, що «допомагає».
По суті це перенесення у світ ШІ старої інженерної ідеї — N-версійного програмування з 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% випадків). Але жодна кількість агентів не замінює об’єктивну перевірку — запуск, тест, відтворення. Рев’ю моделями звужує простір помилок, а не усуває його. Тому незалежна перевірка згенерованого коду завжди завершується запуском, а не голосуванням.
Механізм, чому це працює, простіший на побутовій аналогії. Уявіть, що текст вичитує автор і його колега, який учився за тими самими підручниками: вони пропустять ті самі звичні помилки, бо в них спільні сліпі плями. А редактор з іншої школи помітить те, що обидва вважають нормою. З ШІ так само: критик того самого сімейства, що й генератор, — це «колега за підручниками», а критик іншого сімейства — «редактор збоку». Саме тому крос-сімейна перевірка дає непропорційно багато порівняно з простим збільшенням числа однакових критиків.
Скільки це коштує
Економіка — те, про що євангелісти патерну замовчують. Зібрані з різних джерел цифри дають широкий діапазон:Кейс Вартість Що це Ілюстративний ~$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). Але власна збірка дає контроль над ролями і, головне, над різноманіттям сімейств — ключовим чинником, який вбудовані однопрохідні рев’ю зазвичай не забезпечують. Саме так AI-агенти шукають баги до релізу ефективніше, ніж один універсальний асистент.
Не перестарайтеся з масштабом. Почати варто з мінімальної робочої зв’язки: генератор плюс два-три критики за ключовими лінзами плюс суворий арбітр, що зараховує тільки відтворювані знахідки. Така схема вже ловить помітно більше за один прохід і при цьому не розорює за токенами. Нарощувати число критиків і раунди дебатів має сенс тільки тоді, коли ви бачите, що знахідки продовжують з’являтися, а не коли «що більше агентів, то солідніше». І тримайте в контурі людину на фінальному рішенні: адверсаріальне рев’ю звужує список підозр, але ухвалює або відхиляє їх усе одно інженер — особливо там, де ціна помилки висока.
FAQ
Чим адверсаріальний критик відрізняється від звичайного код-рев’ю ШІ? Звичайний ШІ-рев’юер часто «покращує» й схильний погоджуватися. Адверсаріальний критик отримує мандат зламати код — знайти контрприклад, дірку, межовий випадок. Це змінює поведінку: він шукає проблеми активно, а не підтверджує, що все добре.
Чому не можна обійтися одним розумним агентом? Один агент повторює викривлення своєї моделі: він і генерує, і перевіряє з тими самими сліпими плямами. Кілька незалежних критиків, особливо з різних сімейств, помиляються по-різному — і ловлять те, що один пропускає одностайно з генератором.
Отже, якщо всі критики згодні, код точно добрий? Ні. Одностайність — сигнал низької цінності: вона може означати спільний тренувальний bias. Є реальний випадок, де десятки агентів одностайно підтвердили вразливість, якої насправді немає. Фінальну перевірку дає запуск і тест, а не консенсус моделей — відтворюваний контрприклад важить більше за десяток згодних думок.
Коли це виправдано за грошима? Коли ціна пропущеного бага висока (безпека, фінанси, незворотні операції) і код складний. Вартість зростає лінійно з числом агентів, тому на дрібних і простих змінах багатоагентне рев’ю — зайві витрати.
Чи можна довіряти цифрі «менш ніж 1% хибних спрацювань»? Це самозвіт конкретної компанії про свою систему, і він розходиться з незалежним орієнтиром у 5–15% для типових однопрохідних рев’юерів. Сприймайте її як заяву вендора про конкретну реалізацію, а не як універсальну характеристику ШІ-рев’ю.
Скільки критиків оптимально? Універсального числа немає, але починати розумно з двох-трьох за різними лінзами (безпека, продуктивність, коректність) плюс арбітр. Далі вирішує не кількість, а суворість арбітражу й різноманіття сімейств. П’ять однакових критиків з м’яким зведенням вердиктів гірші за трьох різних із суворим правилом «баг тільки за відтворюваного контрприкладу».
Чи замінює це людину-рев’юера? Ні. Адверсаріальне рев’ю звужує список підозрілих місць і ловить те, що пропустив би один прохід, але фінальне рішення — прийняти знахідку чи відхилити — лишається за інженером. Особливо там, де ціна помилки висока: моделі можуть помилятися й одностайно, а відповідальність несе людина.
Курс «Claude Code з нуля до продакшену» · модуль «PRO: автономність і дисципліна». Повна програма і два маршрути навчання — на сторінці курсу.
Попередній урок: Test-Driven Development зі ШІ
