AI Coding Workflow: Как сократить повторные правки кода от ИИ

Plan → Scoped Edit → Verify / Cursor Rules / малые diff / чеклист приёмки / диагностика циклов

При разработке функций в Cursor, Claude Code или Copilot Workspace знакома ли вам такая ночь: ИИ меняет файл A — тесты падают; вы чините B — A снова ломается; говорите «попробуй ещё раз» — и вчерашний рабочий код исчезает. Дело не в том, что модель «недостаточно умна» — не хватает повторяемого AI Coding Workflow, который разделяет планирование, объём изменений и приёмку. Без этой структуры Agent бесконечно крутится на одной и той же ошибочной гипотезе.

В статье — проверенный в 2026 году командный процесс: сначала Plan, потом точечные правки, и только после Verify — дальше. Вместе с Cursor Rules и малыми Git-коммитами мы сократили «чинить один и тот же баг 8 раз» до максимум 2 итераций. Если параллельно разворачиваете MCP Server на облачном Mac или выбираете open-source AI Agent проекты на GitHub — тот же workflow применим.

Почему ИИ попадает в бесконечный цикл правок?

Режим Agent по сути — пробовать и ошибаться в неопределённой среде. Если сказать только «почини баг логина», модель не знает, речь об OAuth-callback, истечении сессии или фронтенд-роутинге — она угадывает наиболее правдоподобный ответ, тестирует, терпит неудачу и пробует другой путь. Каждый раунд отменяет часть предыдущей гипотезы, diff растёт, контекст забивается противоречивыми правками — и вы в состоянии «чем больше патчим, тем хуже».

Три корневые причины

• Размытая цель — без описания «успех выглядит так» ИИ выводит из ошибок тестов назад; сообщения об ошибках часто указывают на симптом, а не на корень
• Разъехавшийся объём — задача на 10+ файлов, при правке auth заодно рефакторят utils, появляются новые регрессии
• Нет ворот приёмки — без жёсткого правила «продолжаем только при зелёном» реакция на провал — «сгенерировать ещё версию», а не «откатить и переопределить объём»

Эмпирическое правило: если три раунда подряд говорите «нет, ещё раз» — проблема не в модели, а в том, что задачу не перепланировали.

Трёхфазный workflow: Plan → Scoped Edit → Verify

Разделить каждую сессию с ИИ на три непропускаемые фазы часто эффективнее апгрейда модели:

1. Plan (планирование) — в режиме Plan или только в диалоге: список файлов, табу и команды приёмки (напр. npm test -- auth). Результат: «спецификация задачи» для вставки; не запускать Agent сразу, сначала подтвердить spec
2. Scoped Edit (ограниченные правки) — явно написать: «менять только src/auth/login.ts, остальные файлы табу». За раунд: 1–3 файла, <200 строк чистого изменения
3. Verify (приёмка) — тесты, lint, ручной smoke. Зелёный → commit и следующая задача; красный → с полным логом ошибки обратно к Plan, не «попробуй ещё»

Структура промпта: цель, границы и приёмка за один раз

Шаблон для копирования (скобки замените на свой проект):

## Цель
(Одно предложение: пользователь нажимает Вход и за 3 секунды попадает в dashboard)

## Объём
- Менять только: src/auth/login.ts, src/auth/session.ts
- Табу: роутинг, стили, другие модули

## Приёмка
- npm test -- --grep "login"
- Вручную: неверный пароль показывает «неверный логин или пароль», без раскрытия существования аккаунта

## Контекст
- Текущая ошибка: (вставить полный stack trace)
- Соглашения: сессия в Redis, см. docs/auth.md

Эта структура соответствует тому, что в лучших практиках Claude Code от Anthropic называют «чёткими границами» — модели не нужно угадывать, и поверхность регрессий остаётся под контролем.

Rules / Skills: записать ограничения проекта в репозиторий

Повторять в каждом чате «мы на pnpm, без class components, тесты в __tests__» тратит токены и даёт непоследовательное поведение. Запишите соглашения в .cursor/rules или проектный AGENTS.md:

Rules (правила)

Постоянные ограничения: стиль имён, запрещённые паттерны, обязательные команды перед commit. Cursor внедряет их при каждом вызове Agent.

Skills (навыки)

Переиспользуемые сценарии, напр. чеклист «добавить новый API endpoint». Меньше заново изучать структуру проекта на каждой задаче.

User Rules vs Project Rules

Личные предпочтения (напр. «отвечать по-русски») — в User Rules; командный консенсус (напр. «backend не трогать без запроса») — в Project Rules, важно для совместной работы.

См. документацию Cursor Skills: когда частые процессы зафиксированы, число повторных ошибок одного типа заметно падает.

Малые diff и дисциплина Git

ИИ хорошо генерирует большие блоки кода — люди плохо ревьюят большие diff. Рекомендации:

• Одна задача Agent = один commit — message с кратким Plan, чтобы git revert был простым
• При хаосе — reset — не патчить дальше огромный diff; git checkout -- . к последней зелёной точке, затем меньший объём
• Ветки для экспериментов — особенно на облачном Mac или в CI: git worktree или отдельная ветка изолирует «дикие правки» ИИ

Управление контекстом: не утопить Agent в море файлов

Отдать весь monorepo Agent — искать сигнал в шуме. Эффективнее:

1. Точно ссылаться на 3–5 файлов через @filename, а не «сканировать весь проект»
2. Крупные рефакторинги делить на несколько Plan: сначала интерфейс, потом реализация, потом тесты — Verify на каждом шаге
3. После 15+ раундов: новый чат с «spec + текущее состояние» чище, чем тащить историю

Четыре типичных цикла и способы выхода

Если оркестрируете сложные Agent-пайплайны (пакетная обработка документов или цепочки MCP-инструментов), схема «маршрутизация → выполнение → проверка» совпадает с архитектурой маршрутизации в нашей статье о пакетном распознавании PDF: сначала решить, потом действовать — не гнать каждую задачу по самому медленному и хрупкому пути.

Частые вопросы

1. Помогает ли более сильная модель? — Сильнее модели уменьшают синтаксические ошибки, но проблемы контроля объёма и регрессии слабо зависят от tier модели; решает workflow
2. Как унифицировать в команде? — Rules, шаблоны PR и чеклисты приёмки в репозиторий; на code review проверять «малые коммиты?»
3. Можно ли всё отдать Agent? — Выполнение да, но Plan и Verify лучше оставить человеческими воротами — особенно для платежей, auth и миграций
4. Как сочетается с TDD? — Сначала падающий тест (Plan), потом реализация (Scoped Edit), зелёный — refactor; естественно ложится на три фазы

Итог: сократить повторные правки кода от ИИ получается не «ещё одной попыткой», а дисциплиной Plan → Scoped Edit → Verify, чёткими промптами, Rules в репозитории и смелостью делать git revert. Когда процесс устоялся, время уходит на формулировку проблемы — а не на N-й патч.