Human-in-the-loop: когда AI должен остановиться и спросить разрешения

Представьте: вы попросили AI-ассистента «причесать» Figma-файл перед демо. Через минуту он переименовал 80 слоёв, удалил «лишние» фреймы из архива, перекрасил половину компонентов в новый primary и закоммитил всё в основную ветку Git-плагина. Технически — выполнил задачу. Фактически — стер три дня работы коллеги, который держал черновики в том же файле.

Это не страшилка про восстание машин. Это типичный сценарий, когда AI слишком уверен в своих полномочиях, а человек слишком уверен в AI. Human-in-the-loop (HITL) — это не модный термин из ресёрча, а конкретный дизайн-принцип: где именно в потоке работы AI обязан остановиться, показать намерение и дождаться подтверждения.

Чем мощнее становятся агенты — Figma MCP, Cursor, Claude Code, кастомные пайплайны на n8n — тем чаще проблема не в том, что AI не справился. А в том, что справился слишком хорошо и слишком быстро, не в ту сторону.

## Почему это вообще проблема

Раньше интерфейс был понятный: пользователь нажал — система ответила. Один клик — одно действие. AI ломает эту логику. Одна фраза в чате может породить десятки операций: чтение файлов, запись, удаление, сетевые запросы, изменения в shared-документах.

И вот здесь возникает разрыв доверия:

• Пользователь думает, что согласился на «помоги с файлом».
• AI понял это как «делай что считаешь нужным со всем содержимым».
• Откатить изменения часто либо невозможно, либо очень дорого.

### Три типа цены ошибки

Перед тем как проектировать чекпоинты, полезно разделить действия по обратимости.

• Дешёвые и обратимые. Подсветить слой, предложить вариант копирайта, сгенерировать черновик в отдельном фрейме. Здесь спрашивать каждый раз — значит душить поток.
• Дорогие, но обратимые. Массовое переименование, рефакторинг компонентов, миграция токенов. Откатить можно, но это часы работы и нервы.
• Необратимые или с внешним эффектом. Коммит в main, отправка письма, публикация в Figma Community, удаление файлов, оплата по API, изменения в продакшн-базе.

Правило простое: чем правее в этом списке — тем громче и явнее должна быть остановка.

## Где именно AI должен спрашивать

Хороший HITL — это не «подтвердите действие» на каждом шаге. Это набор осознанных чекпоинтов, расставленных там, где цена ошибки выше цены трения.

### Чекпоинт 1: перед действиями с blast radius > 1 объекта

Если операция затрагивает один слой, одно сообщение, один файл — обычно можно делать. Если она трогает 10, 100, 1000 — обязательно показать список и спросить.

На ревью это выглядит так: AI говорит не «переименовал 240 слоёв», а «нашёл 240 слоёв под переименование, вот первые 10 примеров — продолжать?».

### Чекпоинт 2: перед действиями с внешним эффектом

Всё, что выходит за пределы локальной песочницы:

• отправка в Slack, email, мессенджеры;
• коммиты, пуши, PR, мержи;
• публикация, шаринг ссылок;
• запросы к платным API;
• действия с правами/доступами.

Здесь даже одно действие требует подтверждения. Не потому что AI не справится, а потому что отозвать сообщение, увиденное командой, нельзя.

### Чекпоинт 3: перед необратимым удалением

Удаление фреймов, веток, файлов, записей в базе. Корзина и git history спасают не всегда: в Figma удалённые компоненты ломают инстансы по всему файлу мгновенно.

### Чекпоинт 4: при смене намерения

Это тонкий случай. Пользователь попросил «почистить отступы», а AI по дороге решил «заодно привести цвета к токенам». Даже если это полезно — это новая задача. Правильное поведение: закончить исходную, показать предложение по второй, дождаться «да».

## Анти-паттерны, которые встречаются чаще всего

• Слепое «Apply all». AI показывает 40 предложений и одну кнопку «принять всё». Человек жмёт — потому что лень кликать 40 раз. Это не HITL, это его имитация.
• Подтверждение без контекста. «Выполнить 17 операций? Да/Нет». Без списка, без примеров, без диффа. Подтверждать тут нечего — только угадывать.
• Подтверждение постфактум. «Я сделал X. Откатить?» — звучит вежливо, но это уже не loop, а уведомление. Особенно опасно для внешних действий.
• Диалоговая усталость. AI спрашивает буквально про всё, человек за день привыкает жать Enter, и в момент реально опасного действия делает это на автомате.

## Быстрый чеклист для команды

Если вы внедряете AI-фичу — пройдитесь по этим вопросам до релиза:

• Для каждого действия агента понятен blast radius: 1 объект, N объектов, внешний эффект.
• Необратимые действия требуют явного подтверждения с превью.
• В подтверждении видно что именно произойдёт, а не сколько операций.
• Есть «undo» для всего, что можно откатить, и нет иллюзии undo для того, что откатить нельзя.
• AI не смешивает несколько намерений в одном подтверждении.
• Сценарий «человек жмёт Enter не глядя» не приводит к катастрофе.

Короткий итог: HITL — это не про недоверие к модели. Это про дизайн интерфейса, в котором у человека остаётся реальный, а не декоративный контроль над дорогими и необратимыми действиями. Дальше разберём, как расставлять чекпоинты в конкретных пайплайнах — от Figma-плагинов до агентов в IDE.

## Рабочий процесс: как встроить HITL в реальный пайплайн

Чекпоинты на бумаге — это половина дела. Дальше важно, чтобы они срабатывали внутри того конкретного инструмента, с которым работает команда. Figma-плагин, агент в IDE, бот в Slack, скрипт миграции токенов — везде остановки выглядят по-разному, но логика одинаковая: сначала намерение, потом превью, потом действие.

### Шаг 1. Опиши намерение словами

Прежде чем агент что-то сделает, он формулирует план на естественном языке: «пройдусь по 18 экранам в файле Onboarding v3, заменю hex-значения на токены из библиотеки Core/Color, не трогаю тексты и автолэйауты». Это страховка от смены намерения по ходу: если в плане нет «удаления неиспользуемых стилей» — он этого не делает, даже если очень хочется.

### Шаг 2. Покажи dry-run

Любой агент, который собирается сделать больше пяти операций, должен уметь dry-run: «вот что я сделаю, ничего ещё не применено». В Figma это отдельный фрейм с before/after. В IDE — дифф. В скрипте — лог в консоль без записи в базу. Если dry-run невозможен технически — это сигнал, что фичу рано отдавать пользователю.

### Шаг 3. Подтверждение с шансом сузить scope

Хорошее подтверждение — не «Да/Нет», а «Да всё / Да только эти / Нет». Человек должен иметь возможность снять галочки с трёх странных случаев и применить остальные 37. Бинарный выбор заставляет либо принимать мусор, либо отменять полезную работу.

### Шаг 4. Применение с журналом

После подтверждения агент пишет, что именно он сделал, и оставляет точку отката. Не «готово», а «обновил 37 слоёв, лог здесь, undo — Cmd+Z или кнопка ниже».

## Как диагностировать, что HITL сломан

Часто проблема не в том, что подтверждений нет, а в том, что они есть, но не работают. Симптомы, по которым это видно:

• В команде кто-то регулярно говорит «ой, я не туда нажал».
• Подтверждения проскакивают не глядя — потому что они одинаковые для безопасных и опасных действий.
• После работы агента уходит время на «починить то, что он наделал».
• Никто не помнит, что именно агент сделал вчера — нет журнала.
• В ретро всплывают истории «он сам решил, что так лучше».

Если хоть один пункт повторяется — это не пользовательская халатность, это дизайн-долг в самом продукте.

## Как дизайнеру применять это в макете

HITL — это не настройка под капотом, это видимый паттерн в UI. Несколько приёмов, которые работают почти всегда.

### Разделяй кнопки по весу

Безопасное действие — основной цвет, привычное место. Дорогое — вторичная кнопка, отдельная позиция. Необратимое — деструктивный стиль и явный текст глагола: не «Продолжить», а «Удалить 240 слоёв».

### Показывай объект, а не количество

«Заменить шрифт в 14 фреймах» — слабо. «Заменить Inter на SF Pro в этих фреймах: Onboarding/Step-1, Onboarding/Step-2…» — сильно. Список объектов снимает с человека работу по угадыванию.

### Делай превью обязательным, а не опциональным

Если для подтверждения нужно нажать «показать дифф» — половина не нажмёт. Дифф должен быть видимым сразу, кнопка — рядом с ним.

### Защити «Enter не глядя»

Для деструктивных действий — сдвинь фокус с кнопки подтверждения, добавь короткую задержку, потребуй вписать имя объекта. Это раздражает ровно один раз — в момент, когда спасает файл.

## Вопросы для ревью макета с AI-действием

Когда приносишь дизайн фичи с агентом на ревью, прогони его по короткому списку:

• Что именно произойдёт после клика — это видно до клика?
• Какой scope действия, и можно ли его сузить прямо здесь?
• Есть ли способ откатить, и насколько он очевиден?
• Что увидит человек, если агент ошибся — ошибку, тишину или фальшивый успех?
• Отличается ли подтверждение опасного действия от подтверждения безопасного хотя бы визуально?
• Что произойдёт, если человек закроет окно в середине операции?

Если на два вопроса ответ «не знаю» — макет ещё не готов, независимо от того, как он выглядит.

## Короткий итог сегмента

Рабочий HITL — это четыре шага (намерение, превью, подтверждение с возможностью сузить scope, журнал) и набор визуальных приёмов, которые не дают человеку случайно согласиться на дорогое действие. Дальше посмотрим, как это раскладывается на конкретные сценарии — от автогенерации компонентов до агентов, которые сами правят прод.

## Сценарий 1. Автогенерация компонентов из промпта

Дизайнер пишет «сделай карточку товара в нашем стиле» — и агент создаёт фрейм с фото, ценой, кнопкой. Безопасно? Почти. Опасно становится, когда тот же агент решает заодно «обновить» существующий компонент Card/Product, потому что счёл новую версию лучше.

Где должен быть HITL:

• Перед записью в библиотеку — всегда подтверждение, даже если изменение «косметическое».
• Перед заменой пропсов, которые ломают обратную совместимость — отдельный экран с перечислением экземпляров, которые сломаются.
• Перед автоматическим detach — никогда не молча.

Анти-паттерн: агент создаёт «Card/Product v2» рядом со старым и считает, что этого достаточно. Через неделю в файле семь версий, никто не знает, какая актуальная.

## Сценарий 2. Массовый рефактор стилей

Замена цветовых токенов, чистка локальных стилей, миграция со старой системы на новую. Это та зона, где люди чаще всего жалеют, что нажали «Применить ко всем».

Что должно быть видно до подтверждения:

• Сколько слоёв затронуто и в каких файлах.
• Сколько из них — мастер-компоненты, а сколько — инстансы и отдельные слои.
• Есть ли пересечения с библиотеками, которые шарятся с другими командами.
• Что произойдёт со слоями, которые не подходят ни под одно правило — пропустим, пометим, спросим отдельно.

Если в подтверждении только число «затронуто 312 объектов» — это не HITL, это лотерея.

## Сценарий 3. Агент, который правит код или прод

Здесь HITL перестаёт быть UX-вопросом и становится вопросом доверия к продукту. Правила, которые работают на практике:

• Любая запись в прод — через PR, не напрямую. Даже если агент «уверен».
• Любая миграция данных — сначала на копии, потом превью диффа, потом подтверждение, потом выполнение.
• Любое действие, которое нельзя откатить за 10 секунд — отдельный класс подтверждения, отличающийся визуально от обычного.

Анти-паттерн: «режим автопилота», в котором агент сам решает, что считать рутиной. Рутину определяет команда заранее и письменно, а не модель в моменте.

## Командный контекст: кто отвечает за решение агента

Когда агент работает один — отвечает тот, кто его запустил. Когда агент работает в общей библиотеке или общем репозитории — нужны явные правила, иначе ответственность размазывается.

Минимум, который стоит зафиксировать:

• Кто имеет право подтверждать действия в shared-библиотеке.
• Кто видит уведомления о крупных изменениях и в каком канале.
• Что считается «крупным» — порог в числах, а не «на глаз».
• Как откатывать чужое подтверждение, если оно оказалось ошибкой.

Без этого появляется классическая ситуация: агент что-то сломал, все согласны, что виноват «процесс», и никто конкретно не чинит.

## Как проверять качество HITL-паттерна

Прежде чем выкатывать фичу с агентом наружу, прогоните её через четыре теста.

### Тест «новый человек»

Посадите за макет коллегу, который не участвовал в проектировании. Дайте задачу, в которой агент должен сделать что-то крупное. Смотрите молча.

• Понял ли он, что произойдёт, до клика?
• Заметил ли разницу между обычным и опасным подтверждением?
• Смог ли откатить, если что-то пошло не так?

### Тест «уставший в пятницу»

Симулируйте режим, в котором человек кликает быстро и не вчитывается. Если в этом режиме можно случайно подтвердить дорогую операцию — паттерн дырявый, добавляйте трение точечно: задержку фокуса, ввод имени объекта, отдельный шаг.

### Тест «агент ошибся»

Намеренно подсуньте агенту неоднозначный кейс, где он, скорее всего, решит неправильно. Проверьте, что человек:

• видит ошибку, а не фальшивый «успех»;
• понимает, какие из 37 действий применились, а какие — нет;
• может откатить только проблемные, не теряя остальное.

### Тест «через неделю»

Откройте журнал действий агента семидневной давности. Понятно ли по нему, что и зачем было сделано? Если журнал есть, но читать его невозможно — это тот же случай, что журнала нет.

## Как объяснять решение команде

HITL почти всегда добавляет шаги. Продакт спросит, зачем замедлять флоу, инженер — зачем городить подтверждения, если «и так понятно». Аргументация, которая работает на ревью:

• Покажите конкретный кейс, где отсутствие шага стоило времени или данных — свой или чужой, но настоящий.
• Сравните стоимость лишнего клика и стоимость отката. Клик — секунды, откат — часы и нервы.
• Различайте трение, которое раздражает каждый день, и трение, которое срабатывает редко, но в правильный момент. Второе команда обычно принимает спокойно.
• Привяжите подтверждения к классам действий, а не к отдельным кнопкам. «Все действия класса A — без подтверждения, класса B — с превью, класса C — с вводом имени» проще защищать, чем сорок индивидуальных решений.

И отдельный приём: предложите померить. Сколько раз за месяц сработал «опасный» диалог, в скольких случаях человек выбрал «отмена» или сузил scope. Если хоть в одном — паттерн уже окупился.

## Короткий итог сегмента

В продвинутых сценариях HITL — это не одно подтверждение, а несколько классов действий с разной защитой, явные правила ответственности в команде и четыре простых теста на качество. Дальше соберём всё в рабочий чеклист и посмотрим, как встраивать HITL в дизайн-процесс с самого начала, а не прикручивать в конце.

## Чеклист: что должно быть на месте перед выкаткой агента

Этот чеклист — не «галочки для отчёта», а минимум, без которого HITL не работает. Прогоните по нему любую фичу с агентом, прежде чем включать её на пользователях.

### Перед действием

• Каждое действие отнесено к классу: безопасное, обратимое, дорогое, необратимое.
• Для каждого класса заранее описано, какое подтверждение требуется.
• Видно scope: сколько объектов затронет, в каких файлах, на каких страницах.
• Видно намерение агента словами, а не только diff: что именно он хочет сделать и почему.
• Для дорогих и необратимых действий — отдельный визуальный режим, отличающийся от обычного подтверждения.

### Во время действия

• Есть прогресс с возможностью остановить, а не только «отменить уже выполненное».
• Промежуточные ошибки показываются сразу, а не копятся до финала.
• Частичный успех виден как частичный, без маскировки под «готово».

### После действия

• Есть журнал с человеко-читаемой записью: что, где, кем подтверждено, что изменилось.
• Откат работает гранулярно: можно отменить часть, не теряя остальное.
• Есть способ найти и откатить действие через неделю, а не только в текущей сессии.

Если хоть один пункт не закрыт — это не значит «не выкатывать». Это значит — знать, где у вас дырка, и сознательно решить, кто и как её закрывает руками.

## Анти-паттерны, которые встречаются чаще всего

### «Подтвердить всё»

Один диалог на весь батч из десятков действий. Человек либо жмёт ОК не глядя, либо отменяет всё и теряет полезную часть. Лечится разбиением на классы и возможностью снять галочки точечно.

### Подтверждение постфактум

«Агент уже сделал X, Y, Z. Откатить?» Это не HITL, это уведомление об ущербе. Подтверждение, по определению, до действия.

### Кричащий красный на всё подряд

Если каждое второе действие подсвечено как опасное, опасное перестаёт читаться. Красный должен быть редким, иначе он становится фоном.

### Кнопка «всегда разрешать»

Соблазнительно для скорости, разрушительно для безопасности. Если очень хочется — пусть это будет настройка с явным сроком: «не спрашивать в течение часа», а не «никогда».

### Невидимая авторизация

Агент действует от имени человека, который согласовал что-то месяц назад в чате. На ревью никто не может восстановить, кто и когда дал добро. Авторизация должна жить рядом с действием, а не в переписке.

### Журнал «для галочки»

Лог есть, но в нём строки вида action_executed: true. По такому журналу нельзя ни разобрать инцидент, ни обучить новичка. Если запись нельзя прочитать вслух коллеге — её нет.

## Вопросы для дизайн-ревью

Когда смотрите макет с агентом, задавайте не «красиво ли», а:

• Что произойдёт, если человек кликнет «подтвердить», не читая?
• Чем визуально отличается подтверждение обратимого действия от необратимого?
• Где в интерфейсе видно, что именно агент собирается изменить, до того как он это сделает?
• Кто увидит уведомление, если действие затронет shared-ресурс?
• Как выглядит частичный провал — и отличается ли он от полного успеха?
• Откуда я узнаю через неделю, что это действие выполнил агент, а не человек?
• Есть ли путь откатить одно действие из батча, не трогая остальные?
• Какое из подтверждений в этом флоу самое частое — и не превратилось ли оно в шум?

Если на любой из вопросов ответ «не знаю» или «как-нибудь разберёмся» — макет не готов к ревью, он готов к доработке.

## Практический итог

HITL — это дизайн-задача, а не настройка модели. Решается она на уровне классов действий, визуальной иерархии подтверждений, журналов и командных правил, кто за что отвечает. Чеклист выше — не идеал, а нижняя планка: если она закрыта, агент перестаёт быть источником сюрпризов и становится инструментом, с которым можно жить в продакшене. Дальше работа простая и скучная: раз в спринт пересматривать пороги, чистить шумные подтверждения, добавлять трение туда, где случился инцидент, и убирать оттуда, где оно мешает без причины.