Planning mode перед генерацией кода: шаблон планирования

Зачем нужен planning mode и какие проблемы он решает

ИИ часто генерирует "не то", потому что заполняет пробелы за вас. Если цель описана размыто, ограничения не названы, а данные и роли пользователей не уточнены, модель додумывает детали сама. В итоге вы получаете рабочий код, но для другой задачи.

Planning mode нужен, чтобы сначала договориться о смысле, а уже потом о реализации. Это не "ТЗ на 20 страниц". Скорее короткий разговор по делу: что должно получиться, что нельзя делать, на каких данных работаем, где риски и как поймем, что готово.

Больше всего времени обычно съедают переделки, которые можно увидеть заранее: границы модуля и API, формат и качество данных, роли и права, особенности интеграций (ошибки, таймауты, лимиты), а также критерии готовности.

Planning mode особенно полезен, когда вы делаете новый модуль, трогаете оплату, авторизацию, отчеты, импорт данных или подключаете внешние сервисы. Там одна неуточненная деталь легко превращается в переписывание половины решения.

Пример: вы просите "сделай админку для заявок". Без планирования ИИ может сделать таблицу и форму. А потом выясняется, что нужны статусы, история изменений, разные права для менеджера и оператора, уведомления и выгрузка. Если проговорить это в planning mode, результат будет ближе к реальной работе с первой попытки.

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

Сначала цель: формулируем результат без лишних слов

Четкая цель резко снижает шанс получить "почти то, но не то". Важно описывать конечный результат, а не процесс разработки.

Сформулируйте результат в одном предложении: что именно появится в продукте (функция, экран, API-метод, фоновый сервис). Затем уточните, для кого вы это делаете: не "для пользователей", а для конкретной группы и конкретного сценария. Обычно достаточно 1-2 ключевых сценариев, иначе ИИ начнет распыляться.

Полезно разделить успех на две части:

• для пользователя: стало ли проще, быстрее, понятнее;
• для бизнеса: что улучшится (меньше обращений в поддержку, выше конверсия, меньше ручной работы).

Чтобы цель была проверяемой, добавьте 3-5 признаков "сделано": пользователь проходит сценарий за N шагов, ошибки показаны понятным текстом, данные сохраняются после перезагрузки, есть базовая проверка некорректного ввода, время ответа укладывается в X секунд на типичном запросе.

Пример: вместо "сделай экран профиля" лучше "экран профиля, где пользователь меняет имя и аватар, видит понятную ошибку при неверном формате, и изменения сохраняются после повторного входа".

Ограничения: что нельзя и что точно нужно учесть

Хороший planning mode начинается с ограничений. Это способ заранее отсечь решения, которые красиво выглядят в коде, но не подходят вам по стеку, срокам, данным или безопасности.

Сначала зафиксируйте платформы и технологии. Один и тот же функционал по-разному делается для веба, бэкенда и мобильного. Если вы заранее знаете, что фронтенд на React, бэкенд на Go, база PostgreSQL, а мобильное приложение на Flutter, ИИ не будет предлагать лишние библиотеки и подходы, которые потом придется вычищать. В TakProsto это особенно важно, потому что генерация и экспорт кода завязаны на выбранный стек.

Дальше обозначьте ограничения по времени, бюджету и людям. Частая причина переделок - план написан "как в идеальном мире", а делать его придется одному человеку за два вечера. Прямо укажите, сколько дней есть, какой уровень у команды и что точно нельзя усложнять.

Отдельный блок - ограничения по данным. Уточните, есть ли доступ, в каком формате данные приходят (JSON, CSV, таблица), насколько они чистые, можно ли рассчитывать на стабильные поля. Если доступ появится "позже", это риск, и его лучше сразу превратить в план Б.

И наконец, безопасность и хранение. Зафиксируйте требования: где хранятся данные, какие поля нельзя логировать, нужна ли маскировка, кто имеет доступ. Если есть требование локального хранения, явно укажите это заранее. Например, TakProsto работает на серверах в России и использует локализованные модели, что удобно для проектов, где важно не выводить данные за пределы страны.

Чтобы ИИ не гадал, удобно собрать ограничения в короткий список:

• целевые платформы и обязательный стек;
• дедлайн и допустимый объем работ (MVP или "сразу идеально");
• данные: доступ, формат, качество, частота обновления;
• безопасность: хранение, логи, права доступа, запреты.

Данные и интеграции: уточняем до кода

Чаще всего ломается не логика, а данные. Если заранее не договориться, какие сущности существуют и откуда они берутся, ИИ быстро нагенерирует красивую структуру, которую потом придется подгонять под реальность.

Начните с карты входных данных на уровне здравого смысла: какие сущности точно есть (пользователь, заказ, платеж, файл, комментарий). Для каждой сущности достаточно понять: кто создает, кто читает, как удаляется (если вообще), какие есть статусы.

Дальше уточните источники и интеграции. Важно прописать не только "откуда", но и "как обновляем": по кнопке, по расписанию, по вебхуку, при каждом открытии экрана. И обязательно решите, что считается источником правды, если данные расходятся.

Полезный минимум схемы для первой версии:

• основные поля (5-10), типы и обязательность;
• статусы (3-6) и переходы;
• связи (1:N или M:N) и где хранится связь;
• идентификаторы (uuid или числовой id), требования к уникальности;
• обработка "грязных" данных (пустые поля, дубликаты, неверный формат).

Пример: "заказ" без деталей не работает. Нужны хотя бы id, user_id, сумма, валюта, статус (новый, оплачен, отменен), created_at. По платежам важно решить заранее: подтверждение приходит вебхуком или вы опрашиваете провайдера сами. От этого зависит модель статусов и обработка повторных событий.

И обязательно отметьте, что откладываете: историю изменений, сложные роли, редкие поля, импорт из старой системы, расширенную аналитику. Это помогает не пытаться "сразу сделать идеально".

Риски: где чаще всего ломается план и как подстелить соломку

Planning mode ломается не из-за ИИ, а из-за туманных вводных. Чем раньше вы поймаете риск, тем меньше будет спорных правок.

Частые точки поломки:

• неполные требования: "сделай удобно" без примеров экранов, статусов и правил;
• сложная интеграция: внешнее API ведет себя иначе, чем в документации, или есть лимиты;
• права доступа: непонятно, кто что видит и меняет;
• данные: нет тестовых данных, неизвестны форматы, не оговорены обязательные поля.

Риск обычно видно по словам "примерно", "как обычно", "потом уточним". В этот момент стоит остановиться и задать три вопроса: какие входы и выходы (с примерами), что считается ошибкой, и кто принимает результат.

Простой план подстраховки:

• маленький прототип: один экран или один эндпоинт без красоты;
• проверка интеграции: один реальный запрос к API и разбор ответов;
• тестовые данные: 10-20 строк с крайними случаями;
• матрица прав: "роль -> действия -> ограничения".

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

Как ставить задачу ИИ перед генерацией кода

Если вы хотите меньше переделок, не просите ИИ сразу писать код. Сначала договоритесь о плане: что делаем, что не делаем, какие данные нужны и как проверить результат.

Сформулируйте, чего вы ждете от ИИ именно сейчас. Обычно есть три режима: (1) задать уточняющие вопросы, (2) предложить план и разбиение на задачи, (3) набросать каркас без деталей. Код появляется только после того, как вы подтвердили первые два пункта.

Попросите артефакты, которые удобно обсуждать:

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

Заранее задайте формат ответа. ИИ часто "растекается" текстом, если не попросить форму. Работают простые рамки: нумерованные шаги для плана, чеклист для критериев, таблица для сущностей и полей.

Хорошее правило: сначала вопросы и план, потом код. Прямо так и напишите.

Сначала задай уточняющие вопросы (до 7). Затем предложи план в 8-12 шагов.
Отдельно: структура файлов, схема данных (таблица), критерии готовности (чеклист).
Код не генерируй, пока я не отвечу и не подтвержу план.

Такой запрос дисциплинирует диалог: вы видите пробелы в требованиях до того, как они превратятся в лишние коммиты и переписанные модули.

Пошаговый шаблон planning mode (можно копировать)

Planning mode обычно занимает 10-20 минут, но часто экономит часы переделок. Идея простая: сначала фиксируем смысл и границы, потом просим ИИ писать код.

Последовательность из 5 шагов:

1. Соберите вводные и выпишите неизвестные. Отдельно - вопросы, без ответа на которые код будет угадайкой.
2. Сформулируйте цель и границы первой версии (MVP). Одно предложение: что пользователь получит. Затем 2-3 пункта, что точно не делаем в первой версии.
3. Опишите данные и ключевые экраны или API. Какие сущности есть, какие поля обязательны, где храним, какие операции нужны.
4. Составьте последовательность работ и проверьте зависимости. Что нужно сделать раньше, где возможны блокеры (доступы, миграции, тестовые данные).
5. Согласуйте критерии готовности. Только после этого просите код.

Шаблон, который удобно копировать в чат:

ЗАДАЧА:
Контекст:
Цель (1 фраза):
MVP (что входит):
Не делаем в MVP:

Неизвестные вопросы (ответьте перед кодом):

Данные:
- Сущности и поля:
- Источник данных / хранилище:

Экраны или API:
- Экраны (если UI):
- Эндпоинты (если API):

План работ (по шагам):

Риски и как проверим:

Критерии готовности (чек):

Пример короткого критерия: "Пользователь может создать запись, увидеть ее в списке, удалить, и после перезагрузки страницы все сохраняется". Это сразу задает проверяемый результат.

Критерии готовности: как понять, что можно остановиться

Planning mode полезен только тогда, когда у плана есть четкая точка остановки. Иначе вы будете бесконечно уточнять детали, а потом все равно получите переделки - просто позже.

Смысл критериев готовности - заранее договориться, что именно считается результатом и как вы это проверяете.

Что должно быть готово

Хороший набор критериев покрывает три слоя: пользовательские сценарии, поведение в ошибках и способ проверки.

Минимальный ориентир:

• 3-7 конкретных пользовательских сценариев (что делает и что видит);
• роли и права: кто может создавать, редактировать, удалять, смотреть;
• обработка ошибок: что показываем пользователю, что пишем в логи;
• границы данных: форматы, обязательность, валидации;
• проверка качества: минимальный набор тестов или примеры входов и ожидаемых результатов.

Пример: для формы заявки "готово" - это не "форма работает", а "пользователь отправляет заявку, видит подтверждение, ошибки валидации понятны, дубли не создаются, событие фиксируется".

Что считается не готово (красные флаги)

Если видите один из сигналов ниже, лучше вернуться в план и уточнить, иначе ИИ будет угадывать:

• нет ответа на вопрос "как поймем, что все работает";
• непонятно, какие ошибки возможны и что делать при сбоях;
• роли и доступы не определены, но уже обсуждается интерфейс;
• данные описаны словами ("короткий текст", "нормальная дата") без формата и правил;
• есть критичные интеграции, но нет договоренности про запросы, таймауты и поведение при недоступности.

Когда критерии готовности записаны, можно переходить к коду - в Claude Code, в TakProsto или в любом другом инструменте.

Частые ошибки, из-за которых потом все переделывают

Самая дорогая часть работы с ИИ часто не генерация, а переделки. Они почти всегда появляются из-за размытых вводных.

1) Просят код без плана и без вопросов

Если сразу попросить "сделай страницу/бота/сервис", ИИ начнет заполнять пробелы догадками. На вид все работает, но не совпадает с ожиданиями.

Сначала добейтесь короткого плана: что делаем, в каком порядке, какие решения спорные. И отдельно - список вопросов, без которых нельзя начинать.

2) Смешивают MVP и будущие улучшения

Типичная ловушка: в одном запросе хотят и "простую первую версию", и "чтобы потом легко масштабировалось", и "с красивой админкой". В итоге ИИ строит сложную архитектуру ради функций, которых нет в текущем релизе.

Договоритесь, что входит в первую версию, а что явно откладывается. Если нужно, добавьте фразу: "не закладывай расширение, пока оно не требуется".

3) Не фиксируют ограничения по данным и доступам

Переделки почти гарантированы, если не уточнено: откуда данные, какие поля доступны, где лежат секреты, кто имеет право читать и менять записи.

Достаточно коротко зафиксировать источники данных, роли пользователей, доступы, и что нельзя хранить или логировать.

4) Забывают про ошибки, пустые состояния и права

ИИ легко делает "счастливый путь", но пользователь живет в другом мире: нет данных, сеть упала, доступ запрещен, форма заполнена частично.

Проверьте, что в плане есть хотя бы:

• пустое состояние (нет записей);
• ошибки сети/валидации;
• запрет доступа и понятное сообщение;
• загрузка (пока ждем ответ).

5) Принимают результат без критериев готовности

Когда нет критериев готовности, "похоже работает" становится финальным решением. Потом выясняется, что не хватает сценария, теста или важной проверки.

Принимайте код только по заранее записанным условиям (сценарии, ограничения, поведение на ошибках). Тогда planning mode реально снижает переделки.

Короткий чеклист перед тем, как просить ИИ писать код

Перед стартом сделайте паузу на 2-3 минуты и прогоните задачу по списку. Он убирает двусмысленности, из-за которых потом появляются лишние правки.

• Цель: сформулирована коротко, без слов типа "удобно", "красиво", "быстро". Понятно, что именно появится у пользователя.
• Входные данные: перечислены сущности и поля, а также источники (форма, файл, база, внешний сервис). Если данных еще нет - чем заменяем (пример JSON/CSV, тестовые записи).
• Порядок работ: шаги идут по очереди, и у каждого шага понятен ответственный (ИИ делает код, вы подтверждаете решение, кто-то дает доступы или макет).
• Риски: записано хотя бы три "что может пойти не так" и рядом - способ снизить риск (заглушка, проверка формата, лимиты, логирование, запасной сценарий).
• Готовность: есть список критериев "сделано", и для каждого понятно, как проверить.

Мини-пример: если вы просите ИИ сделать "страницу списка заказов", без чеклиста он может угадать таблицу не той структуры. С чеклистом вы заранее фиксируете поля (id, статус, сумма), источник (таблица orders), шаги (сначала API, потом UI), риски (пустые данные, пагинация), и критерии (фильтр работает, 3 тестовых заказа отображаются корректно).

Пример: как выглядит planning mode на простой задаче

Сценарий: мини-CRM для заявок. Две роли: менеджер создает и ведет заявки, руководитель смотрит сводку и меняет статус, но не редактирует поля клиента.

Цель первой версии (MVP): менеджер может создать заявку, увидеть список и карточку, менять статус; руководитель видит все заявки и отчет по статусам за период. Никаких сложных автоматизаций на старте.

Ограничения: срок 3 дня, только веб. Данные храним в одной базе, без импорта из старых таблиц. Доступы через логин и пароль, без SSO. Интеграций пока нет, но нужно заложить поле для будущего источника (например, "канал").

Риски: дубли заявок (один клиент оставил две заявки), ошибки в правах (руководитель случайно получает редактирование), будущая миграция данных (поля названы так, что потом сложно сопоставить). Для подстраховки заранее фиксируем минимальное правило уникальности (например, проверка по телефону + дате) и матрицу прав в 5-6 строк.

План (без кода): сначала схема данных (Заявка, Клиент, Пользователь, Роль, История статусов), затем API-операции (создать, список с фильтрами, карточка, смена статуса), после этого экраны (логин, список, карточка, отчет), и в конце тестовые сценарии (права, фильтры, дубль, крайние случаи пустых полей).

Критерии готовности, чтобы остановиться и переходить к коду:

• роли и права описаны;
• есть список статусов и правила переходов (например, "Новая" -> "В работе" -> "Закрыта");
• зафиксированы поля заявки и клиента, включая обязательные;
• понятны фильтры в списке (статус, менеджер, дата создания);
• решено, как предотвращаем дубли (минимальное правило и где проверяем).

Перед генерацией кода стоит уточнить еще:

• какие данные руководитель видит в отчете (счетчики, таблица, период по умолчанию);
• как выглядит ошибка доступа (сообщение и код ответа);
• что логируем в истории (смена статуса, кто изменил, когда);
• минимальный набор тестов приемки: 3-5 сценариев, которые должны пройти без обсуждений.

Следующие шаги: как внедрить planning mode в ежедневную работу

Начните с простого правила: любая новая функция сначала проходит через один и тот же шаблон planning mode. Храните его в заметках или в таск-трекере и не меняйте структуру каждый раз. Меняться должны ответы, а не вопросы.

Чтобы не спорить заново через пару недель, ведите короткую историю решений: что выбрали, какие варианты отсеяли и почему. Достаточно 5-7 строк.

Дальше выстраивайте привычку: сначала planning mode в выбранном ассистенте, потом код по частям. Хороший темп: план - маленький кусок реализации - проверка - следующий кусок. Чем меньше порция кода, тем легче ловить ошибки.

Если делаете продукт через TakProsto, фиксируйте в плане ограничения (стек, данные, сроки, требования к безопасности) и проверяйте варианты без риска застрять в неудачной ветке. Снимки и откат можно использовать как страховку: попробовали идею, посмотрели результат, вернулись назад.

После первого релиза не переписывайте все сразу. Соберите обратную связь и обновите план второй итерации.

Мини-рутина на каждый день:

• перед стартом: 5 минут на цель, ограничения и критерии готовности;
• перед кодом: согласовать шаги и риски;
• после результата: 3 заметки - что сработало, что сломалось, что меняем в шаблоне.