Какие задачи отдавать агенту и как их ставить

Разработчик решает, как ставить задачу агенту в своей сессии. Тимлид решает раньше: какие задачи вообще уходят в работу с агентом и в каком виде они лежат в трекере. Хорошо оформленная карточка экономит больше времени, чем любая настройка модели. В этом уроке — как отбирать задачи и шаблон карточки для Kaiten.

Две оси: риск и проверяемость

Удобнее всего смотреть на задачу по двум вопросам. Насколько дорого обойдётся ошибка? Насколько легко проверить результат — тестом, сравнением со скриншотом, запуском?

Правая нижняя клетка не означает «агенту нельзя». Агент полезен и там: разобраться в коде, найти все места вызова, набросать план. Но решение и основной код — за человеком, который понимает последствия.

Признаки задачи, которая подходит агенту

• Понятен критерий готовности. «Форма отправляет заявку, в CRM появляется лид, на e2e-тест есть зелёный прогон».
• Есть похожий образец в коде. «Сделай как в компоненте ContactForm». Агент хорошо воспроизводит шаблоны, которые уже есть в репозитории, — и плохие тоже.
• Задача ограничена. В материалах OpenAI о внутреннем использовании Codex лучшими названы задачи примерно на час или на несколько сотен строк (How OpenAI uses Codex). Документ написан ещё в 2025 году, и с тех пор агенты берут задачи крупнее, но принцип прежний: одна связная единица работы.
• Агент может сам проверить результат. Есть команды тестов, стенд, линтер. Если проверить нечем, сначала задача «написать проверку», потом сама задача.

Признаки задачи, которую надо доработать

• Решение продуктовое, а не техническое: «сделать удобнее», «как у конкурентов».
• Нужны данные или доступы, которых нет в репозитории: макет только в голове дизайнера, договорённость с клиентом в переписке.
• Задача затрагивает несколько команд или сервисов, и порядок изменений важен.
• Нет способа понять, что результат верный, кроме «посмотреть глазами».

Такую задачу не отвергают — её дробят. Сначала спайк-исследование с агентом в режиме планирования, потом несколько ограниченных карточек.

Шаблон карточки

Документация Codex рекомендует строить запрос из четырёх частей: цель, контекст, ограничения и условие «готово, когда» (best practices). Тот же каркас подходит для карточки в трекере — её прочитает и человек, и агент.

## Цель
Что должно стать возможным и для кого. Одно-два предложения.

## Контекст
- Где в коде: файлы, компоненты, похожий образец
- Ссылки: макет, ТЗ, обсуждение (то, что нужно, скопировать сюда)
- Как воспроизвести (для багов): шаги, ожидаемое и фактическое

## Ограничения
- Что не трогать
- Какие решения уже приняты
- Совместимость, производительность, безопасность

## Готово, когда
- Проверяемые условия: тест, сценарий, скриншот
- Какие команды должны пройти

Ключевое — раздел «Контекст»: ссылки на внешние документы агенту бесполезны, если у него нет к ним доступа. Нужное из переписки с клиентом копируется в карточку, а долгоживущие решения — в docs/ репозитория.

Пример: до и после

Было:

Починить форму обратной связи, не уходят заявки

Стало:

Цель: заявки с формы «Связаться» на странице /contacts снова
попадают в CRM.

Контекст:
- Компонент plugins/site/forms/components/ContactForm.php,
  отправка через сервис CrmClient.
- С 14:00 вчера в логе CRM-клиента ошибка 422,
  фрагмент приложен ниже.
- Похожая форма, которая работает: CallbackForm.

Ограничения:
- Не менять контракт CrmClient: им пользуются ещё три формы.
- Персональные данные в логи не писать.

Готово, когда:
- Есть тест, который падал до исправления и проходит после.
- e2e-тест tests/e2e/contact-form.spec.ts зелёный.
- В описании MR указана причина ошибки.

Второй вариант агент возьмёт без уточнений. Заметьте: он полезен и человеку — новичок в проекте справился бы с ним так же.

Метка «готово для агента»

Чтобы карточки не оценивались каждый раз заново, заведите в трекере метку или колонку вроде «agent-ready». Карточка получает её, когда в ней заполнены четыре раздела и есть способ проверки. Кто ставит метку — аналитик, тимлид или сам разработчик — договоритесь в команде.

Некоторые команды идут дальше и делают трекер точкой управления агентами: каждой карточке соответствует свой агент и своё рабочее пространство. Так устроена открытая спецификация Symphony от OpenAI; авторы при этом отмечают, что неоднозначные задачи, требующие суждения, остаются интерактивными. Этот уровень разобран в курсе по harness engineering — «Оркестрация параллельных агентов».

Попросите агента помочь со сборкой карточки

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

Вот описание задачи от менеджера: <текст>.
Изучи репозиторий и подготовь карточку по шаблону
Цель / Контекст / Ограничения / Готово, когда.
В «Контексте» укажи конкретные файлы и похожие места в коде.
Отдельным списком выпиши вопросы, на которые нельзя ответить
по коду, — их я задам аналитику.

Список вопросов часто полезнее самой карточки: он показывает, где задача ещё не готова.