Задача, отданная агенту одной фразой, кажется самой быстрой формой работы. "Почини баг", "добавь фильтр", "ускорь список" - коротко, понятно, отправлено. Соблазн в том, что так действительно быстрее написать запрос. Но скорость написания и скорость получения нужного результата - разные вещи, и именно их подмена стоит потом дороже всего.
Наивный ход естественен, потому что мы переносим на агента привычку разговаривать с коллегой. Живому человеку хватает намёка: он знает проект, помнит вчерашний разговор, видит ваше лицо и переспросит, если что-то неясно. С этой моделью в голове короткая фраза выглядит достаточной - собеседник ведь достроит остальное сам, как достроил бы человек за соседним столом.
Ломается это там, где у агента нет вашей общей истории, а пробелы задачи он всё равно обязан чем-то заполнить. Не получив цели, он угадает её по формулировке; не получив ограничений, сочтёт разрешённым всё, что не запрещено; не получив критериев, объявит готовым первое, что скомпилировалось. Догадки не отменяют работу - они её направляют, и вы получаете аккуратно сделанное не то. Спорить после этого приходится не с агентом, а с его домыслом, который вы же и оставили без ответа.
Отсюда рабочая рамка: сильная задача - это контракт из пяти полей, и каждое закрывает свой класс догадок. Цель - наблюдаемое изменение поведения, а не название приёма. Контекст - входная точка, issue, версии и relevant files. Ограничения - что нельзя менять, требования совместимости, зона риска. Критерии приёмки - конкретные сценарии, по которым задача считается закрытой. Проверка - команды, ручной сценарий или артефакт, которым результат доказывают.
Разведём поля по смыслу, потому что их часто путают. Цель отвечает на вопрос "что снаружи станет другим": не "добавь кэш", а "повторный запрос того же отчёта возвращается без обращения к базе". Контекст - это не пересказ задачи своими словами, а опорные точки: файл и строка, где симптом виден, номер issue, версия, в которой он воспроизводится. Ограничения очерчивают периметр неприкосновенного: какие сигнатуры и форматы данных менять нельзя, какую совместимость держать, где зона повышенного риска. Критерии - это не повтор цели, а список ситуаций, которые должны сойтись: пустой ввод, максимальный объём, одновременный доступ. Проверка - не обещание "я протестировал", а конкретный способ это увидеть: команда с ожидаемым кодом возврата, сценарий в браузере, файл-артефакт.
Почему именно пять, а не три и не десять. Меньше - и снова открывается щель для догадки: без ограничений агент "заодно" перепишет соседнее, без критериев остановится слишком рано. Больше - и поля начинают дублировать друг друга, а лишние подробности размывают сигнал не хуже пустоты. Пять - это минимальный набор, закрывающий четыре типовые щели интерпретации плюс способ доказать, что щель действительно закрыта.
Цена заполнения этих полей - несколько минут перед стартом, и она кажется избыточной на мелкой задаче. Но эта цена платится один раз и вперёд, тогда как цена пропуска платится в конце и процентами: разбор чужого diff, откат сделанного не туда, повторный заход с уточнением, которое стоило дать сразу. Чем автономнее поверхность и чем длиннее turn, тем сильнее эта разница в вашу пользу. Есть и побочная выгода: заполненные поля переживают саму сессию - они становятся записью о том, что и зачем делалось, к которой возвращаются при ревью, при откате или когда задачу через неделю берёт другой человек.
Это не значит, что каждую реплику нужно оформлять контрактом. На тривиальной inline-правке через Command пять полей избыточны: цель очевидна, проверка - взгляд на diff. Рамка окупается там, где растёт неопределённость или радиус действия: многошаговая работа Devin Local, долгая задача в облаке, всё, что трогает больше одного файла. Правило простое - объём контракта соразмеряют с ценой ошибки, а не пишут по привычке.
Проверять качество самой задачи можно ещё до её отправки, одним тестом: способен ли агент, прочитав контракт, назвать, чем он докажет результат. Если поле проверки пустое или сводится к "должно работать", задача ещё не готова - вы не сможете отличить сделанное от заявленного. Хорошая формулировка та, из которой критерий приёмки и способ проверки вычитываются буквально, без досочинения с вашей стороны.
Типичные провалы повторяют пропущенные поля один в один. Нет цели - получаете решение не той проблемы. Нет ограничений - получаете "улучшения" в местах, которые просили не трогать. Нет критериев - получаете "готово" на половине сценариев. Нет проверки - получаете слово вместо доказательства. Признак у всех один: спор идёт о том, что имелось в виду, а не о том, что видно в diff. Заполните пять полей заранее - и спорить будет не о чем.