Мультиагентний рій для автономного рев’ю коду: Planner, Implementer, Tester, Critic

Блог для розробників TormentNexus опублікував практичний розбір мультиагентної системи, яка виконує автономне рев’ю коду. Статтю передрукували на Dev.to 26 вересня. Автор стверджує, що одному AI-асистенту бракує стримувань і противаг зрілої інженерної команди: пропозиції не перевіряють, виправлення не тестують на побічні ефекти, а дизайнерські наслідки майже не обговорюють.

Чому одного асистента замало

Один агент може повернути код, який синтаксично правильний, але архітектурно слабкий. Альтернатива — змоделювати сильну команду: спеціалізовані агенти взаємодіють в одній організованій розмові й дають не просто відповідь, а перевірене та вдосконалене рішення.

Чотири ролі рою

Кожен агент — це окремий виклик LLM із власним системним промптом. Planner працює як технічний лідер: аналізує код і формує порядок денний рев’ю навколо безпеки, продуктивності та читабельності. Implementer пише конкретне виправлення чи рефакторинг. Tester перевіряє зміни модульними й інтеграційними тестами та скануваннями безпеки. Critic ставить під сумнів припущення, оскаржує архітектуру й перевіряє підтримуваність коду.

Приклад: зміцнення завантажувача конфігурації

У прикладі фігурує коротка функція Python, яка читає YAML-конфігурацію та повертає розділ бази даних. Planner визначає план: проаналізувати ризики безпеки, зокрема path traversal і довіру до даних, покращити обробку помилок для відсутніх ключів і некоректного YAML, а тоді оцінити дизайн. Implementer додає блоки try/except із зрозумілими повідомленнями ValueError, а Tester пише набір тестів pytest для нових шляхів помилок.

Critic радше заперечує, ніж погоджується. Повернення лише config['database'] він називає антипатерном, який приховує повний контекст конфігурації, і вказує на ризик TOCTOU: шлях до файлу можуть змінити між перевіркою та використанням. Його порада — повертати весь config і розв’язувати символьні посилання через os.path.realpath перед відкриттям файлу.

Консенсус і оркестрація

Коли Implementer і Critic не згодні, арбітром виступає Planner. У прикладі він доручає Implementer-у повертати повний config, а Tester-у — оновити тести й додати перевірку безпеки для розв’язання символьних посилань. Увесь цикл працює в чаті зі станом: це спільний список повідомлень, який читають і доповнюють усі агенти, а центральний оркестратор керує чергою ходів за вказівками Planner-а.

Автор перелічує вигоди: глибший аналіз коду, менша потреба в нагляді людини, автоматична документація дизайнерських рішень у журналі чату та простий шлях до вбудови статичного аналізу в процес. Модель масштабується: можна додати DevOps-агента для контейнеризації чи Doc-агента для вбудованої документації.