Как я использую ИИ-советы (AI Councils) для решения неоднозначных инженерных задач
Один ИИ-ассистент полезен. Но его недостаточно для сложной программной архитектуры.
Если вы используете ИИ для чего-то большего, чем автодополнение, вы заметите закономерность. Одна модель предлагает решение. Оно выглядит хорошо. Вы его внедряете. А через три дня обнаруживаете серьезный архитектурный изъян.
Это не ошибка модели. Это ошибка вашего процесса. Одна модель редко подвергает сомнению собственные предположения.
Чтобы решать неоднозначные задачи, вам нужен ИИ-совет (AI Council). Это не новая платформа. Это рабочий процесс, в котором несколько ИИ-контекстов рассматривают предложение с разных ролей.
Цель состоит в том, чтобы превратить использование ИИ в управляемый инженерный рабочий процесс.
Вот этот рабочий процесс:
• Постановка задачи: Вы формулируете проблему. • Агент-архитектор: Агент, опирающийся на исходные данные (source-grounded), создает предложение с учетом компромиссов. • Критика ИИ-совета: Различные ИИ-роли рассматривают предложение. • Синтез обратной связи: Агент оценивает все отзывы и выявляет противоречия. • Реестр возражений: Вы отслеживаете все возражения, их серьезность и способы решения. • Человеческое управление: Вы решаете, готов ли план или требуется еще один раунд. • Агент-исполнитель: Отдельный контекст реализует план. • Агент-аудитор: Третий контекст проверяет код на соответствие исходной спецификации.
Сила заключается в разделении ролей. Не спрашивайте просто «что ты думаешь?». Назначайте конкретные роли различным ИИ-сессиям:
- Системный мыслитель: Оценивает системные риски и границы.
- Критический рецензент: Ставит под сомнение предположения и находит логические пробелы.
- Упроститель: Находит излишнюю сложность.
- Рецензент альтернатив: Предлагает различные подходы.
Самая важная часть — это Реестр возражений (Objection Ledger). Без него обратная связь превращается в расплывчатые мнения. Реестр заставляет вас разрешать каждое замечание. Вы помечаете возражения как Open (Открыто), Accepted (Принято), Rejected (Отклонено) или Resolved (Решено). Это создает проверяемую историю принятия решений.
Вы не становитесь «узким местом» из-за постоянного копирования и вставки. Агент, опирающийся на исходные данные, выполняет синтез. Вы выступаете в роли Управляющего (Governor). Вы не выполняете ручную работу. Вы контролируете контрольные точки.
Вы принимаете решения:
- Когда прекратить итерации.
- Когда утвердить спецификацию.
- Когда принять окончательный риск.
Используйте это для рискованного рефакторинга или неопределенной архитектуры. Не используйте это для исправления тривиальных багов. Накладные расходы оправданы только тогда, когда цена ошибки в проектировании высока.
Начните с малого. Используйте одного критика и одного упростителя. Вы сразу увидите ценность.
Источник: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii