ИИ-агенты: как ставить задачи, чтобы не переделывать работу за ними

ИИ-агенты - это не сеньор с десятью годами опыта, который сам догадается, что вы имели в виду. Это хороший работяга: быстрый, неутомимый, исполнительный, но без вашего контекста и без привычки переспрашивать. Задачу он выполнит буквально. Поэтому половина успеха - в том, как она поставлена: цель, контекст, ограничения, критерий "готово" и что делать, если что-то пошло не так.

Я это понял не из курсов, а из собственного конвейера статей. Скилл, по которому агент без меня пишет черновики для этого блога, стартовал 13 июля 2026 года на 66 строках. Сейчас в нём 190 строк и 16 коммитов правок. Почти каждая новая строка появилась после того, как агент сделал ровно то, что я написал, а не то, что я хотел.

Почему ИИ-агент не понимает задачу так, как опытный разработчик?

ИИ-агент не понимает задачу как опытный разработчик, потому что у него нет неписаного знания о проекте: истории решений, договорённостей, прошлых граблей. Сеньор достраивает недосказанное из опыта и переспрашивает. Агент достраивает из среднего по интернету и почти не переспрашивает. Отсюда работа, которая формально по ТЗ, но мимо цели.

Anthropic в документации по промптингу прямо советует думать о Claude как о блестящем, но совсем новом сотруднике, у которого к тому же амнезия: ему нужны явные инструкции (Business Insider, пересказ гайда Anthropic). В гайде по Claude Code та же мысль короче: модель умеет угадывать намерение, но мысли читать не умеет (Claude Code best practices).

Хорошая иллюстрация - исследование METR (июль 2025). 16 опытных опенсорс-разработчиков решали 246 реальных задач в своих же репозиториях, часть - с ИИ (Cursor Pro и Claude 3.5/3.7 Sonnet). Ждали ускорения на 24%, а с ИИ задачи заняли на 19% больше времени. При этом после эксперимента участники были уверены, что ускорились на 20% (METR, arXiv 2507.09089). Одно из объяснений авторов - опытные разработчики опираются на недокументированное знание о своём коде, которого у ИИ нет. Инструменты с тех пор сильно подтянулись, но суть та же: чего нет в задаче и в репозитории, того для агента не существует.

Мой пример попроще. В правилах конвейера было "добавляй в статьи реальные артефакты из проекта". Агент добавил. Взял кусок MEMORY.md - и вместе с ним в статью уехал реальный IP сервера. Нашёл и вычистил 24 августа 2026 года. Агент не сломался и не схалтурил: он сделал ровно то, что просили. Просто никто не сказал ему, что в артефакте бывает то, что светить нельзя. Сеньор бы это понял сам. Работяга - нет.

Как правильно ставить задачу ИИ-агенту

Правильная задача ИИ-агенту состоит из шести частей: цель (зачем), контекст (что уже есть и где лежит), ограничения (чего нельзя), критерий готовности (как проверить), поведение при сбое (что делать, если не получилось) и пример хорошего результата. Пропущенная часть почти всегда возвращается переделкой.

Самые недооценённые пункты - последние три. Цель и контекст люди пишут интуитивно, а вот критерий "готово" и поведение при сбое почти всегда забывают. Хотя именно там агент отличается от сеньора сильнее всего: сеньор сам скажет "слушай, тут задача кривая". Агент чаще доделает кривую задачу до конца.

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

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

Мой конвейер работает так: cron-обёртка раз в несколько часов берёт тему из беклога и запускает Claude Code в headless-режиме со скиллом blog-draft. Человека рядом нет, переспросить не у кого. Значит, всё, что сеньор бы уточнил голосом, должно лежать в тексте скилла. По статусам в базе через конвейер прошло 269 черновиков: 263 опубликованы, 6 отклонены.

История скилла - это по сути журнал моих недосказанностей:

• 5 августа 2026 - перелинковка стала обязательным шагом. До этого я писал "по возможности ставь ссылки", и агент по возможности их не ставил. Сейчас в тексте жёсткое условие: ноль внутренних ссылок - черновик не сдаётся.
• 24 августа 2026 - история с IP выше. После неё в правилах появились запрет любых реальных IP (включая публичные), карт портов и серверных путей, плюс финальный grep-скан текста перед сдачей.
• 21 сентября 2026 - каркас статьи под интент запроса. Аналитика показала, что статьи без структуры под запрос висели на 9-11 позициях при 0% CTR. Агент писал хорошую прозу там, где человек из поиска ждал таблицу. Теперь правило прямое: интент "какие есть / сравнение" - обязательна таблица от 5 строк в первом-втором H2.
• 26 сентября 2026 - самый показательный кейс. Агент честно отказывался писать дубль уже опубликованной статьи. Но обёртка понимала только один исход - "ИТОГ: черновик #". Отказ она считала ошибкой и возвращала тему в беклог. Тема #443 крутилась так каждые 2 часа.

Обратите внимание: агент в этой истории был прав. Он правильно распознал дубль. Сломалась постановка задачи - я не описал, как выглядит законный отказ. Сеньор бы просто пришёл и сказал "это уже написано". Агенту нужно было дать для этого формальный канал.

Вот дословные строки из текущей версии скилла, которые появились после таких историй:

Что не нашлось или попало в серую зону фильтра — НЕ выдумывать,
...
по смыслу абзаца, не «читайте тут». 0 внутренних ссылок =
...
   с кодом 0. Это штатный исход, не ошибка: обёртка не вернёт тему

Ни в одной из них нет ничего умного. Это всё вещи, которые человек с опытом в команде знает "по умолчанию". Агенту их надо написать.

Какую информацию обязательно давать агенту перед началом работы?

Перед началом работы агенту обязательно нужны: где лежит код и правила проекта, что уже сделано (чтобы не дублировать), явные запреты, проверяемый критерий готовности и разрешённый способ сказать "не могу". Всё остальное - тон, примеры, приоритеты - улучшает результат, но без этих пяти пунктов агент работает вслепую.

Порядок, по которому я собираю задачу для агента сейчас:

1. Одна фраза цели. Не "напиши тесты", а "нужны тесты на разлогиненного пользователя, чтобы поймать регрессию в оплате". Пример из гайда Claude Code ровно такой: не "добавь тесты для foo.py", а "тесты для foo.py, покрой случай разлогиненного пользователя, без моков" (Claude Code best practices).
2. Карта контекста. Пути к файлам и команды, а не пересказ. В blog-draft это список: профиль площадки, голос, правила AEO, команда published-titles. Агенту быстрее прочитать файл, чем понять мой пересказ.
3. Запреты с числами. "Короткий заголовок" - не ограничение. "title не длиннее 75 символов" - ограничение, его можно проверить скриптом.
4. Критерий готовности, который проверяется без меня. Тесты зелёные, сборка проходит, в тексте есть хотя бы одна внутренняя ссылка.
5. Выход для "не получилось". Что вернуть, если данных нет, задача противоречивая или уже решена. Без этого пункта агент либо выдумывает, либо упирается.
6. Формат ответа. Особенно если результат читает скрипт, а не человек.

Шаблон, который можно забрать себе:

Цель: <что нужно получить и зачем, одна фраза>
 
Контекст:
- код: <пути к файлам/модулям>
- правила проекта: <CLAUDE.md, docs/...>
- уже сделано: <что не повторять, где посмотреть>
 
Ограничения:
- нельзя: <конкретные запреты>
- лимиты: <числа: длина, время, бюджет, файлы, которые не трогать>
 
Готово, когда:
- <проверяемое условие 1: тесты/сборка/команда>
- <проверяемое условие 2>
 
Если не получается:
- данных не хватает -> не выдумывай, перечисли вопросы
- задача уже решена или противоречит правилам -> остановись и объясни
 
Формат ответа: <что вернуть в конце>

Часть этих пунктов живёт не в каждой задаче, а в постоянных инструкциях проекта. Тут важно не перегнуть: раздутый CLAUDE.md агент начинает игнорировать, об этом пишет и сама Anthropic. Как я переделывал свои инструкции под новые модели - в статье про контекст-инжиниринг для Claude Code и /doctor.

Промпт инжиниринг для агентов: это больше про ТЗ, чем про промпты

Промпт инжиниринг для ИИ-агентов в 2026 году - это не поиск волшебных формулировок, а умение писать нормальное техзадание. По моему опыту, плохой результат чаще даёт не неудачное слово, а пропущенный контекст или отсутствие критерия готовности.

Моя граница простая: если задачу нельзя поставить так, чтобы её результат проверил скрипт или я сам за пару минут, - это не задача для агента без присмотра. Это задача для меня с агентом рядом. Я разбирал эту границу подробнее в тексте о том, какие задачи оставить себе, а какие отдать агенту.

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

Когда подробная постановка задачи не нужна?

Подробная постановка задачи не нужна, когда ошибка дешевле брифа: разовый скрипт, черновой прототип, исследование "покажи варианты". Там быстрее дать агенту сделать, посмотреть и поправить словами в той же сессии. Полный бриф окупается там, где агент работает без вас или где результат уходит в прод.

Мои ориентиры:

• Интерактивная сессия, результат смотрю сразу - достаточно цели и пары путей к файлам. Остальное поправлю по ходу.
• Задача повторяется (каждый день, каждую тему, каждый тикет) - формализовать в скилл или шаблон. Одна недосказанность тут множится на все прогоны, как с темой #443.
• Агент работает headless, по cron - бриф обязателен целиком, включая поведение при сбое. Переспросить ему некого.
• Код, который вы сами не понимаете - тут бриф не спасёт, нужен ещё и способ проверки. Об этом отдельно: как ревьюить AI-код, когда сам не эксперт.

Короче, работяге нужна нормальная смена: что делаем, где инструмент, чего не трогать и как понять, что закончили. Дадите это - он сделает быстро и аккуратно. Не дадите - сделает тоже быстро, но не то :)