Где я намеренно держу approval gate — даже когда могу убрать его совсем
У меня 15 cron-задач. Из них 5 никогда не получат auto-publish — даже если я мог бы технически убрать approval gate за пару часов.
Не потому что сложно. Потому что суждение о конкретном человеке нельзя делегировать.
Это правило я вывел после первой недели с автономным LinkedIn-агентом. До этого я думал, что approval gate — временная мера, пока агент «учится». Оказалось, это архитектурное решение навсегда. Одно из немногих, которые я сделал до того, как заплатил за ошибку.
«Убери человека из цикла» — рефлекс, а не решение
В 2024 году это звучало из каждого утюга. Убери рутину, освободи время, дай AI делать работу. Я согласен с 80% этого утверждения. Реально убрал себя из десяти процессов — от JSONL-логирования до форматирования дайджестов. Это работает, и времени стало больше.
Но я заметил, что «убери человека» часто означает «убери любой контроль, который тебя замедляет». Это другое. Замедление может быть инженерной проблемой. А может быть намеренной точкой суждения. Разница принципиальная.
Когда я стал разбирать свои 15 задач, понял: они делятся на два типа. Структурные — где результат предсказуем по входным данным. И задачи суждения — где правильный ответ зависит от контекста, который система не видит.
Два вида задач: структурные и суждения
Структурная задача выглядит так: «Взять JSONL-лог за вчера, отформатировать в Markdown, положить в папку Inbox.» Алгоритм детерминирован. Ошибка обратима — перезапустил, получил тот же результат. Человек здесь — лишнее звено.
Задача суждения выглядит иначе: «Написать комментарий к посту Максима про React Native.» Алгоритм знает шаблоны. Но он не знает, что Максим три дня назад написал мне в личку с претензией. Он не знает, что тон этого конкретного поста предполагает другую интонацию. Он не знает, что сейчас — не лучший момент.
Проблема в том, что эти два вида задач выглядят одинаково с точки зрения кода. Оба принимают параметры и возвращают результат. Разницу видно только если думать о последствиях.
Пять точек, где у меня стоит gate
Первое — исходящие LinkedIn-запросы на коннект. Система умеет находить релевантных людей, писать персонализированное сообщение. Технически — готово. Но кнопку «Отправить» нажимаю я. Причина: LinkedIn узнал об автоматических запросах с тремя аккаунтами знакомых за три дня. Два из них улетели в бан. Я потерял три дня и нервы. После того как поставил gate — ноль проблем за шесть месяцев.
Второе — финальная публикация длинной статьи. Агент пишет черновик, гоняет его через humanizer, проверяет SEO. Я читаю итог глазами. Не ищу фактические ошибки — агент с этим справляется. Ищу момент, где тон ушёл не туда. За три месяца gate поймал четыре статьи, которые публиковать не стоило: в одной я рассуждал как аналитик, а не как практик; в другой был абзац, который мог обидеть конкретного человека.
Третье — ответ на нестандартный комментарий. Стандартные комментарии («Спасибо!», «Интересно, а как вы..?») агент обрабатывает сам. Но если комментарий сложный — спор, жалоба, неоднозначная ирония — он кладёт его в Inbox с тегом needs-review. Я разбираю руками. Цена ошибки здесь — репутационная, не техническая.
Четвёртое — упоминание реальных клиентских кейсов. Когда агент включает в статью факты из проектов, он не знает, согласился ли клиент на публичность. Это фильтруется на стороне gate. Без него однажды ушёл бы в прод кейс с цифрами, которые клиент считал конфиденциальными.
Пятое — изменения в самой системе автоматизации. Задачи, которые меняют логику других задач, никогда не выполняются автономно. Агент делает diff, я смотрю, я подтверждаю. Иначе один баг в cron-задаче может аффектить восемь других.
Что происходит, когда gate убираешь по ошибке
Неделя без approval gate на LinkedIn-коннекты стоила мне трёх дней в бане и одного испорченного cold outreach к потенциальному клиенту. Цифры: 47 запросов за неделю вместо плановых 5-7 в день. LinkedIn счёл это автоматизацией. Технически это и была автоматизация — просто без контроля.
Есть более тонкий случай. Один из черновиков ушёл бы в прод с формулировкой «мы в студии делаем X». Не критично. Но это не мой голос — я пишу от первого лица, от своего опыта. Агент это не заметил. Я заметил.
Gate — это не про недоверие к AI. Это про то, что некоторые виды ошибок стоят дороже, чем время на ручную проверку.
Когда gate можно убрать
Три условия одновременно:
Первое — задача чисто структурная: на одинаковые входные данные всегда один и тот же тип результата. Форматирование, логирование, сборка шаблонов — да. Публикация от имени — нет.
Второе — ошибка обратима. Если агент положил файл не в ту папку — можно переложить. Если агент опубликовал пост с неправильным тоном — репутация уже пострадала.
Третье — я прогнал задачу руками 20+ раз и не нашёл ни одного случая, где контекст менял решение. Это не про количество итераций. Это про разнообразие ситуаций.
Если все три — gate снимается. Если хоть одного нет — оставляю.
Итог: human-in-the-loop — это архитектура, не слабость
Когда я говорю, что у меня стоит approval gate, иногда слышу: «Ты просто не доверяешь своей системе». Нет. Я ей доверяю ровно в той части, где она детерминирована. Там, где нет — я оставляю суждение за собой.
Это не значит, что система медленная. Структурные задачи работают без меня 24/7. Gate стоит только в точках, где цена ошибки выше, чем цена пяти минут моего времени.
Human-in-the-loop — не тренировочные колёса. Это сознательное решение о том, где граница между машинным и человеческим в конкретной системе.
Подробнее о том, как устроены мои production-паттерны для AI-агентов — в статье про три паттерна доверия. О том, что и как логировать, чтобы знать, что реально происходит — в материале про мониторинг 13 агентов. О том, как писать task-спеки для автономных агентов так, чтобы они работали без уточняющих вопросов — отдельная статья.