Что нельзя давать AI: как я выстроил фреймворк после 13 задач в production

Семь из тринадцати задач в моей системе проходят через меня. Пять работают сами. Одну я никогда не отдам алгоритму — даже на стадии «сначала покажи, потом сделаю».

Это и есть ответ на вопрос «что нельзя давать AI в работе». Только не в виде готового списка — в виде критерия, который я сформулировал методом ошибок. Называю его «тест самопрезентации»: если результат идёт от моего имени в мир и я не могу его проверить в момент публикации — это не auto.

Звучит очевидно. Применяется постоянно.

Откуда взялся этот вопрос

Несколько месяцев назад я построил систему из 13 cron-задач для ежедневной LinkedIn-рутины. Задачи разные: одни читают ленту и пишут черновики комментов, другие смотрят профили, третьи снимают статистику. Полный разбор той системы — отдельная статья.

Но пока я проектировал эту систему, мне пришлось ответить на вопрос, который обычно замалчивают: что именно из этого списка я готов отдать AI полностью, а что нет? И почему?

У большинства разработчиков, которые начинают работать с AI-агентами, нет ответа на этот вопрос. Есть два режима.

Первый: «не доверяю, пусть только объясняет код». Инструмент есть, прироста нет.

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

Мне нужен был рабочий критерий. Не «доверяю / не доверяю», а конкретный вопрос, который можно задать про каждую задачу.

Тест самопрезентации

Вопрос звучит так: если этот вывод уйдёт от моего имени прямо сейчас, без моей проверки — мне будет за него комфортно?

Если нет — это approval gate.

Под «от моего имени» я понимаю не только публичные посты. Клиентское письмо — это от моего имени. Коммент под чужим постом — от моего имени. Код, который AI написал и который я не прочитал, но уже вложил в PR — это тоже от моего имени. Даже если технически подпись под ним стоит «AI-assisted».

Важный нюанс: approval gate — это не «AI делает, а потом я всё равно переписываю». Это «AI делает черновик, я читаю 30 секунд, ставлю OK или удаляю». Ценность в скорости подготовки. Не в автономности.

Три класса задач

Из 13 задач я получил три класса. Они приложимы за пределами моей LinkedIn-системы.

Approval-gate — задача генерирует что-то, что пойдёт от моего имени. T1 (черновики комментов под чужими постами), T4 (кандидат на repost), T8 (черновики replies на мои посты), T13 (черновик статьи). Общая черта: результат публичный, он несёт мой голос, ошибка видна всем. Семь из тринадцати.

Auto — задача делает действие, которое я бы делал руками и которое не несёт текстовый вывод от моего лица. T3 (подписка на хэштеги), T5 (follow компаний), T6 (просмотры профилей), T11 (snapshot SSI в таблицу), T12 (обновление статистики постов). Ошибка здесь измеримая и обратимая: лишний follow — не катастрофа. Пять из тринадцати.

Never — отдельная история. T10, подсказка кандидата на Featured-пост, я попросил систему не приносить мне даже черновик. Просто снимать статистику и молчать. Featured — это первое, что видит незнакомый человек на моём профиле. Это не вопрос какой пост самый популярный. Это вопрос как я хочу выглядеть. Алгоритм не знает, что я сейчас хочу подчеркнуть. Один из тринадцати.

Где я поставил gate не туда

T7 — connect-request с персональной запиской. Первые две недели я держал его на approval. Потом переключил на auto (в рамках лимита 5 в день).

Это была ошибка. Не из-за качества текста — AI пишет нормальные записки. Из-за контекста. Connect-request я отправляю конкретному человеку, с которым хочу строить отношения. Это начало разговора, не транзакция. Модель не знает, что я уже читал этот аккаунт три месяца, или что этот человек — CTO из компании, с которой у меня переговоры.

Вернул gate. Потерял в скорости, выиграл в том, что каждый connect — это действительно я.

Вывод: auto-статус можно присваивать задаче, только если контекст задачи не меняется от случая к случаю. Если у каждого исполнения есть уникальный контекст, который влияет на решение — это approval.

За пределами LinkedIn

Тот же фреймворк я использую при работе с Claude Code.

Написать тесты для уже написанного метода — auto в моей голове. Я даю Claude Code писать тесты и не читаю каждый. Тесты запускаются, если падают — смотрю. Это эквивалент T11: измеримый вывод с встроенной проверкой.

Предложить архитектуру для нового модуля — никогда. Не потому что AI не может набросать вариант. Может. Но решение об архитектуре несёт мою ответственность перед клиентом на годы вперёд. Это «от моего имени» в самом сильном смысле.

Ответ клиенту на претензию — approval. AI пишет черновик, я читаю. Не потому что черновик будет плохим, а потому что я хочу видеть, что ушло от моего имени, прежде чем оно ушло.

Мониторинг production: в моей системе наблюдения за AI-агентами каждый agent пишет JSONL-лог. Это auto — агент сам пишет, я смотрю при alert или раз в неделю. Ошибка в логе — это не ошибка в коде, которую видит клиент. Gate здесь добавил бы работу без ценности.

Итог: критерий, а не список

Фреймворк не про доверие к модели. Claude сегодня достаточно хорош, чтобы делать большинство задач лучше, чем я делал бы в усталом состоянии. Вопрос не в качестве вывода, а в типе ответственности.

Три вопроса перед тем, как поставить задачу на auto:

1. Результат идёт от моего имени публично или в приватной коммуникации с конкретным человеком? Если да — approval.
2. У каждого исполнения есть уникальный контекст, который влияет на решение? Если да — approval.
3. Ошибка обратима и измерима без участия клиента или аудитории? Если нет — как минимум approval, а скорее всего never.

Если на все три — нет, нет, да — auto. Остальное — approval или never.

Это не «не доверяй AI». Это «знай, где стоит твоя подпись».