Как выполнять упражнения с ИИ-агентом в курсе

Когда вы и агент знаете, что происходит на каждом шаге, исчезает главный источник хаоса: неясность, что вообще считается «сделано».

1. Повторяемость — один и тот же цикл срабатывает для любой задачи, от мелкой правки до новой фичи.
2. Проверяемость — результат каждого шага виден в diff и в тестах, а не в словах агента.
3. Откатываемость — коммит после каждого шага даёт точку возврата на случай ошибки.
4. Обучаемость — разобравшись с форматом один раз, вы перестаёте думать о процессе и думаете о задаче.

Курс построен так, что каждый урок — это маленькое упражнение с чётким результатом. Если вы научитесь доводить такое упражнение до конца, вы научитесь доводить до конца реальные задачи в рабочих проектах — механика одинаковая.

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

Условие

Короткое описание того, что нужно сделать. Это не техническое задание на десять страниц, а одно-два предложения, задающие направление. Если условие кажется размытым — это повод задать агенту уточняющие вопросы, а не начинать работу. Подробнее о том, как вытаскивать требования, — в уроках про цикл Grill-Execute-Clear.

Шаги

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

Критерий приёмки

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

Коммит

Фиксация результата в git. Коммит закрывает цикл: работа сделана, проверена и сохранена. Подробно про команды git мы говорили в уроке про настройку проекта, здесь же важно правило — один завершённый шаг, один коммит.

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

Зачем так? Когда вы знаете, куда идёте, каждый шаг читается осмысленно: вы понимаете, какая часть текста вам нужна прямо сейчас, а какая — справочная. Это же правило работает с агентом: сначала покажите ему цель, потом давайте материал. Агент, как и человек, работает лучше, когда видит конечную точку.

1. Контекст — что за проект, какие файлы уже есть, что вы уже пробовали.
2. Задача — что конкретно нужно сделать, какими инструментами.
3. Критерий приёмки — как вы поймёте, что задача выполнена.

Пример слабого запроса:

Добавь функцию валидации.

Пример сильного запроса:

В проекте есть файл src/validate.js с пустой функцией validateEmail.
Добавь в неё проверку формата email по регулярному выражению.
Критерий приёмки: функция возвращает true для a@b.ru
и false для строки "не-email". Тест в tests/validate.test.js должен проходить.

Обратите внимание на разницу: во втором случае агент не гадает, где находится функция и что считается корректным результатом. Чем меньше агент вынужден додумывать, тем меньше шансов на неверную реализацию. Уточнения, которые вы вложили в запрос, экономят цикл правок в конце.

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

1. Дать агенту один шаг с критерием приёмки.
2. Дождаться завершения и посмотреть diff.
3. Проверить критерий приёмки: тесты, вывод, глазами.
4. Закоммитить результат.
5. Перейти к следующему шагу.

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

Визуально это выглядит как короткий диалог: вы даёте шаг, агент делает и показывает diff, вы проверяете и либо принимаете, либо отправляете на доработку. Никакой магии — просто дисциплина коротких циклов.

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

Проверка глазами

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

Проверка тестами

Если в упражнении есть тесты, запустите их. Тест — самый честный проверяющий: он не устал, не торопится и не хочет угодить. Команда запуска обычно записана в package.json в блоке scripts.

npm test

Проходящий тест — сильный аргумент в пользу того, что шаг выполнен. Но помните: тест проверяет ровно то, что в нём написано. Хороший тест нужно уметь читать, и этому посвящены отдельные уроки про обратные связи и TDD.

Проверка критерием приёмки

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

Коммит — это не бюрократия, а точка принятия решения. Выполненный шаг, который не закоммичен, — это невыполненный шаг: изменения живут в рабочей копии и могут быть случайно потеряны или перемешаны со следующей задачей. Коммит фиксирует границу: «вот здесь шаг завершён, дальше новое состояние».

git add .
git commit -m "Шаг 1: добавлена валидация email"

Пишите в сообщении, какой шаг закрыт, а не что «всякое по мелочи». Когда через неделю вы или агент откроете git log, по сообщениям должно быть понятно, в каком порядке шла работа и где искать нужное изменение. Это бесплатная документация, которую вы пишете автоматически каждым коммитом.

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

Закрепление формата на примере

Возьмите учебный проект и выполните простое упражнение целиком — от условия до коммита. Упражнение: добавить функцию, которая считает сумму чисел массива.

1. Сформулируйте критерий приёмки: функция возвращает 6 для массива [1, 2, 3] и 0 для пустого массива.
2. Дайте агенту шаг с контекстом: файл src/main.js, добавить функцию sum и экспортировать её.
3. Проверьте diff и запустите проверку: напишите тест или проверьте вызов вручную.
4. Сопоставьте результат с критерием приёмки.
5. Закоммитьте шаг с осмысленным сообщением.

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

1. Чтение урока целиком без выполнения, а потом «всё сразу» одним промптом.
2. Отсутствие критерия приёмки — проверять нечем, «вроде работает».
3. Запрос агенту без контекста и без указания, что считается готовым.
4. Пропуск проверки diff и запуск следующего шага «на веру».
5. Проверка только словами агента вместо тестов и критерия.
6. Коммит всего упражнения одним коммитом без промежуточных точек возврата.

Единый формат упражнений — это простой цикл: условие, шаги, критерий приёмки, коммит. Запрос агенту содержит контекст, задачу и критерий; результат проверяется глазами, тестами и по критерию; каждый проверенный шаг фиксируется коммитом. Освоив этот цикл, вы готовы к практическим урокам курса.

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

1. Упражнение — единица курса с условием, шагами и критерием приёмки.
2. Условие — краткое описание того, что нужно сделать.
3. Шаг — одно действие с проверяемым промежуточным результатом.
4. Критерий приёмки — условие, по которому задача считается выполненной.
5. Запрос (промпт) — сообщение пользователя агенту.
6. Контекст — информация о проекте, которую агент учитывает при работе.
7. Diff — разница между версиями файлов, показывающая изменения.
8. Тест — автоматическая проверка, что код работает ожидаемо.
9. npm test — команда запуска тестов, объявленная в скриптах проекта.
10. Рабочая копия — текущее состояние файлов на диске.
11. Коммит — зафиксированная точка в истории изменений git.
12. git log — команда, показывающая историю коммитов.
13. Откат — возврат к предыдущему состоянию проекта.
14. TDD — разработка через тесты: сначала тест, потом код.
15. Vibe coding — неструктурированная работа с агентом без плана и проверок.