Как ставить задачу ИИ, чтобы получался рабочий код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное правило: одна задача — одна сессия.

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

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

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

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

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

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

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

Практическое задание

1. Возьмите задачу из второго урока и проведите обсуждение с агентом в режиме «вопросы по одному». Остановитесь, когда узнаете о своей задаче что-то новое, — а вы узнаете.
2. Сложите ответы в дизайн-документ на одну страницу: цель, архитектура, данные, границы, критерии приёмки.
3. Прогоните чек-лист перед тем, как разрешать писать код:
   • могу назвать пользователя и его сценарий одной фразой;
   • понятно, где хранятся данные и кто их меняет;
   • записано, чего мы НЕ делаем;
   • есть критерий, по которому задача считается сделанной;
   • задача влезает в один заход;
   • известно, чем я проверю результат.

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