Вайбкодинг и AI

Brainstorming → план → код: как заставить AI-агента не торопиться

AI-агент по умолчанию бросается писать код и делает это быстро и мимо. Показываю workflow из трёх этапов, который я применяю на своих проектах, чтобы получать результат с первого раза.

Вячеслав Кочегаров6 сентября 2026 г.

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

Быстро. Мимо.

Проблема не в модели. Модель по умолчанию хочет угодить: ты сказал «админку» — она делает админку. Не спрашивает, что именно редактировать, не уточняет, кто пользователь, не проверяет ограничения платформы. Она просто начинает печатать.

Значит, тормозить должен ты. Ниже — порядок, по которому я работаю сам.

Три этапа вместо одного промпта

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

    обсуждение (вопросы по одному)
            │
            ▼
    дизайн-документ (что и почему)
            │
            ▼
    план (задачи, файлы, шаги)
            │
            ▼
    исполнение (агент за задачей, чистый контекст)

Ключевая мысль: код — последний этап, а не первый. Пока нет документа, который можно прочитать глазами и сказать «да, я хочу именно это», писать код рано.

Этап 1. Обсуждение: агент задаёт вопросы, а не пишет файлы

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

Так вылезает всё, что я «имел в виду», но не сказал.

Живой пример. Я делал на своей платформе LMS: курсы, уроки, доступ по оплате. Формулировка в голове была ровно одна — «личный кабинет с уроками». В обсуждении выяснилось:

доступ покупается к курсу целиком или к отдельным урокам?
что видит человек до оплаты — ничего, программу или первый урок?
что происходит, если оплата прошла, а вебхук от банка не дошёл?
кто и как выдаёт доступ руками, когда что-то пошло не так?

Ни один из этих вопросов не звучит в фразе «сделай личный кабинет». Но каждый меняет модель данных. Если бы агент начал с кода, я бы узнал про них на четвёртой переделке.

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

Этап 2. Дизайн-документ: что делаем и почему

Результат обсуждения — короткий документ. У меня он обычно на страницу-полторы и содержит:

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

Раздел «что мы НЕ делаем» экономит больше всего. Именно из него потом не вырастают три недели незапланированной работы.

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

Этап 3. План: задачи, файлы, шаги

Дальше дизайн превращается в план реализации. Не «сделай LMS», а список задач, где у каждой:

какие файлы трогаем (создаём/меняем);
какие шаги внутри задачи;
какой тест доказывает, что задача выполнена;
чем проверить — конкретная команда, а не «запусти тесты».

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

Проверка качества плана простая: прочитай задачу и попробуй понять, что делать, забыв весь предыдущий разговор. Не получилось — план недоделан.

Этап 4. Исполнение: одна задача — один чистый контекст

Дальше начинается код, и тут работает главное правило: одна задача — одна сессия.

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

Когда каждая задача едет отдельно, у агента в голове только план и текущий файл. Результат предсказуемый.

После каждой задачи — проверка. У меня это тесты бэкенда и проверка типов на фронте, и только потом следующая задача. Не «сделай пять задач, потом посмотрим».

Почему это окупается

Меня долго держало ощущение, что планирование — это потеря времени. «Пока я тут пишу документ, можно было уже накодить».

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

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

Частые ошибки

Слишком большой план. Если в задаче двадцать шагов — это не задача, это проект. Дели.
План без файлов. «Добавить авторизацию» — не задача. «Изменить deps.py, добавить зависимость, покрыть тестом» — задача.
Пропуск обсуждения на «простой» задаче. Простые задачи чаще всего и оказываются теми, где ты неправильно понял требование.
Проверка в конце. Ошибку, найденную через пять задач, чинить дороже в разы.
Обсуждение без фиксации. Если результат разговора не лёг в файл — его нет. В новой сессии он не воскреснет.

Мини-чеклист перед тем, как разрешить агенту писать код

Я могу назвать пользователя и его сценарий одной фразой?
Понятно, где хранятся данные и кто их меняет?
Записано, чего мы НЕ делаем?
Есть критерий, по которому задача считается сделанной?
Задача влезает в один заход, или её надо порезать?
Известно, чем я проверю результат?

Шесть «да» — можно начинать. Любое «нет» — возвращайся на этап выше, это дешевле.

Хочешь поставить себе такой процесс?

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

Именно эту систему я и передаю на курсе по вайбкодингу — один на один, на твоей реальной задаче, а не на учебном примере. Программа и запись — на странице курса. Если хочешь сначала спросить, подойдёт ли это под твой проект, пиши в Telegram.