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

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

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

Полезно один раз увидеть, как выглядит такая задача в виде контракта. Ниже - короткая формулировка: цель, граница (какой модуль и тесты трогать, зависимости не добавлять), требование сначала воспроизвести ошибку, затем прогнать targeted-тест и typecheck, и в конце показать diff и отдельно перечислить непроверенное. К этой форме возвращаются на каждой новой задаче: именно граница и проверка, а не длина запроса, делают результат оцениваемым.

Порядок шагов внутри задачи важнее их набора. Сначала воспроизвести проблему существующей командой, затем внести минимальное изменение, затем повторить тот же сигнал и убедиться, что он позеленел, и лишь потом расширять проверку на соседние тесты и typecheck. Обратный порядок - сразу "запусти всё" - размывает сигнал: непонятно, что именно починилось, а что сломалось попутно. Узкий сигнал сначала, широкая проверка потом.