Нам нужен план

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

Нужна нам, скажем, форма авторизации. Мы не можем просто так взять и сказать: Йоу, сотвори форму авторизации😃

Потому что там нужны понятные: 1. Фронт (адаптив, состояния, UX) 2. Бэк (эндпоинты, сессии/токены, безопасность) 3. Миграции (таблицы, индексы, ограничения) и куча всего еще.

Вот мы и делаем план 🤖

В Cursor переключаетесь в режим Plan и пишете что-то вроде:

«Проанализируй проект и составь план по внедрению окна авторизации. Опиши фронт и бэк. Укажи миграции, проверки и критерии приемки». Можно даже сказать пожалуйста.🙏

И агент реально читает проект и потом такой: План по созданию формы авторизации

Цель — Пользователь может войти/выйти — Сессия сохраняется и корректно истекает — Защищенные страницы недоступны без авторизации

Ограничения — Не трогать существующие публичные роуты — Не менять схему users без миграции — Не ломать текущие интеграции — Не переписывать архитектуру «заодно», только то, что нужно для задачи

Шаг 1. Аудит текущего проекта — Где сейчас хранится пользователь (если уже есть) …

Шаг 2. Определить модель авторизации — Email+пароль / код на почту / оба варианта …

Шаг 3. Миграции и БД — users (если нет) + уникальность email …

Шаг 4. Бэкенд: эндпоинты — POST /auth/login …

Шаг 5. Фронтенд: UI и состояния — Страница/модалка авторизации …

Шаг 6. Интеграция — Auth store/provider …

Шаг 7. Проверки и тесты — Минимум: ручной чек-лист сценариев …

Критерии приемки — Логин/логаут работают стабильно … И вот такой темы сразу на много экранов. Этапы внедрения в самом конце

И вот тут самое вкусное🤤: читаешь план и видишь, чего не хватает. И пишешь: Накинь вход по коду на электронную почту И он переделывает. Не код. План.

Как только план готов — дальше по вкусу: — жмешь Build и агент делает по шагам (с дифами) — или если такого режима нет: открываешь второго агента, кидаешь ему PLAN.md и говоришь: «Выполни попунктно, после каждого пункта показывай, что поменялось и что проверить».

Claude Code Там план — это отдельный режим: Plan Mode. Сначала выбиваешь пошаговый план, правишь требования, и только потом выходишь из Plan Mode и начинаешь исполнение.

VS Code / GitHub Copilot Chat Там тоже есть «планирование» как отдельный этап: агент собирает todo/шаги, чтобы было понятно, что именно будет сделано, и уже потом запускаешь реализацию.

OpenAI Codex (CLI/IDE extension) У Codex план обычно живет как артефакт: PLAN.md / SPEC.md. Сначала просишь «собери план», потом «выполняй по шагам», а ты контролируешь дифы и проверки.

Что еще можно делать с планом

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

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

Что полезно явно держать в плане: — Цель и не-цель (что не делаем) — Ограничения (что нельзя трогать) — Артефакты (какие файлы/таблицы/эндпоинты появятся) — Пошаговая реализация + проверка после каждого шага — Риски и откат (что может сломаться и как вернуть назад) — Критерии приемки (проверяемые)

Когда план особенно нужен — 🖲Поднять голый VPS до прод-готовности (пользователь, ssh hardening, firewall, nginx, сертификаты, postgres, бэкапы, мониторинг, логи, секреты, деплой) — 💰Внедрить оплату (webhook-и, идемпотентность, статусы, ретраи, миграции, аудит-лог) — 🛠Большой рефакторинг (план миграции, совместимость, фича-флаги, этапы)

Когда можно и без плана 1. Поправить класс 2. Переименовать пару переменных 3. Добавить простую проверку 4. Поправить верстку в одном месте

Было: Запрос → агент кодит → ты ревьюишь код → переделываешь

Стало: Запрос → агент планирует → ты ревьюишь план → агент кодит → ты контролируешь дифы

План — это ваш контракт с агентом. Агент делает план, вы с важным видом смотрите на генерацию 🖥 https://t.me/vibe_coders_only/61 #vibe_coding #cursor #агенты #workflow #планирование #Разработка