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

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

Ломается это на невозможности проверить. Крупный diff на незнакомом поведении агента нельзя ни быстро прочитать, ни уверенно принять; "вроде работает" - это не доказательство, а отступление. Без наблюдаемой цепочки от запроса до проверки первый цикл не учит ничему, кроме общего впечатления, а впечатление не переносится на следующую задачу.

Профессиональный ход - сознательно уменьшить масштаб до наблюдаемого. Откройте небольшой репозиторий и проверьте статус Git. Попросите режим Ask объяснить один модуль без изменений - это безопасный способ увидеть, как агент читает код. Выберите маленький баг или один тест. Сформулируйте acceptance criteria и запрещённые области. Разрешите только те действия, что нужны для этой задачи. Просмотрите diff, запустите узкие тесты, затем полный relevant suite. Сделайте commit своим осмысленным сообщением. Каждый шаг здесь выбран так, чтобы отвечать за одно звено цепочки и не смешиваться с соседними: чтение отдельно, правка отдельно, проверка отдельно.

Смысл этого масштаба - сделать каждое звено видимым. Ask без изменений показывает чтение отдельно от правки. Маленький баг даёт diff, который можно прочитать целиком. Узкие тесты до полного прогона локализуют эффект, прежде чем расширять проверку. Свой commit-месседж фиксирует, что закрыли задачу вы, а не автопилот. Маленькая задача - это не игрушка, а лаборатория, где видно каждый переход. Полный relevant suite в конце нужен не для галочки, а чтобы поймать эффект правки за пределами того файла, где она сделана, - узкий тест этого не увидит.

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