Рабочий процесс AI-кодинга: от задачи к проверке

На разборе ко мне часто приходят с одной фразой: «я уже пробовал cursor agent, но каждый раз как лотерея». Открыли чат, написали «сделай форму», получили diff на восемь файлов, нажали Accept - через день проект не собирается. На следующей неделе тот же сценарий с другим промптом. Модель тут ни при чём. Вы спросили агента и получили правки, но не прошли цикл с проверкой.

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

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

У меня в работе был типичный кейс: самозанятый собрал лендинг за вечер в Agent, не закоммитил промежуточные шаги. Через неделю попросил «добавить оплату» - агент переписал половину стилей, потому что в чате не осталось ни плана, ни критерия «не трогать layout». Мы не спорили про модель. Мы разложили его вечер на шесть этапов и записали, что на каждом считается готово. Со второй итерации diff стал предсказуемым. Мне это нравится больше, чем ловить «почему вчера работало».

Рабочий процесс AI-кодинга, который я использую сам и даю на наставничестве, укладывается в шесть этапов. Каждый этап заканчивается артефактом: короткой записью, файлом, diff или выводом команды. Без артефакта этап не закрыт, даже если агент написал «готово». Я к этой фразе отношусь спокойно и не верю ей на слово.

1. 01

   Контекст - понять, где в проекте живёт задача (Ask, Rules, @-файлы).

2. 02

   План - согласовать шаги до правок (Plan mode или явный план в чате).

3. 03

   Малое изменение - один инкремент в Agent, без «сделай всё приложение».

4. 04

   Diff - просмотр изменений до принятия; reject лишних hunks.

5. 05

   Тесты - lint, typecheck, unit или ручной сценарий с записью результата.

6. 06

   Документирование - README, комментарий, commit message: что и зачем.

Режимы Cursor привязаны к этапам. Они не подменяют этапы сами по себе. Agent правит файлы и запускает shell. Ask читает код без правок - удобен для карты перед планом. Plan строит план как виртуальный файл, вы approve → Build. Debug нужен, когда есть runtime evidence (лог, стек). Переключение: Shift+Tab или dropdown в чате. Официальная рекомендация Cursor - новый чат при смене задачи, потому что контекст режимов разделён. Я так и делаю: новая задача - новый чат, иначе вчерашний «почини кнопку» всплывает в сегодняшней оплате.

Checkpoints в Agent сохраняют локальный снимок файлов до шага; Restore Checkpoint откатывает к нему. Это страховка внутри сессии, не замена Git: merge в основную ветку только после вашего ревью и тестов. Подробнее про возможности агента - в статье Cursor Agent mode; здесь фокус на склейке этапов, а не на справочнике кнопок.

Что считается готовым артефактом

Первый этап цикла - не Agent с «сделай фичу», а сбор контекста. Я открываю Ask и задаю вопросы уровня «где обрабатывается X», «какие модули трогает Y», «есть ли уже тест на Z». Ask не меняет файлы. Пока карта не ясна, правки рано запускать - иначе агент начнёт писать в соседний модуль, потому что так удобнее ему, а не вам.

Постоянный контекст проекта живёт вне чата: Project Rules в .cursor/rules/*.mdc, корневой AGENTS.md, User/Team rules. Их имеет смысл держать в git вместе с кодом. В rules я фиксирую то, что не хочу повторять каждый раз: стек, запрет на новые зависимости без согласования, команды проверки, стиль коммитов. Подробный разбор - в гайде по cursor rules.

Для разовой задачи добавляю @-файлы и короткий brief. Шаблон 00-brief.md экономит время, когда возвращаетесь к проекту через неделю:

# Brief: добавить поле «телефон» в форму заявки

Цель: клиент оставляет телефон; поле уходит в webhook CRM.

Файлы:
- src/components/LeadForm.tsx
- src/api/submitLead.ts

Ограничения: не менять стили hero; не добавлять npm-пакеты.

Критерий готовности: npm run lint && npm test -- LeadForm;
ручная проверка: отправка тестовой заявки, 200 от API.

Формулировку задачи для агента разбираю отдельно в промптах для Cursor. Здесь другое: контекст - отдельный этап с записью. Его нельзя склеивать с тем же сообщением, где вы уже просите переписать модуль. Я так ошибался сам: одно длинное «и ещё поправь стили, раз уж открыл» - и план разъехался.

Пример rule для процесса, который я кладу в .cursor/rules/process.mdc:

---
description: Малый шаг и проверка на каждой итерации Agent
alwaysApply: true
---

# Процесс AI-кодинга

- Одна задача на чат: цель + файлы + критерий готовности.
- Правки - один логический шаг; если diff затрагивает >5 файлов без согласования - остановись и предложи план.
- После правок запусти команды из package.json: lint, test. Вставь exit code в ответ.
- Секреты и .env не коммитить; ключи только через переменные окружения.

Когда контекст собран, переключаюсь в Plan или Agent с явной отсылкой к brief. Прыжок сразу в Agent без карты - самая частая причина фразы «агент забыл, что мы делали вчера». Забыл не агент. Забыли вы: контекст остался в закрытом чате.

План для меня - способ урезать откаты, а не бумажка «для галочки». В Cursor для задач на несколько файлов или спорной архитектуры я включаю Plan mode: агент пишет план как виртуальный файл, я правлю, жму Build. Если план поехал не туда - Revert на сообщении, уточняю, снова Build. Save to workspace сохраняет план в репозиторий; на разработке проектов это часто становится мини-ТЗ для заказчика. Заказчику проще спорить с планом, чем с уже размазанным diff.

Критерий малого изменения, который я озвучиваю агенту и себе:

• Один понятный результат: «добавить поле», «починить тест X», «вынести функцию в модуль».
• Diff можно просмотреть за 5-10 минут без «пролистывания наугад».
• Есть одна команда или ручной сценарий, который доказывает готовность.
• Если затронуты тесты, CI или lint config - это отдельное согласование, не «попутно».

Когда остановить агента и вернуться к плану:

• Diff разросся на файлы, которых не было в brief.
• Агент предлагает новую библиотеку или меняет публичный API без запроса.
• Вы не можете объяснить своими словами, что делает каждая правка.
• Тесты «зелёные», но вы не понимаете, что именно они проверяют.

На разборе я прошу ученика перед каждым Agent-сообщением писать одну строку: «После этого шага я увижу …». Если строка расплывчата («станет лучше»), план ещё не готов. Agent mode хорош, когда шаг уже согласован. Иначе вы платите временем на откат checkpoint и нервы. Мне этот откат знаком: сидишь, смотришь на 14 файлов и думаешь, с какого hunk начать.

Diff в Cursor виден по ходу работы агента; нежелательные hunks можно reject до merge в git. Я не принимаю diff только потому, что агент уверенно объяснил. Уверенный тон в чате и просмотренный diff - разные вещи. Порядок ревью, который держу в голове:

1. 01

   Scope (2 мин): каждый файл относится к текущему шагу? Лишнее - reject или отдельный PR позже.

2. 02

   Harness diff (3 мин): изменения в tests/, CI, coverage, lint config - красный флаг до объяснения.

3. 03

   Импорты и зависимости: новые пакеты существуют, версии осмысленны, нет секретов в коде.

4. 04

   Cross-file: grep по удалённым символам - не сломали ли вызовы в других модулях.

5. 05

   Critical path (5 мин): один сценарий «вход → побочный эффект» (auth, деньги, запись в CRM, удаление данных).

Чек-лист перед Accept в IDE:

• Количество файлов совпадает с планом или есть явная причина расширения
• Нет ключей API, паролей, .env в diff
• Нет skip / only в тестах без вашего запроса
• Я могу пересказать каждую правку коллеге за 30 секунд

Restore Checkpoint откатывает файлы к снимку до сообщения - используйте до git commit, если diff ушёл в сторону. После commit откат - через git, не через checkpoint. Углублённый разбор проверки кода от ИИ - в гайде по Cursor AI; здесь акцент на том, что diff - обязательный gate цикла. Если его пропускать, цикл превращается в «нажал Accept и пошёл пить чай».

Тесты в цикле AI-кодинга ловят silent logic: код запускается, но делает не то. Красивый зелёный экран меня не греет, если я не видел команду. Я прошу агента запускать команды в терминале и показывать exit code, а не писать «тесты прошли» без вывода.

Типовой блок для Node/TypeScript проекта:

npm run lint
# ожидаю exit 0

npm run test -- --runInBand src/components/LeadForm.test.tsx
# ожидаю exit 0; при падении - полный stderr в ответ

Для Python:

ruff check src/
pytest -q tests/test_lead_form.py
# exit 0; при fail - traceback, не переписывать тест «чтобы зелёный»

Минимум для пилота без автотестов: ручной сценарий из 2-3 шагов с записью «ожидал / получил». Честно пишите в brief, что автотестов нет - иначе агент может нагенерировать тесты, которые не ловят неверное поведение (happy path only). Такие тесты успокаивают, а баг всё равно уезжает в прод.

Красные флаги на этапе тестов:

• Агент ослабил порог coverage или добавил continue-on-error в CI без обсуждения.
• Тест проверяет только «функция вызвана», а не результат.
• Lint отключён «временно» в изменённом файле.

Я закрываю этап, когда есть артефакт: скрин терминала, лог в комментарии к commit или CI run. Без артефакта этап «тесты» не выполнен, даже если вам «вроде работает». «Вроде» - это не критерий. Критерий - команда и то, что вы видели глазами.

Шестой этап часто пропускают: закрыли вкладку, через неделю новый чат, агент снова предлагает тот же рефактор. Документирование - мост между циклами. Минимум, который я делаю сам:

• Commit message: что изменилось, зачем, как проверить (fix: поле phone в LeadForm, npm test LeadForm).
• Строка в README или CHANGELOG для заметных поведенческих изменений.
• Обновление rule или AGENTS.md, если появилось новое постоянное ограничение.

Если работаете один, хватит 00-brief.md с секцией «Сделано» и ссылкой на commit. Если команда - короткий handoff в issue или PR description: контекст, решение, риски, как откатить.

Документирование не обязано быть романом. Достаточно, чтобы человек без доступа к чату Cursor воспроизвёл проверку за пять минут. Это же критерий готовности артефакта на этапе 6. Я так проверяю себя: если через неделю я сам не вспомню, как гонять сценарий - запись была слишком короткой.

Ниже сводная таблица - главный проверяемый артефакт статьи. Можно скопировать в Notion или положить в репозиторий как PROCESS.md.

Версия для одной задачи в Agent mode (короткий маршрут):

1. 01

   Новый чат → вставить brief → подтвердить один шаг.

2. 02

   Agent → правки → diff review → checkpoint при сомнении.

3. 03

   npm run lint + целевой test → зафиксировать вывод.

4. 04

   Commit → обновить brief «Сделано».

Ночной cron или автоматизация вроде RSS-триггера на один шаг (например, «прогнать lint и открыть draft PR») - это один шаг цикла. Это не автопилот «сайт соберётся сам». Расписание не отменяет утреннее ревью diff человеком. Я бы не оставлял merge на cron без глаз.

Процесс не бесконечный DIY. Признаки, что пора подключить человека:

• Три и более цикла подряд на одной задаче без закрытия критерия готовности.
• Вы не можете объяснить diff, но боитесь откатить - «вдруг сломается».
• Задача упирается в прод, деньги, персональные данные, а тестовой среды нет.
• Нужен не процесс, а исполнитель: срок, фиксированный scope, сдача «под ключ».

Наставничество - когда хотите встроить цикл на вашем репозитории или боте: разбор этапов, rules, критериев проверки, без обещаний дохода и «станете разработчиком за N дней». Разработка проектов - когда нужен исполнитель пилота, а не ещё один вечер с промптами.

Я не продаю «cursor agent вместо команды». Я продаю повторяемость: вы знаете, на каком шаге застряли, и что должно лежать в артефакте. Если после двух-трёх итераций цикл не складывается - это сигнал на созвон. Удлинять промпт в такой момент обычно бесполезно: вы уже крутите одно и то же колесо.

Если узнали себя в двух и более строках - новый плагин не спасёт. Вернитесь к этапу 1 или 2 и запишите артефакт, которого не хватает. На разборе я часто вижу: человек силён в Agent, слаб в тестах и документировании. Чинится это закрытым этапом 5-6, а не «лучшим промптом». Промпт без артефакта я уже видел слишком много раз.

Что читать дальше

• Промпты для Cursor - этап контекста и формулировка.
• Как пользоваться Cursor AI - этапы diff и тестов углублённо.
• Cursor Agent mode - режимы и безопасность, без дублирования цикла.