Делегирование: что отдавать ИИ, а что нет
Самая частая причина плохого результата от ИИ — не плохой промпт, а то, что модели отдали не ту задачу или отдали её целиком, когда нужно было отдать часть. Делегирование — первый навык модели 4D, и он про решение, которое принимается до того, как вы открыли чат. В этом уроке — как это решение принимать.
Сначала задача, потом инструмент
Первая составляющая делегирования — осознание задачи. Прежде чем что-то делегировать, нужно ответить себе на три вопроса.
Что я хочу получить в итоге? Не «текст», а «письмо, после которого клиент согласует перенос срока». Не «код», а «функция, которая проходит вот эти тесты и не ломает существующие».
Что я считаю хорошим результатом? Какие у него признаки: длина, точность, тон, соответствие стандарту команды. Если вы не можете это сформулировать, вы не сможете ни описать задачу, ни проверить результат.
Что в этой задаче требует моего суждения? В любой работе есть части, которые можно сделать по правилам, и части, где нужен человек, который знает контекст, отношения, историю. Эти части нужно увидеть заранее.
Полминуты на эти три вопроса экономят полчаса переделок. Хорошая привычка — записать ответы одной строкой каждый, прямо в начале промпта. Тогда осознание задачи автоматически становится частью описания.
Что умеет инструмент под рукой
Вторая составляющая — осознание платформы. Одна и та же модель в разных оболочках умеет разное, и это влияет на то, что ей можно отдать.
Чат в браузере видит только то, что вы вставили или прикрепили. Он не знает вашего репозитория, не видит трекер, не помнит прошлых разговоров (если у продукта нет функции памяти). Зато он удобен для обсуждений и черновиков.
Ассистент с подключёнными источниками — поиском, файлами проекта, MCP-серверами — может опираться на актуальные данные. Ему можно отдавать задачи, где нужна свежая информация или содержимое ваших документов.
Агент вроде Claude Code сам читает и меняет файлы, запускает команды, прогоняет тесты. Ему можно отдать не «напиши функцию», а «реализуй задачу и убедись, что тесты проходят». Но у него и больше возможностей сделать что-то не то, поэтому ему нужны границы.
Полезно один раз выяснить про свои инструменты: что модель видит без моей помощи, что может сделать сама, что для неё недоступно. Если не уверены — спросите её саму: «какие у тебя есть инструменты и к чему у тебя есть доступ в этом разговоре?».
Кто делает какую часть
Третья составляющая — собственно распределение работы. Здесь помогают несколько критериев.
Насколько легко проверить результат? Чем легче проверка, тем смелее делегируем. Переписанный абзац проверяется чтением. Правильность SQL-запроса — запуском. Достоверность утверждения о бизнесе клиента — только звонком клиенту. Первое отдаём, второе отдаём с обязательной проверкой, третье не отдаём.
Какова цена ошибки? Опечатка во внутреннем черновике — ничего. Неверная цифра в коммерческом предложении — потерянный контракт. Чем выше цена, тем больше доля вашей работы: как минимум полная проверка, как максимум — сделать самому.
Есть ли у модели всё нужное? Если задача требует знаний, которых нет ни в её обучении, ни в вашем запросе, ни в подключённых инструментах, — результат будет выдуман. Либо дайте ей эти знания, либо не делегируйте.
Требуется ли суждение о людях и отношениях? Как отреагирует конкретный клиент на прямой отказ, стоит ли поднимать вопрос о бюджете сейчас — это ваше. Модель может помочь сформулировать, но решение о том, что говорить, остаётся за вами.
Это разовая задача или повторяющаяся? Разовую можно сделать в чате. Повторяющуюся стоит оформить как шаблон, инструкцию или, если у вас есть Claude Code, как навык — тогда описание задачи пишется один раз. Об этом подробнее в следующем уроке.
Три режима как результат делегирования
Вспомним три режима из первого урока. Правильное делегирование — это выбор режима для каждой части задачи.
Автоматизация — для частей, где вы точно знаете, что нужно, и результат легко проверить. Разработчик: «сгенерируй тесты для этих трёх функций по образцу существующих». Тестировщик: «преобразуй этот список багов в таблицу с колонками серьёзность, шаги, ожидаемый результат».
Дополнение — для частей, где нужно подумать, а не выполнить. Аналитик обсуждает с моделью, не упустил ли он сценарии для роли администратора. Дизайнер просит сыграть роль пользователя, который впервые открыл приложение, и пройти сценарий вслух. Здесь результат — не текст модели, а ваше решение, принятое после диалога.
Агентность — для частей, где модель может работать сама по понятным правилам, а вы проверяете итог. Claude Code исправляет все места, где используется устаревший метод, и запускает тесты. Здесь важно заранее описать границы: что можно менять, что нельзя, когда остановиться и спросить.
Большинство реальных задач смешанные. Написать ТЗ — это дополнение (обсудить структуру и пробелы), потом автоматизация (оформить по шаблону), потом снова дополнение (найти противоречия). Умение разрезать задачу на такие куски и есть навык делегирования.
Две крайности, которых стоит избегать
Отдать всё. «Напиши ТЗ для интернет-магазина». Модель напишет — длинно, гладко и ни о чём, потому что не знает ни клиента, ни продукта, ни ограничений. Потом это ТЗ придётся либо переписывать, либо, что хуже, оно уйдёт дальше как есть.
Не отдавать ничего. Делать руками то, что модель сделала бы за минуту и что легко проверить: переформатирование, черновики писем по заметкам, тесты по образцу, объяснение незнакомого кода. Это не принципиальность, а потеря времени.
Грамотное делегирование почти всегда где-то посередине: суждение, контекст и ответственность — у вас; черновики, варианты, структурирование, рутина — у модели; обсуждение — вместе.
Попробуйте сами
10–15 мин на рабочем месте- Возьмите одну сегодняшнюю задачу продолжительностью не меньше часа. Разрежьте её на 3–5 частей и для каждой напишите режим: сам, автоматизация, дополнение, агентность. Обоснуйте одним словом: «проверяемо», «дорого», «нужен контекст», «суждение».
- Спросите свой основной ИИ-инструмент: «Какие инструменты и источники данных тебе доступны в этом разговоре? Что ты не можешь сделать?». Запишите ответ — это ваша карта платформы. Проверьте один пункт на практике.
- Найдите в своей работе одну повторяющуюся задачу, которую вы каждый раз делаете руками (еженедельный статус, чек-лист регресса, шаблон письма). Оцените, какая её часть — автоматизация, и попробуйте её отдать.
Коротко
- Делегирование начинается до чата: что хочу получить, что считаю хорошим результатом, где нужно моё суждение.
- Одна модель в разных оболочках умеет разное; выясните, что видит и может ваш инструмент.
- Критерии: легко ли проверить, какова цена ошибки, есть ли у модели всё нужное, нужно ли суждение о людях, повторяется ли задача.
- Режимы: автоматизация — выполнить; дополнение — подумать вместе; агентность — работать самостоятельно в границах.
- Реальные задачи смешанные; навык — разрезать их на части и каждой назначить режим.
- Обе крайности плохи: «отдать всё» даёт текст ни о чём, «не отдавать ничего» теряет время.
Видеоверсия
Сценарий озвучки · 447 слов, ≈ 3 мин
Самая частая причина плохого результата от ИИ — не плохой промпт. Это то, что модели отдали не ту задачу или отдали её целиком, когда нужно было отдать часть. Делегирование — первый навык модели четыре Д, и оно происходит до того, как вы открыли чат.
Первая составляющая — осознание задачи. Три вопроса. Что я хочу получить в итоге? Не «текст», а «письмо, после которого клиент согласует перенос срока». Что я считаю хорошим результатом? Длина, точность, тон, соответствие стандарту команды. И что в этой задаче требует моего суждения? В любой работе есть части по правилам и части, где нужен человек, который знает контекст и отношения. Полминуты на эти вопросы экономят полчаса переделок.
Вторая составляющая — осознание платформы. Одна и та же модель в разных оболочках умеет разное. Чат в браузере видит только то, что вы вставили. Ассистент с подключёнными источниками может опираться на актуальные данные. Агент вроде Claude Code сам читает и меняет файлы, запускает тесты — ему можно отдать не «напиши функцию», а «реализуй задачу и убедись, что тесты проходят». Но у него больше возможностей сделать что-то не то, поэтому ему нужны границы. Если не уверены, что умеет ваш инструмент, спросите его самого.
Третья составляющая — распределение работы. Несколько критериев. Насколько легко проверить результат? Переписанный абзац проверяется чтением, запрос к базе данных — запуском, а утверждение о бизнесе клиента — только звонком клиенту. Первое отдаём, второе отдаём с проверкой, третье не отдаём. Какова цена ошибки? Опечатка во внутреннем черновике — ничего, неверная цифра в коммерческом предложении — потерянный контракт. Есть ли у модели всё нужное? Если знаний нет ни в обучении, ни в запросе, ни в инструментах, результат будет выдуман. Нужно ли суждение о людях? Как отреагирует конкретный клиент — это ваше.
Правильное делегирование — это выбор режима для каждой части задачи. Автоматизация — для частей, где вы точно знаете, что нужно: сгенерируй тесты по образцу существующих. Дополнение — для частей, где нужно подумать: аналитик обсуждает с моделью, не упустил ли он сценарии для администратора, дизайнер просит сыграть нового пользователя и пройти сценарий вслух. Агентность — для частей, где модель может работать сама по понятным правилам: исправь все места с устаревшим методом и прогони тесты. Большинство задач смешанные. Написать ТЗ — это обсудить структуру, потом оформить по шаблону, потом найти противоречия. Умение разрезать задачу на такие куски и есть навык делегирования.
Две крайности. Отдать всё: «напиши ТЗ для интернет-магазина». Модель напишет длинно, гладко и ни о чём, потому что не знает ни клиента, ни продукта. Не отдавать ничего: делать руками переформатирование, черновики по заметкам, тесты по образцу. Это не принципиальность, а потеря времени. Грамотное делегирование посередине: суждение, контекст и ответственность у вас, черновики и рутина у модели, обсуждение вместе.
Попробуйте сегодня: возьмите одну задачу на час, разрежьте на три-пять частей и каждой назначьте режим. В следующем уроке посмотрим, как это масштабируется на целый проект.