Вайбкодинг — практический мини-гайд
Как организовать работу с LLM-агентами, чтобы получать надёжные итерации, минимизировать ошибки и ускорить доставку кода. Я собрал и структурировал свои заметки и превратил их в удобное руководство.
TL;DR
- Всегда в Plan & Review режиме: сначала план, потом реализация.
- Включай auto-run для быстрых итераций — но с белым списком безопасных команд.
- Используй hooks, MCP и множественные LLM-агенты там, где это даёт ценность.
- Откатывай и переписывай постановку задачи вместо бесконечного «исправления» кода агентом.
- Составляй и обновляй правила для агентов, чтобы избегать повторяющихся ошибок.
Мы поговорим о Cursor и Claude Code. Все остальные интсрументы я считаю сильно отстающими от этих двух (по крайней мере на момент авугста 2025), поэтому рассказываю на их примере.
Подпишешься на мой Телеграм канал?
Почему вайбкодинг работает (и когда его не применять)
Вайбкодинг — это набор практик для работы с генеративными агентами, где ключевые преимущества: сверхбыстрая итерация, автоматическая проверка и параллельная работа ИИ-агентов. На самом деле мы все понимаем, что нам лень работать, поэтому почему бы не заставить AI работать за нас.
Не нужно весь код писать с помощью AI, но так же не нужно не отдавать его AI вообще. Если ты программист и не используешь кодинг агентов — есть шанс очень скоро (если не уже) стать неконкурентноспосбным. Понимаю, если этому противишься, но будущее неизбежно.
Если ты не программист — это шанс стать менее тупым в лице коллег программистов. Но на самом деле это прекрасная возможность стать намного полезнее в работе, да и в любых своих проектах.
Не стоит же упоминать, что не нужно полагаться на AI полностью? Впрочем, не уверен, что это даже у тебя получится. Даже если в какие-то моменты кажется, что с помощью ChatGPT ты непобедим и находишься в шоке от тех задач, которые он решил, это не волшебная таблетка. Особенно если не знать, как пользоваться.
Отправная точка
Любой агент сейчас умеет в команду /init. Он автоматически верхнеуровнево просмотрит код и составит документацию в AGENTS.md или своем файле, например, CLAUDE.md. С этого нужно начинать, если начинаешь использовать AI в существующем проекте. Для нового проекта это не нужно.
Более подробно можно поглядеть на соответствующем сайте — agents.md
Основные правила рабочего процесса (Plan & Review)
From writing code to writing specifications
Перед началом: всегда в план-режиме. План — не расплывчатая заметка, а файл в .claude/tasks/TASK_NAME.md:
- Целью и критериями приёмки (done criteria).
- Разбивкой на конкретные таски (MVP first).
- Необходимыми исследованиями / зависимостями и ссылками на источники.
Впрочем уже не так важно, что конкретно там будет, сам его писать все равно не будешь — только проверять состав.
- Просим ИИ составить план действий (только план — без кода).
- Редактируем и утверждаем план.
- Реализация: ИИ делает шаги, обновляет план и лог изменений в том же markdown. Следим.
- После завершения — append с детальным описанием изменений и инструкциями для handover.
Тут важно понимать, что чем лучше и подробнее описана задача, тем лучше будет результат. Планнинг может занять ну очень много времени, но это именна та инвестиция, которая нужна для нормального результата. Будь максимально специфичен.
Если задача требует каких-то внешних знаний, то нужно прямо направить агента эти знания получить и описать.
Следи, чтобы план поддерживался в актуальном состоянии на протяжении работы.
Auto-run: когда включать и как безопасно настроить
Auto-run = автозапуск команд агентом (когда-то его называли yolo mode). Именно тут происохдит вся магия: агент видит логи, фиксит ошибки и снова запускает. Но нужно минимизировать риск, когда он начнет делать что-то не то.
Можно пойти тяжелым путем через белый список команд (например: git commit, npm test, npm run lint, npx repomix) — агент может выполнять только их. И отключать действия, которые могут повредить проду (деплой, удаление данных).
Но проще всего работать в дефолтном режиме, когда все запрещено, а ты апрувишь те или иные команды по ходу работы, но агент больше не будет спрашивать разрешение на эти же команды потом.
Что делать в процессе работы
Допустим, есть план и поехала имплементация. Самое правильное будет двигаться по плану, где он разбит на логические задачи и компоненты. Готов один компонент проекта - проверяешь его, апдейтишь план, коммитишь результаты.
Ведь не у всех агентов есть реверт, особенно у CLI-based тулов типа Claude Code. Впрочем, в Cursor эта фича позволяет вернуться и отменить все, что сделал агент до какого-то запроса. Сильно выделяет эту IDE среди других.
Заставить ИИ «думать вслух»
Перед выполнением команды требуй:
«Сделай по шагам план решения. Не пиши код, только план.»
Это актуально даже когда есть план, и ты уже работаешь внутри него.
Не проси исправить ошибку
Полезная практика — не давать ИИ просто «пофиксить» свою же ошибку, а вместо этого откатиться назад и изменить изначальный промпт. Во-первых, это экономит контекстное окно, во-вторых почти всегда ошибка агента это на самом деле твоя ошибка в постановке задачи. Я всегда в любых AI стараюсь переформулировать изначальную задачу, а не исправлять уже сделанное.
Вообще это вероятно одна из самых ключевых фич при работе с тем же Cursor, у которого как я уже говорил есть фича revert. Я подробнее писал об этом методе взаимодействия с любой LLM в этом посте.
Lazy prompting leads to misaligned solutions and wasted tokens
Изменяй правила на ходу
В IDE с AI-ассистентами есть специальные конфиги, которые определяют правила для конкретного проекта. Например, в Cursor это встроенная фича, которая использует файлы по пути: .cursor/rules/. Такие же правила можно создавать отдельными файлами и указывать их в основном файле агента (AGENTS.md и аналогов).
Там пишем все основные подходы в проекте; это как код-стайлинг гайд для конкретного вашего проекта. Как и куда настраивать логирование, как структурировать файлы, различные конфигурации и прочее. Как только видишь, что агент несколько раз допускает одну и ту же ошибку — это явный сигнал описать эту ситуацию в правилах.
Примеры составления правил ищем в инете. Например, здесь.
Начинай новый чат
Пока мы все дружно ждем дешевых моделей с огромным контекстным окном, чтобы заполнить его всем нашим бесполезным кодом, приходится мириться с главным ограничением LLM — размером контекста. Именно из-за него происходит большинство ошибок, поэтому его нужно экономить.
Вовремя останавливать агента, когда он начинает что-то оверинжинирить или пытается исправить не ту проблему. Останавливать его тогда, когда перестаёшь понимать, что он делает — в это время можно спросить у другого агента, что происходит.
Voice input
Мы уже получили прекрасные технологии для транскрипции нашего голоса в текст (например, Flow). Почему не использовать это и для кодинга тоже? Это отличное пособие поразмышлять вслух, а потом просто очистить лишнее в тексте.
Что добавить в работу
MCP, Perplexity и мульти-LLM проверка
Если не знаешь, что такое MCP -- в интернете куча гайдов, я не буду повторяться.
MCP — включай, когда агент часто использует один и тот же сервис (Sentry, Supabase и т.д.). Но не перегружай контекст. Прикольно конечно пройтись по какому-нибудт awesome MCP list и забрать себе все прикольные штуки оттуда, но агент тогда просто перестанет использовать их вообще. Достаточно двух-трех для конкретного проекта.
- context7 — документация
- browsermcp — дает агенту смотреть в браузер и логи
- serenamcp — упрощает агенту поиск по коду
Любой MCP для сервиса или тула, который часть используешь в проекте может оказаться полезен.
Помни, что MCP занимают токены в контексте, даже если не используются.
Используй Perplexity для внешней проверки API/документации. Иногда это намного проще, чем просить агента искать, ждать пока он разберется и усложнит что-нибудь.
Multi-LLM validation: параллельно прогнать несколько моделей на ту же задачу — сравнить ответы и выбрать лучший. Отлично для спорных design-decision.
Как работать с UI
Приучите его (и себя) работать по картинке. Один из самых эффективных способов ставить задачи на UI/UX — дать скриншот, нарисованную от руки схему или макет и сказать: «Сделай так». ИИ отлично понимает визуальные цели и будет итерировать, пока результат не совпадет с макетом.
Впрочем, уже появилось огромное количество сервисов и проектов, которые помогают работать с визуалом. Начиная от Lovable, заканчивая какими-нибудь Superdesign.dev.
Полезные штуки для Claude Code
npx ccstatusline@latest — кастомизация status line
npx ccusage blocks --live -- мониоринг использования
double tap EXIT — перейти к предыдущему сообщению
Hooks: используем их для автоматического запуска шагов (lint, тесты, миграции) при определённых action. Например, есть определенный стиль того как хочешь чтобы выглядели коммиты и что должно быть сделано перед коммитом — опиши это отдельным промптом и сделай хук /commit.
Ну и не забывайте, что в нашем распоряжении еще есть:
Заключение
Все, что я здесь пишу, может уже быть неактуально через несколько месяцев. Ирония развития кодинг-агентов заключается в том, что то, что мы делаем сейчас вручную и что действительно работает, через какое-то время станет встроенной фичей агента. Когда я начал собирать заметки для этого гайда, я очень хотел рекомендовать тулзу Task-master, которая готовила серьезный развернутый план, оценивая сложность задачи и разбивая их на сабтаски. Plan mode того же CC сейчас делает это из коробки, и task-master уже не особо актуален. То же самое произойдет с остальными фишками, пока мы не придем к моменту, когда почти все агенты смогут делать это сами.
Подпишешься на мой Телеграм канал?
Чеклист — что можно делать сразу
Создать шаблон задачи и начать с него для первой фичи:
- .claude/tasks/TASK_NAME.md (цель, критерии готовности, MVP-шаги, файлы для изменения, риски).
- Попросить агента составить план (только план, 5–10 шагов) и утвердить его вручную.
- Настроить репо: добавить AGENTS.md / .claude с правилами проекта (логирование, формат коммитов, hooks).
- Настроить белый список команд для auto-run (начать с минимального: git commit, npm test, npm run lint) и запретить всё остальное.
- Отключить/запретить доступ к продакшену агентам — ручной контроль на деплой. ⚠️
- Внедрить частые коммиты: коммитить по завершении каждого логического шага.
- При ошибке — откатывай изменения и переформулируй исходную задачу/промпт, а не проси агент исправить всё подряд.
- Подключить базовые хуки: предкоммитные проверки (lint/tests) и автоматический запуск тестов в CI.
- Подключить 1–2 полезных MCP (например, docs/browsermcp) осторожно — не перегружая контекст.
- Завести короткий чеклист безопасности для PR (SCA, secret scanning, тесты, план в .claude/tasks).