Выберите полезную первую задачу для ИИ

Выберите задачу, которую можете проверить

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

Не выбирайте задачу только ради эффектной демонстрации. Масштабная переработка может дать много видимых изменений и скрыть неверные предположения. Небольшая задача покажет, читает ли агент инструкции, соблюдает ли рамки и точно ли сообщает о неуспешных проверках.

Необязательно выбирать самую лёгкую задачу. Выберите ту, для которой команда сможет распознать правильный результат и объяснить, почему он правильный.

Сравните возможные задачи

Рассмотрим три вымышленных запроса для приложения отчётности.

Объяснение помогает изучить рассуждения и подтверждения. Регрессионный тест добавляет контролируемое действие. Архитектурная задача может быть полезна позже, но требует гораздо более точного задания и процесса review.

Для первого упражнения выберите регрессионный тест. Используйте вымышленные даты и локальную ветку. Укажите, что доступ к production, обновление зависимостей и посторонний рефакторинг не входят в задачу.

Запишите условие завершения

«Улучши обработку дат» допускает слишком много трактовок. Задайте конкретное условие: «Если во входных данных недопустимая календарная дата, верни ошибку валидации. Для допустимых дат сохрани документированный результат».

Добавьте примеры допустимых и недопустимых входных данных. Укажите существующую команду тестирования. Попросите агента изучить текущее поведение до изменения файлов. Потребуйте кратко объяснить дефект и привести подтверждения после изменения.

Отличайте результат задачи от выполненного действия. «Агент написал тест» описывает действие. «Тест обнаруживает известный дефект» описывает подтверждение. Тест, который проходит и на правильном, и на неправильном коде, не доказывает наличие нужной защиты.

Наблюдайте за ходом работы

Во время упражнения записывайте, где агенту нужен дополнительный контекст. Проверяйте, читает ли он относящиеся к задаче инструкции репозитория. Замечайте изменения вне рамок задачи и повторение неудачного подхода без новых данных.

Не исправляйте немедленно каждое несущественное решение. Дайте агенту завершить разрешённую обратимую работу, чтобы оценить результат. Вмешайтесь, если следующее действие пересекает установленную границу или продолжение зависит от неуточнённого требования.

После завершения изучите diff и выполните нужные проверки. Запишите время работы агента и своё время на подготовку и review. Эти наблюдения помогут выбрать следующую задачу и улучшить рабочие инструкции.

Расширяйте границы по одной

Если упражнение удалось, усложните задачу по одному направлению. Например, перейдите от одной функции к двум связанным модулям. Или добавьте документированную интеграцию. Явно указывайте разрешения и требования к проверке.

Если упражнение не удалось, установите причину, прежде чем расширять объём работы. Недостаток контекста, неясное требование, недоступное тестовое окружение и ограничение модели требуют разных исправлений. Повышение автономности не решает все четыре проблемы.

Если прототип продолжает использоваться, назначьте ответственного за сопровождение. Новая информация об уязвимостях может требовать действий даже без изменения кода. См. непрерывное управление уязвимостями.