Консиліум: три агенти знайшли різні проблеми в проекті

whitetrd · 16.02.2026 · 4 min read

Коли питаєш одного агента “що думаєш про цей код?” — отримуєш одну перспективу. Логічну, послідовну, але одну. Він не сперечається сам із собою. Не дивиться на проблему з різних боків. Просто видає список зауважень зі своєї єдиної точки зору.

Я вирішив спробувати інакше. Запустив п’ять незалежних експертів на один і той самий проект. Кожен нічого не знав про інших. Результат здивував.

Консиліум — це не команда

Спершу розберемось з термінами. Є два принципово різних підходи до мультиагентності.

КОМАНДА (Team)                    КОНСИЛІУМ (Consilium)
─────────────────                  ─────────────────────

Завдання                           Проблема
   │                                  │
   ├── Агент A: бекенд           ┌────┼────┐────┐────┐
   ├── Агент B: фронтенд         │    │    │    │    │
   └── Агент C: тести            ▼    ▼    ▼    ▼    ▼
                                  E1   E2   E3   E4   E5
   Мета: швидкість               (архіт) (UX) (бізн) (безп) (перф)
   Принцип: розділяй працю
                                  Мета: якість рішення
                                  Принцип: множинність думок

Команда ділить роботу. Один робить бекенд, інший — фронтенд, третій пише тести. Вони координуються. Мета — зробити швидше.

Консиліум працює інакше. Кілька експертів незалежно дивляться на одну й ту саму проблему. Не координуються. Не знають один про одного. Мета — не швидкість, а якість рішення.

Як медичний консиліум. Кардіолог, невролог і хірург дивляться на одного пацієнта. Кожен бачить своє. Разом — повну картину.

Дослідження підтверджують

Це не моя вигадка. Karpathy формалізував подібні патерни. MIT Media Lab створили MDAgents — систему, що емулює медичну консультацію з кількома спеціалістами. На ICLR 2026 вийшло дослідження Multi-Agent-as-Judge, яке підтверджує: п’ять незалежних експертів знаходять більше проблем, ніж один, навіть якщо кожен окремо слабший.

Один агент дає консистентний список з однієї перспективи. П’ять незалежних — ловлять різне.

Як я це застосував

У мене був проєкт для вайбкодинг-спільноти. Бот, уроки, оплати, прогрес студентів. Функціонально — все працювало. Але код ріс хаотично, і я хотів зрозуміти, що з ним насправді не так.

Claude Code запустив субагентів через Task tool. Кожен отримав однаковий контекст — діаграму архітектури та доступ до коду. Але кожен мав свій фокус: архітектура, UX, бізнес-логіка, безпека, продуктивність.

Ключовий момент — субагенти не знали про існування один одного. Працювали паралельно, не послідовно. Жодної координації.

Чому незалежність критична

Коли агенти бачать відповіді один одного, вони конвергують. Другий агент погоджується з першим або будує на його висновках. Третій бере за основу консенсус. Зрештою отримуєш п’ять варіацій однієї думки.

Незалежність ламає цей ефект. Архітектурний експерт побачив проблеми з coupling між модулями. UX-експерт знайшов неочевидні проблеми в потоці студента. Бізнес-логік вказав на edge cases в оплатах. Жоден з них не повторив іншого.

Від думок до перевірених рекомендацій

Є одна пастка. Консиліум дає думки. Думки агентів без перевірки — це просто галюцинації з додатковою впевненістю.

Після консиліуму я запустив окремого агента, який перевіряв рекомендації через Exa. Чи справді цей патерн вважається best practice? Чи є дослідження, що підтверджують цю проблему? Чи рекомендують це робити інакше?

Без верифікації — це просто п’ять думок. З верифікацією — обґрунтовані рекомендації.

Від рекомендацій до задач

Перевірені рекомендації самі по собі нічого не варті, якщо вони залишаються текстом. Наступний крок — декомпозиція в конкретні GitHub Issues.

Кожна issue отримала опис, контекст, і чітке формулювання того, що треба зробити. Не “покращити архітектуру”, а конкретна задача з конкретним scope.

Повний пайплайн

Весь процес зайняв 92 хвилини і 15 промптів.

  1. Діаграма архітектури проєкту
  2. Запуск п’яти паралельних експертів (консиліум)
  3. Верифікація рекомендацій через Exa
  4. Брейншторм пріоритетів
  5. Створення GitHub Issues

Від “що не так з моїм проєктом?” до конкретного беклогу задач — менш ніж за дві години.

Коли використовувати

Не завжди потрібен консиліум. Ось простий фреймворк.

Один агент:

Консиліум:

Промпт для консиліуму

Ось шаблон, який можна використати в Claude Code. Він запускає субагентів через Task tool з різними фокусами.

Ти — ведучий консиліуму. Запусти 5 паралельних субагентів через Task tool.

Кожен субагент отримує:
1. Однаковий контекст: [опис проєкту, діаграма архітектури, ключові файли]
2. Свій фокус експертизи (один з п'яти):
   - Архітектура та модульність
   - Користувацький досвід та потоки взаємодії
   - Бізнес-логіка та edge cases
   - Безпека та обробка помилок
   - Продуктивність та масштабованість

Інструкції для кожного субагента:
- Ти єдиний експерт. Інших немає.
- Проаналізуй проєкт виключно зі своєї перспективи.
- Знайди 5-7 конкретних проблем з прикладами з коду.
- Для кожної проблеми вкажи: що не так, чому це проблема, як виправити.
- Не намагайся охопити все. Глибина, не ширина.

Після отримання всіх відповідей:
- Зведи результати в єдиний список
- Видали дублікати
- Згрупуй за пріоритетом

Головний інсайт

Субагенти — це не просто виконавці. Це мислителі. Якість через множинність. Дослідження валідують думки. Результат — це задачі, а не текст.

Один агент дає відповідь. Консиліум дає рішення.