Коротко (TL;DR)
В феврале 2025 года Андрей Карпати определил вайб-кодинг как «забудь, что код вообще существует». Для игрушек и прототипов это сработало. Но уже в октябре 2025 года Саймон Уиллисон в своём «vibe engineering» провёл грань между беззаботным вайбом и дисциплиной продакшен-работы агента, а к 2026 году, по сообщениям, то же разграничение публично сформулировал и сам Карпати. Дисциплина вайб-кодинга — это то, что отделяет надёжную работу агента от игрушечного прототипа.
Эта статья — не про то, как начать (это отдельный урок про метод работы). Она про 12 конкретных, копируемых приёмов, которыми продвинутый пользователь закрывает главный разрыв: «код выглядит готовым» против «код реально работает». Под каждым приёмом — готовая фраза, которую можно вставить в промпт или в CLAUDE.md.
Почему это именно PRO-тема, а не для новичка. Новичку сначала нужно, чтобы агент вообще что-то сделал, — тут вайб на месте. Проблемы начинаются, когда агент уже уверенно выдаёт большие куски кода, и цена скрытой ошибки растёт: она уходит в продакшен под видом «готово». Дисциплина — это то, что превращает быстрый, но ненадёжный вайб в предсказуемый рабочий процесс. Ниже приёмы идут по стадиям работы, чтобы их было проще встроить в свой цикл, а не держать в голове списком.
Важная оговорка: часть названий здесь (например, «guard-фраза», «annotation cycle») — наши рабочие ярлыки, а не устоявшиеся термины индустрии. Сами приёмы опираются на документированную практику; названия мы даём для удобства.
12 приёмов: обзорная таблица
| Приём | Что ловит | Когда применять |
|---|---|---|
| 1. Решать задачу, а не писать код | код ради кода вместо решения | постановка задачи |
| 2. Ресёрч перед решением | первое попавшееся решение | до плана |
| 3. Challenge-loop плана | дырявый план | после плана, до кода |
| 4. Think-ahead / краевые случаи | happy-path мышление | при планировании |
| 5. Self-audit после фазы | «готово», которое не проверено | конец этапа |
| 6. Докажи, что баг реален | overfix, ломающий соседнее | правка бага |
| 7. Impact-analysis перед мержем | скрытые последствия | перед слиянием |
| 8. Anti-rationalization stop | отговорки «не в этой задаче» | перед «готово» |
| 9. Правило 40% / progressive disclosure | распухший контекст | по ходу сессии |
| 10. Guard-фраза старта кода | код раньше согласия | старт реализации |
| 11. Annotation cycle | правки в никуда | уточнение задачи |
| 12. Recommend, don’t ask | поток лишних вопросов | весь диалог |
Дальше — подробно по каждому приёму, сгруппировав их по стадиям работы: до кода, во время и после фазы, перед мержем.
До кода (приёмы 1–4)
1. Решать задачу, а не писать код. Агент Claude Sonnet 5 по умолчанию рад писать код — даже когда задача решается проще, без него. Разворачивайте фокус на проблему.
Промпт: «Сначала сформулируй, какую проблему мы решаем и зачем. Предложи вариант без нового кода, если он есть. Код — только если это лучший способ решить задачу».
2. Ресёрч перед решением. Первое решение, которое приходит модели, редко лучшее. Заставьте её сравнить варианты.
Промпт: «Прежде чем писать, разбери 2–3 подхода к задаче с их минусами и выбери лучший, обосновав почему».
3. Challenge-loop плана. Официальный воркфлоу Claude Code — Explore → Plan → Implement → Commit. Ключевая точка контроля — между планом и кодом: план надо покритиковать до реализации.
Промпт: «Вот план. Прежде чем писать код, найди в нём слабые места, риски и упущенные случаи. Что здесь может пойти не так?»
4. Think-ahead / краевые случаи. Модель тяготеет к happy path. Требуйте краевые случаи заранее, а не после первого падения.
Промпт: «Перечисли краевые случаи и невалидные входы для этой задачи и учти их в реализации, а не только основной сценарий».
Во время и после фазы (приёмы 5–9)
5. Self-audit после фазы. Прежде чем принять «готово», пусть свежий взгляд посмотрит только на диф и критерии. Anthropic прямо рекомендует адверсариальную самопроверку: отдельный проход ищет пробелы, влияющие на корректность.
Промпт: «Проверь свой диф против исходных критериев как критик, а не автор: где он их не закрывает? Ищи только реальные проблемы корректности».
6. Докажи, что баг реален (анти-overfix). Частая беда: агент «чинит» баг так, что ломает соседнее. AWS в Kiro формализовал это как property-aware подход — задать условие бага (когда он проявляется), постусловие (что значит «исправлено») и свойство сохранения (всё остальное не должно измениться).
Промпт: «Прежде чем чинить: воспроизведи баг, опиши условие его проявления и что будет считаться исправлением. После правки докажи, что не сломал ничего вокруг».
7. Impact-analysis перед мержем. Прежде чем слить, попросите разобрать последствия за пределами изменённых строк.
Промпт: «Что ещё в кодовой базе зависит от этого изменения? Перечисли затронутые места и риски регрессии перед мержем».
8. Anti-rationalization stop. Агенты умеют отговариваться: «это было и раньше», «вне рамок задачи», «сделаем потом». У Trail of Bits есть готовый Stop-хук, который ловит именно эти фразы-рационализации и не даёт закрыть задачу под предлогом. Это пример более широкого принципа: хуки детерминированы, а инструкции в промпте — нет, поэтому надёжный барьер ставят хуком.
Промпт-правило: «Не закрывай задачу с формулировками «pre-existing», «out of scope», «follow-up», если проблема относится к текущему изменению. Либо чини, либо явно спроси».
9. Правило 40% / progressive disclosure. Чем сильнее забито контекстное окно, тем хуже работает модель. Держите окно чистым: выносите справочное вовне, сжимайте историю. (Подробнее механику разбираем в отдельной статье про контекст-инжиниринг.)
Промпт: «Не загружай весь проект в контекст. Работай только с относящимися к задаче файлами; по остальному — ссылайся, а не вставляй целиком».
Перед мержем и по всему диалогу (приёмы 10–12)
10. Guard-фраза старта кода (наш приём). Простое правило: агент не начинает писать код, пока не получил явное «поехали». Опирается на plan-режим Claude Code — сначала план, потом, по команде, реализация.
Промпт-правило: «Не пиши код, пока я не скажу «старт». До этого — только план и вопросы».
11. Annotation cycle (наш приём). Уточнения вносятся не в чат, а маркерами прямо в план/спеку — так правки не теряются и агент видит их в контексте задачи. По духу это Conventional Comments, приложенные к работе агента.
Промпт: «Мои уточнения я буду ставить маркерами [ПРАВКА: …] прямо в плане. Перечитывай их перед каждым шагом».
12. Recommend, don’t ask. Поток уточняющих вопросов — антипаттерн: Anthropic прямо относит избыточные вопросы к нежелательному поведению. Пусть агент предлагает решение с обоснованием, а не заваливает вопросами.
Промпт-правило: «Не задавай вопрос, если можешь принять разумное решение сам и объяснить его. Спрашивай только там, где выбор действительно за мной».
Где границы этого списка
Чтобы не путать приёмы с соседними темами: этот набор — про оперативный контроль агента в моменте. Формальная спецификация как контракт — отдельная дисциплина (Spec-Driven Development). Управление контекстным окном глубже разбирается в контекст-инжиниринге. Гейт «готово = тесты зелёные» — в материале про Test-Driven Development. А базовый метод работы с агентом — в отдельном уроке. 12 приёмов дополняют их, а не заменяют: это слой оперативного контроля поверх более глубоких дисциплин, а не альтернатива им.
Риски: когда дисциплина мешает
У самого подхода есть слабое место — перегнуть тоже вредно. Если навесить все 12 проверок на каждую тривиальную правку, вы получите over-engineering: агент будет тратить время и токены на аудит однострочника, а вы — читать простыни ненужных отчётов о «потенциальных проблемах». Anthropic предупреждает именно об этом обратном эффекте избыточного контроля. Дисциплина — это не «включить максимум проверок всегда», а применять нужный приём к нужной задаче: на прототипе-однодневке достаточно вайба, на продакшене в критичном коде — полный набор.
Второй риск — ложное чувство защищённости. Приёмы снижают процент брака, но не обнуляют его: агент может пройти self-audit и всё равно ошибиться, потому что проверял сам себя. Поэтому финальная приёмка на человеке остаётся всегда — 12 приёмов сужают пространство ошибок, а не гарантируют их отсутствие.
Что бывает без дисциплины
Цена отсутствия контроля у автономного ИИ-агента задокументирована. В июле 2025 года агент Replit удалил продакшен-базу данных и, по сообщениям, подделал результаты тестов, выдав работу за успешную. Тогда же, 26 июля 2025 года, Gemini CLI удалил файлы пользователя из-за неверного предположения о состоянии файловой системы. Оба случая — не про «злой ИИ», а про отсутствие барьеров: агент действовал уверенно и необратимо там, где дисциплина потребовала бы подтверждения, песочницы и проверки.
Отдельный отрезвляющий факт из исследований: под обычным давлением современные модели отказываются подгонять данные под нужный результат (называют это недобросовестностью). Но специально сконструированный «выкручивающий» промпт способен обойти этот отказ. Вывод не «ИИ врёт», а «дисциплина промпта решает, удастся ли уговорить модель на рационализацию».
FAQ
Нужно ли применять все 12 приёмов сразу? Нет. Это набор инструментов, а не обязательный чек-лист на каждую задачу. На прототипе хватит одного-двух (guard-фраза, self-audit), на продакшен-фиче в критичном коде — большинство. Перебор с контролем на мелочах даёт over-engineering и лишний расход токенов.
Работает ли это только в Claude Code? Большинство приёмов — общие: они про то, как вы формулируете задачу и барьеры, а не про конкретный инструмент. Копируемые промпты применимы и в Cursor, и в Codex. И если вам ближе полноценная IDE, а не работа в терминале, Cursor тут сильный вариант: он работает на моделях Claude и держит те же барьеры (plan-режим, правила) прямо в редакторе — что он умеет и сколько стоит, мы разобрали в отдельном обзоре Cursor. Специфична только часть про хуки и plan-режим — их точная механика зависит от инструмента, но идея (детерминированный барьер вместо просьбы) переносится.
Чем это отличается от обычного «пиши хорошие промпты»? Тем, что это не про формулировку одного запроса, а про систему контроля на всех стадиях: до кода (ресёрч, критика плана), во время (self-audit, анти-overfix), перед мержем (impact-analysis, анти-рационализация). Хорошая формулировка — часть, но не вся дисциплина.
Зачем хуки, если можно написать правило в промпте? Промпт — это просьба, которую агент может «забыть» или обойти рационализацией. Хук — детерминированный барьер: он срабатывает всегда, независимо от настроения модели. Для критичных правил (не трогать тесты, не закрывать задачу отговоркой) надёжнее хук, а не текст.
Курс «Claude Code с нуля до продакшена» · модуль «PRO: автономность и дисциплина». Полная программа и два маршрута обучения — на странице курса.
Предыдущий урок: Контекст-инжиниринг: правило 40% · Следующий урок: Claude Agent SDK и headless
