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 работает на серверах в России и использует локализованные модели, что удобно для проектов, где важно не выводить данные за пределы страны.
Чтобы ИИ не гадал, удобно собрать ограничения в короткий список:
Чаще всего ломается не логика, а данные. Если заранее не договориться, какие сущности существуют и откуда они берутся, ИИ быстро нагенерирует красивую структуру, которую потом придется подгонять под реальность.
Начните с карты входных данных на уровне здравого смысла: какие сущности точно есть (пользователь, заказ, платеж, файл, комментарий). Для каждой сущности достаточно понять: кто создает, кто читает, как удаляется (если вообще), какие есть статусы.
Дальше уточните источники и интеграции. Важно прописать не только "откуда", но и "как обновляем": по кнопке, по расписанию, по вебхуку, при каждом открытии экрана. И обязательно решите, что считается источником правды, если данные расходятся.
Полезный минимум схемы для первой версии:
Пример: "заказ" без деталей не работает. Нужны хотя бы id, user_id, сумма, валюта, статус (новый, оплачен, отменен), created_at. По платежам важно решить заранее: подтверждение приходит вебхуком или вы опрашиваете провайдера сами. От этого зависит модель статусов и обработка повторных событий.
И обязательно отметьте, что откладываете: историю изменений, сложные роли, редкие поля, импорт из старой системы, расширенную аналитику. Это помогает не пытаться "сразу сделать идеально".
Planning mode ломается не из-за ИИ, а из-за туманных вводных. Чем раньше вы поймаете риск, тем меньше будет спорных правок.
Частые точки поломки:
Риск обычно видно по словам "примерно", "как обычно", "потом уточним". В этот момент стоит остановиться и задать три вопроса: какие входы и выходы (с примерами), что считается ошибкой, и кто принимает результат.
Простой план подстраховки:
Если риск все же реализовался, заранее выбирайте запасной вариант. Например, если внешнее API нестабильно, закладывайте заглушки и очередь повторных попыток.
Если вы хотите меньше переделок, не просите ИИ сразу писать код. Сначала договоритесь о плане: что делаем, что не делаем, какие данные нужны и как проверить результат.
Сформулируйте, чего вы ждете от ИИ именно сейчас. Обычно есть три режима: (1) задать уточняющие вопросы, (2) предложить план и разбиение на задачи, (3) набросать каркас без деталей. Код появляется только после того, как вы подтвердили первые два пункта.
Попросите артефакты, которые удобно обсуждать:
Заранее задайте формат ответа. ИИ часто "растекается" текстом, если не попросить форму. Работают простые рамки: нумерованные шаги для плана, чеклист для критериев, таблица для сущностей и полей.
Хорошее правило: сначала вопросы и план, потом код. Прямо так и напишите.
Сначала задай уточняющие вопросы (до 7). Затем предложи план в 8-12 шагов.
Отдельно: структура файлов, схема данных (таблица), критерии готовности (чеклист).
Код не генерируй, пока я не отвечу и не подтвержу план.
Такой запрос дисциплинирует диалог: вы видите пробелы в требованиях до того, как они превратятся в лишние коммиты и переписанные модули.
Planning mode обычно занимает 10-20 минут, но часто экономит часы переделок. Идея простая: сначала фиксируем смысл и границы, потом просим ИИ писать код.
Последовательность из 5 шагов:
Шаблон, который удобно копировать в чат:
ЗАДАЧА:
Контекст:
Цель (1 фраза):
MVP (что входит):
Не делаем в MVP:
Неизвестные вопросы (ответьте перед кодом):
Данные:
- Сущности и поля:
- Источник данных / хранилище:
Экраны или API:
- Экраны (если UI):
- Эндпоинты (если API):
План работ (по шагам):
Риски и как проверим:
Критерии готовности (чек):
Пример короткого критерия: "Пользователь может создать запись, увидеть ее в списке, удалить, и после перезагрузки страницы все сохраняется". Это сразу задает проверяемый результат.
Planning mode полезен только тогда, когда у плана есть четкая точка остановки. Иначе вы будете бесконечно уточнять детали, а потом все равно получите переделки - просто позже.
Смысл критериев готовности - заранее договориться, что именно считается результатом и как вы это проверяете.
Хороший набор критериев покрывает три слоя: пользовательские сценарии, поведение в ошибках и способ проверки.
Минимальный ориентир:
Пример: для формы заявки "готово" - это не "форма работает", а "пользователь отправляет заявку, видит подтверждение, ошибки валидации понятны, дубли не создаются, событие фиксируется".
Если видите один из сигналов ниже, лучше вернуться в план и уточнить, иначе ИИ будет угадывать:
Когда критерии готовности записаны, можно переходить к коду - в Claude Code, в TakProsto или в любом другом инструменте.
Самая дорогая часть работы с ИИ часто не генерация, а переделки. Они почти всегда появляются из-за размытых вводных.
Если сразу попросить "сделай страницу/бота/сервис", ИИ начнет заполнять пробелы догадками. На вид все работает, но не совпадает с ожиданиями.
Сначала добейтесь короткого плана: что делаем, в каком порядке, какие решения спорные. И отдельно - список вопросов, без которых нельзя начинать.
Типичная ловушка: в одном запросе хотят и "простую первую версию", и "чтобы потом легко масштабировалось", и "с красивой админкой". В итоге ИИ строит сложную архитектуру ради функций, которых нет в текущем релизе.
Договоритесь, что входит в первую версию, а что явно откладывается. Если нужно, добавьте фразу: "не закладывай расширение, пока оно не требуется".
Переделки почти гарантированы, если не уточнено: откуда данные, какие поля доступны, где лежат секреты, кто имеет право читать и менять записи.
Достаточно коротко зафиксировать источники данных, роли пользователей, доступы, и что нельзя хранить или логировать.
ИИ легко делает "счастливый путь", но пользователь живет в другом мире: нет данных, сеть упала, доступ запрещен, форма заполнена частично.
Проверьте, что в плане есть хотя бы:
Когда нет критериев готовности, "похоже работает" становится финальным решением. Потом выясняется, что не хватает сценария, теста или важной проверки.
Принимайте код только по заранее записанным условиям (сценарии, ограничения, поведение на ошибках). Тогда planning mode реально снижает переделки.
Перед стартом сделайте паузу на 2-3 минуты и прогоните задачу по списку. Он убирает двусмысленности, из-за которых потом появляются лишние правки.
Мини-пример: если вы просите ИИ сделать "страницу списка заказов", без чеклиста он может угадать таблицу не той структуры. С чеклистом вы заранее фиксируете поля (id, статус, сумма), источник (таблица orders), шаги (сначала API, потом UI), риски (пустые данные, пагинация), и критерии (фильтр работает, 3 тестовых заказа отображаются корректно).
Сценарий: мини-CRM для заявок. Две роли: менеджер создает и ведет заявки, руководитель смотрит сводку и меняет статус, но не редактирует поля клиента.
Цель первой версии (MVP): менеджер может создать заявку, увидеть список и карточку, менять статус; руководитель видит все заявки и отчет по статусам за период. Никаких сложных автоматизаций на старте.
Ограничения: срок 3 дня, только веб. Данные храним в одной базе, без импорта из старых таблиц. Доступы через логин и пароль, без SSO. Интеграций пока нет, но нужно заложить поле для будущего источника (например, "канал").
Риски: дубли заявок (один клиент оставил две заявки), ошибки в правах (руководитель случайно получает редактирование), будущая миграция данных (поля названы так, что потом сложно сопоставить). Для подстраховки заранее фиксируем минимальное правило уникальности (например, проверка по телефону + дате) и матрицу прав в 5-6 строк.
План (без кода): сначала схема данных (Заявка, Клиент, Пользователь, Роль, История статусов), затем API-операции (создать, список с фильтрами, карточка, смена статуса), после этого экраны (логин, список, карточка, отчет), и в конце тестовые сценарии (права, фильтры, дубль, крайние случаи пустых полей).
Критерии готовности, чтобы остановиться и переходить к коду:
Перед генерацией кода стоит уточнить еще:
Начните с простого правила: любая новая функция сначала проходит через один и тот же шаблон planning mode. Храните его в заметках или в таск-трекере и не меняйте структуру каждый раз. Меняться должны ответы, а не вопросы.
Чтобы не спорить заново через пару недель, ведите короткую историю решений: что выбрали, какие варианты отсеяли и почему. Достаточно 5-7 строк.
Дальше выстраивайте привычку: сначала planning mode в выбранном ассистенте, потом код по частям. Хороший темп: план - маленький кусок реализации - проверка - следующий кусок. Чем меньше порция кода, тем легче ловить ошибки.
Если делаете продукт через TakProsto, фиксируйте в плане ограничения (стек, данные, сроки, требования к безопасности) и проверяйте варианты без риска застрять в неудачной ветке. Снимки и откат можно использовать как страховку: попробовали идею, посмотрели результат, вернулись назад.
После первого релиза не переписывайте все сразу. Соберите обратную связь и обновите план второй итерации.
Мини-рутина на каждый день:
Planning mode — это короткое согласование смысла до того, как ИИ начнет писать код. Вы фиксируете цель, границы (MVP), данные, роли, интеграции, риски и критерии “готово”.
Он решает главную проблему: ИИ перестает “догадывать” детали и реже генерирует рабочее решение для другой задачи.
Обычно достаточно 10–20 минут на первую версию плана. Время растет, если много ролей, интеграций и спорных правил.
Практичный ориентир: пока вы можете уместить цель, ограничения, данные и критерии “готово” на один экран текста — план не раздувается.
Сначала сформулируйте результат в одном предложении: что появится (экран, API-метод, фоновая задача).
Затем добавьте:
Начните с явного списка:
Полезная фраза для запроса к ИИ: «Не добавляй расширения и сложную архитектуру, пока они не нужны в MVP». Это снижает шанс получить “идеальный” код ради будущих функций.
Минимум, который стоит описать до кода:
Без этого ИИ часто делает “красивую” структуру, которую потом приходится подгонять под реальность.
Зафиксируйте три вещи:
И сразу решите план Б: заглушки, очередь повторных попыток, частичная деградация функционала.
Сделайте простую матрицу:
Минимум, который стоит определить:
Это предотвращает типичную переделку, когда интерфейс уже готов, а права выясняются позже.
Ищите маркеры неопределенности: «примерно», «как обычно», «потом уточним». В этот момент остановитесь и уточните:
Базовая страховка:
Хорошие критерии “готово” покрывают:
Если критериев нет, “похоже работает” станет финалом, и недостающие детали всплывут уже после релиза.
Удобный порядок такой:
В TakProsto дополнительно помогает дисциплина процесса: фиксируете стек и ограничения в чате, делаете изменения маленькими порциями, а для экспериментов используете снимки и откат, чтобы не “застрять” в неудачном варианте.