Разделяй планирование и исполнение: AI-воркфлоу, который реально работает
Знаете, что самое обидное в AI-кодинге? Не то, что модель иногда пишет ерунду. А то, что она пишет ерунду старательно и убедительно. Код компилируется, тесты зелёные, а потом оказывается — решена не та задача. Или решена правильно, но не так, как нужно вашему проекту.
Мэттью Хоу (Matthew Hou) написал отличную статью, пусть ничего революционного в ней и нет. Он сформулировал то, что многие чувствуют, но не могут выразить: проблема не в модели, а в том, что вы просите её делать два дела одновременно.
Почему большинство AI-воркфлоу не работают
Большинство разработчиков используют AI как шар предсказаний. Написал расплывчатый промпт — получил расплывчатый результат — потом двадцать минут всё исправляешь. Знакомо, правда?
Проблема в том, что вы просите модель одновременно:
- Понять, что нужно сделать (планирование)
- Написать код (исполнение)
Это два совершенно разных типа мышления. Когда вы их смешиваете, получается код, который структурно нормальный, но решает не ту задачу. Или решает ту, но криво вписывается в архитектуру.
Как должно быть: сперва план, потом код
Мэттью предлагает до безобразия простой подход. Прежде чем трогать код, вы пишете спецификацию на обычном английском (или русском — не важно). Не промпт, а именно спек:
«Добавь rate limiting на эндпоинт /api/search. Используй sliding window counter в Redis. Лимит: 100 запросов в минуту на API key. При превышении — возвращай 429 с заголовком Retry-After. Сделай middleware, чтобы другие эндпоинты могли использовать тот же паттерн.»
Никакого кода. Никаких деталей реализации. Просто чёткое описание желаемого результата.
Потом вы скармливаете это AI с припиской: «Разбей на подзадачи. Код не пиши». Модель выдаёт список задач. Вы просматриваете, корректируете приоритеты, убираете галлюцинации, добавляете то, что она пропустила. Это занимает минуты две-три.
И только потом — передаёте каждую подзадачу AI по одной.
Почему это работает
Три причины — и каждая сама по себе стоит того, чтобы попробовать.
Вы ловите плохие предположения на ранней стадии. Если в плане AI значится «создавать новое подключение к Redis на каждый запрос» — вы это увидите ещё до того, как появится хотя бы строчка кода. Исправить план дешевле, чем переписывать код.
Вы сохраняете контроль над архитектурой. AI пишет код в рамках, которые вы задали, а не то, что ему кажется умным. Кодовая база остаётся консистентной. Не будет сюрпризов в стиле «а AI решил переписать половину проекта на GraphQL, потому что так красивее».
Качество кода заметно растёт. Маленькие, чётко ограниченные задачи дают лучше результат, чем «сделай мне фичу». Это тот же принцип, по которому мы разбиваем работу на тикеты для людей. Почему-то с AI многие об этом забывают.
Воркфлоу шаг за шагом
Типичная сессия выглядит так:
- Вы пишете спецификацию — 2-5 предложений, описывающих конечный результат
- AI создаёт план — упорядоченный список подзадач с путями к файлам
- Вы просматриваете и корректируете — обычно пара минут, иногда ловите серьёзные проблемы
- AI выполняет каждую подзадачу — вы проверяете результат перед переходом к следующей
- Вы занимаетесь интеграцией — соединяете куски, запускаете тесты, проверяете поведение
Шаги 1 и 3 — ваша главная ценность. Шаги 2 и 4 — где AI помогает больше всего. Шаг 5 — совместный.
И главное: этот подход работает с любым AI-инструментом. Claude Code, Cursor, GitHub Copilot, даже ChatGPT с копипастом — принцип универсальный.
Неуклюжая правда о скорости
Этот подход медленнее, чем «просто попросить AI сделать всё». По ощущениям. Но когда Мэттью засёк реальное время за месяц, подход «планирование сначала» оказался примерно на 40% быстрее от начала до конца. Просто потому что ему почти никогда не приходилось выбрасывать большие куски AI-кода и начинать заново.
Главный пожиратель времени в AI-кодинге — не генерация, а переделка. Планирование убирает大部分переделок.
Чему AI не может заменить
Не всё вписывается в этот воркфлоу:
- Расследование багов — стектрейсы всё равно читать самому. AI отлично предлагает фиксы, но ужасно понимает, почему что-то сломалось именно в вашем окружении.
- Архитектурные решения — AI может предложить варианты, но решение за вами. Он не знает приоритетов команды и продуктовой дорожки.
- Код-ревью — каждую строку AI-кода нужно проверять. Не потому что вы ему не доверяете, а потому что вам нужно понимать этот код — когда он сломается в три часа ночи.
Что попробовать уже завтра
Если вы сейчас используете AI как генератор кода — попробуйте одно простое изменение. Перед следующей фичей напишите 3 предложения о том, что хотите получить. Попросите AI составить план. Просмотрите план. И только потом начинайте кодить.
Результат вас удивит.