Як я використовую ШІ-ради для вирішення неоднозначних інженерних задач

Один ШІ-асистент — це корисно. Але цього недостатньо для складної архітектури програмного забезпечення.

Якщо ви використовуєте ШІ для чогось більшого, ніж автодоповнення, ви помітите закономірність. Одна модель пропонує рішення. Воно виглядає непогано. Ви його впроваджуєте. А потім, через три дні, ви виявляєте величезний архітектурний недолік.

Це не помилка моделі. Це помилка вашого процесу. Одна модель рідко ставить під сумнів власні припущення.

Щоб вирішувати неоднозначні задачі, вам потрібна ШІ-рада (AI Council). Це не нова платформа. Це робочий процес, у якому кілька ШІ-контекстів переглядають пропозицію з різних ролей.

Мета полягає в тому, щоб перетворити використання ШІ на керований інженерний робочий процес.

Ось цей робочий процес:

• Постановка задачі: Ви визначаєте межі проблеми. • Агент-архітектор: Агент, що базується на джерелах, створює пропозицію з аналізом компромісів. • Критика ШІ-ради: Різні ШІ-ролі переглядають пропозицію. • Синтез зворотного зв'язку: Агент оцінює всі відгуки та виявляє суперечності. • Реєстр заперечень: Ви відстежуєте всі заперечення, їхню критичність та способи вирішення. • Людське управління: Ви вирішуєте, чи готовий план, чи потрібен ще один раунд. • Агент-виконавець: Окремий контекст впроваджує план. • Агент-аудитор: Третій контекст проводить аудит коду на відповідність початковій специфікації.

Сила полягає у розділенні ролей. Не питайте просто «що ти думаєш?». Призначайте конкретні ролі різним ШІ-сесіям:

  • Системний мислитель: Оцінює системні ризики та межі.
  • Критичний рецензент: Ставить під сумнів припущення та знаходить логічні прогалини.
  • Спрощувач: Знаходить зайву складність.
  • Рецензент альтернатив: Пропонує різні підходи.

Найважливіша частина — це Реєстр заперечень (Objection Ledger). Без нього відгуки перетворюються на розмиті думки. Реєстр змушує вас вирішувати кожне занепокоєння. Ви позначаєте заперечення як Відкриті (Open), Прийняті (Accepted), Відхилені (Rejected) або Вирішені (Resolved). Це створює запис рішень, піддатний аудиту.

Ви не стаєте «вузьким місцем» через постійне копіювання та вставку. Агент, що базується на джерелах, виконує синтез. Ви виступаєте в ролі Управителя (Governor). Ви не виконуєте ручну роботу. Ви контролюєте етапи перевірки (gates).

Ви приймаєте рішення:

  • Коли припинити ітерації.
  • Коли затвердити специфікацію.
  • Коли прийняти остаточний ризик.

Використовуйте це для ризикованих рефакторингів або незрозумілої архітектури. Не використовуйте це для тривіальних виправлень помилок. Накладні витрати виправдані лише тоді, коли ціна помилкового проєктування є високою.

Почніть з малого. Використовуйте одного критика та одного спрощувача. Ви одразу побачите цінність.

Джерело: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii