Процес перевірки коду з кількома агентами: два рецензенти, один фінальний автор
Я постійно стикаюся з одним і тим самим обмеженням, коли використовую кілька AI-сесій для написання коду. З мого досвіду, паралельні сесії знаходять різні шляхи виконання коду, але їхні розбіжності залишаються в окремих гілках обговорення. Я стаю шиною повідомлень: копіюю одну перевірку в іншу сесію й вирішую, яка модель краще зрозуміла файл.
Кращий підхід — це процес перевірки коду з кількома агентами та трьома чіткими ролями. Дві AI-сесії незалежно перевіряють одну й ту саму версію файлу. Вони обмінюються висновками й оскаржують докази одна одної. Третя сесія отримує запис рішення, створює один патч і запускає перевірки.
Під час перевірки розглядайте файл як спільний незмінний вхідний ресурс. Надавайте одній сесії доступ на запис лише після завершення обговорення.
Це відрізняється від мого поточного гібридного циклу перевірки коду за допомогою AI→, у якому одна модель пише код, а друга перевіряє кожне виправлення. Цей цикл уже дає рецензенту корисну незалежність. Наступний експеримент відкладає запис: спочатку обидві сесії виконують перевірку, а третя починає писати код лише після того, як їхня суперечка породить запис рішення.
Цей шаблон уже близький до того, що підтримують сучасні інструменти для агентів. Документація OpenAI щодо субагентів Codex рекомендує паралельних агентів для дослідження з переважанням операцій читання, тестування, тріажу та перевірки, водночас попереджаючи, що паралельні процеси з великою кількістю операцій запису створюють конфлікти й додаткові витрати на координацію. Бракує лише повноцінного шару обговорення та синтезу між рецензентами й автором.
Навіщо процесу перевірки коду з кількома агентами потрібен один автор?
Паралельний аналіз дає різні гіпотези щодо помилок, не створюючи кількох конкуруючих патчів.
Один рецензент може простежити поведінку та інваріанти. Інший — шукати проблеми безпеки, умови перегонів, відсутні тести або порушення контракту API. Вони починають з одного commit SHA і завдання, але отримують різні інструкції для перевірки. Такий поділ зменшує ймовірність того, що обидві сесії підуть за однією першою ідеєю.
Anthropic описує пов’язаний виробничий шаблон у статті Building effective agents: кілька викликів моделі можуть перевіряти код із різних перспектив, тоді як процес оркестратор-працівники делегує роботу й синтезує результати. Anthropic також радить командам додавати агентну складність лише тоді, коли вона покращує вимірювані результати. Три сесії коштують більше токенів і часу, ніж одна, тому процес має мати причину для існування.
Паралельна зміна файлів рідко є такою причиною. Якщо два агенти редагують одну робочу копію, системі доводиться розв’язувати проблеми застарілого контексту, перекривних фрагментів і частково застосованих припущень. Git уже пропонує безпечніший примітив: пов’язані робочі дерева дають змогу окремим сесіям використовувати ізольований стан `HEAD` та індексу, спільно використовуючи історію репозиторію.
Рецензенти можуть використовувати робочі дерева для експериментів, але лише інтегратор має володіти кандидатним патчем.
За що відповідає кожна AI-сесія?
| Сесія | Доступ | Обов’язковий результат | Не повинна робити |
|---|---|---|---|
| --- | --- | --- | --- |
| Рецензент A | Знімок лише для читання | Ризики поведінки, порушені інваріанти, посилання на рядки, запропоновані тести | Редагувати фінальну гілку |
| Рецензент B | Знімок лише для читання | Проблеми безпеки, конкурентність, крайові випадки, контрприклади | Копіювати висновок рецензента A без доказів |
| Інтегратор | Ексклюзивний доступ на запис | Прийнятий патч, відхилені висновки з поясненнями, результати тестів, фінальний diff | Переписувати код за межами узгодженої області |
Третій агент не стає автоматично розумнішим. Його перевага походить від відповідальності. Він отримує обмежені докази, явно розв’язує конфлікти й створює один diff, який можна перевірити.
Я також залишав би рецензентів неознайомленими з першими висновками один одного. Контрольоване дослідження дебатів між кількома агентами виявило, що тиск більшості може придушувати незалежне виправлення. Ранній обмін думками може перетворити двох рецензентів на одну повторювану думку. Незалежні висновки мають з’явитися першими; обговорення слід починати після того, як обидва зафіксують початкові докази.
Як рецензенти мають обговорювати один файл?
Вільний чат корисний для людей, але процесу написання коду потрібен компактний реєстр висновків. Кожне твердження має містити достатньо доказів, щоб інтегратор міг перевірити його без відтворення приватного ланцюжка міркувань.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
Другий рецензент може прийняти висновок, спростувати його аргументом про досяжність коду або звузити його область. Реєстр зберігає обидві позиції. Сама згода не доводить правильність, а впевнений абзац не має переважати над відтворюваним тестом.
Протоколи для агентів рухаються в цьому напрямку. Протокол Agent2Agent від Google моделює співпрацю через завдання, повідомлення, стан і артефакти. Локальній системі написання коду не потрібен увесь протокол, щоб запозичити його контракт: використовуйте типізовані повідомлення, стабільні ідентифікатори, явний статус і довговічні артефакти замість неструктурованого транскрипту.
Мій міст для взаємної перевірки коду за допомогою AI→ уже пакує diff, фокусні запитання та структурований вердикт для другої моделі. Процесу з трьома сесіями потрібен наступний рівень: два пакети перевірки, які можуть посилатися на однакові ідентифікатори висновків, оскаржувати їх і розв’язувати суперечки до того, як автор їх отримає.
Що автор має отримати до початку редагування?
Інтегратор не повинен отримувати дві довгі історії чату. Йому потрібен невеликий пакет передачі:
Потім автор повторно читає поточний файл і порівнює його версію з пакетом передачі. Невідповідність зупиняє запис. Одна така перевірка не дає коректній перевірці вчорашнього файлу перетворитися на зламаний патч для сьогоднішнього коду.
Саме тут дозволи також мають стати детермінованими. Я вже виступав за детерміновані дозволи для AI-агентів→, оскільки підказка на кшталт «редагуй лише цей файл» слабша за політику інструмента, яка робить усі інші шляхи доступними лише для читання. У цьому процесі модель дозволів має забезпечувати поділ ролей: рецензенти не можуть записувати, а інтегратор не може розширювати область без нового рішення.
Чи покращує обговорення програмні патчі?
Докази підтримують цей напрям, але не доводять, що кожна команда має використовувати саме двох рецензентів і одного автора.
Improving Factuality and Reasoning in Language Models through Multiagent Debate показує, що кілька екземплярів моделі можуть пропонувати, критикувати й уточнювати відповіді протягом кількох раундів, покращуючи результати на завданнях із міркування та фактичності, розглянутих у статті. Ці експерименти не перевіряли конфлікти Git або виробничі pull request.
Ближчий до написання коду приклад з’явився у препринті 2025 року SWE-Debate. Його агенти обговорюють конкуруючі трасування локалізації помилок, узгоджують план виправлення й передають цей план окремому агенту генерації патчу. У статті повідомляється про 207 розв’язаних завдань із 500 у SWE-bench Verified, тобто 41,4%, порівняно з 38,8% для найсильніших зазначених базових методів. Бенчмарк і архітектура відрізняються від запропонованого мною процесу, але поділ показовий: спочатку різноманітний аналіз, потім один етап модифікації.
Чесний наступний крок — невелика контрольована оцінка на реальних pull request. Порівняйте одного агента написання коду з процесом із трьома сесіями на 10–20 помилках. Вимірюйте коректні висновки, хибні спрацьовування, конфлікти злиття, час до прийнятного патчу та регресії, виявлені після першої версії. Більша кількість повідомлень агентів не є показником успіху.
Як автор створює один патч, який можна перевірити?
Інтегратор має дотримуватися вузького циклу:
Остання перевірка має аналізувати патч, а не починати обговорення дизайну спочатку. Кожен рецензент відповідає на два запитання: чи реалізував автор узгоджене рішення і чи створив патч новий ризик?
Поточний застосунок Codex від OpenAI уже використовує окремі потоки й робочі дерева, щоб агенти могли працювати паралельно, не торкаючись одного локального стану Git, і дає розробникам змогу переглядати та коментувати кожен diff. Оголошення застосунку Codex показує, що рівень ізоляції вже існує. Спільний реєстр висновків і явна роль інтегратора перетворили б паралельні завдання на скоординовану кімнату перевірки.
Які помилки залишаються?
Один автор усуває перегони під час редагування, але не помилки моделі.
Два рецензенти можуть мати одну й ту саму сліпу зону, особливо якщо вони використовують ту саму модель, підказку й контекст. Інтегратор може обрати переконливіший аргумент замість правильного. Коментарі в репозиторії можуть містити ненадійні інструкції. Успішний набір тестів може не охоплювати поведінку, від якої залежать користувачі.
Процес потребує захисних механізмів:
Мій попередній висновок після 21,54 мільярда токенів активності code-agent→ усе ще актуальний: саме система навколо моделі визначає, чи перетвориться додатковий інтелект на корисну роботу або на швидше прибирання наслідків.
Коли процес із трьома сесіями виправданий?
Використовуйте його, коли неправильний патч дорого коштує або код має більше одного правдоподібного трактування: автентифікація, дозволи, платежі, міграції, конкурентність, публічні API та виправлення інцидентів. Він також може допомогти, коли старший інженер зазвичай просить двох спеціалістів перевірити різні області ризику.
Не використовуйте його для форматування, згенерованих файлів, простих перейменувань і змін із очевидним оракулом тесту. Команда Anthropic, яка досліджувала кілька агентів, виявила, що складність координації швидко зростає, а її виробнича дослідницька система залежить від чіткого делегування та провідного агента, який синтезує спеціалізовані результати. Для написання коду потрібна така сама дисципліна, але з меншою терпимістю до неоднозначних записів.
Я хочу, щоб coding agents обговорювали докази до того, як один із них отримає курсор. Дві сесії мають перевірити один і той самий файл, відкрито не погодитися й залишити один запис рішення. Третя має створити кандидатний патч і довести його коректність щодо репозиторію.
Цей кандидат усе одно потребує тестів, перевірки diff і рішення людини щодо випуску. Три AI-сесії можуть покращити шлях до патчу, але не перетворюють патч на істину.
FAQ
Чи можуть два AI-агенти одночасно редагувати один файл?
Можуть, але спільний запис створює застарілий контекст і конфліктні зміни. Дозвольте обом агентам аналізувати одну версію в режимі лише для читання або ізолюйте експерименти в окремих робочих деревах, а потім надайте одному інтегратору ексклюзивний доступ на запис до фінальної гілки.
Чи мають обидва рецензенти використовувати одну модель?
Можуть, але різні підказки, ролі або сімейства моделей здатні зменшити корельовані сліпі зони. Різноманітність не гарантує правильності, тому процес усе одно потребує доказів і тестів.
Що відбувається, коли рецензенти не погоджуються?
Зафіксуйте обидві позиції в реєстрі висновків. Інтегратор має відтворити твердження, запустити запропонований тест або позначити проблему як невирішену для людини. Голосування більшістю — слабка заміна доказам, які можна перевірити.
Чи замінює третя AI-сесія перевірку коду людиною?
Ні. Третя сесія відповідає за синтез і створення кандидатного патчу. Людина все одно вирішує, чи відповідає патч ширшій системі, задуму продукту та ризику випуску.
Чи може цей процес працювати зі змінами в кількох файлах?
Так. Зафіксуйте кожен файл, який перевіряється, на одній і тій самій версії репозиторію, призначте чітку відповідальність і використовуйте одну інтеграційну гілку. Рецензенти можуть працювати в ізольованих робочих деревах, тоді як інтегратор залишається єдиною сесією, яка збирає фінальний патч.
---