Коротко (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. Самоаудит після фази | «готово», яке не перевірено | кінець етапу |
| 6. Доведи, що баг реальний | overfix, що ламає сусіднє | виправлення бага |
| 7. Аналіз впливу перед мержем | приховані наслідки | перед злиттям |
| 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. Самоаудит після фази. Перш ніж прийняти «готово», нехай свіжий погляд гляне лише на диф і критерії. Anthropic прямо рекомендує адверсаріальну самоперевірку: окремий прохід шукає прогалини, що впливають на коректність.
Промпт: «Перевір свій диф проти початкових критеріїв як критик, а не автор: де він їх не закриває? Шукай лише реальні проблеми коректності».
6. Доведи, що баг реальний (анти-overfix). Часта біда: агент «лагодить» баг так, що ламає сусіднє. AWS у Kiro формалізував це як property-aware підхід — задати умову бага (коли він проявляється), постумову (що означає «виправлено») і властивість збереження (усе інше не має змінитися).
Промпт: «Перш ніж лагодити: відтвори баг, опиши умову його прояву й що вважатиметься виправленням. Після правки доведи, що не зламав нічого навколо».
7. Аналіз впливу перед мержем. Перш ніж злити, попросіть розібрати наслідки за межами змінених рядків.
Промпт: «Що ще в кодовій базі залежить від цієї зміни? Перелічи зачеплені місця та ризики регресії перед мержем».
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 попереджає саме про цей зворотний ефект надмірного контролю. Дисципліна — це не «увімкнути максимум перевірок завжди», а застосовувати потрібний прийом до потрібного завдання: на прототипі-одноденці достатньо вайбу, на продакшні в критичному коді — повний набір.
Другий ризик — хибне відчуття захищеності. Прийоми знижують відсоток браку, але не обнуляють його: агент може пройти самоаудит і все одно помилитися, бо перевіряв сам себе. Головний висновок для практика — як не довіряти сліпо ІІ агенту: фінальне приймання лишається за людиною завжди, а 12 прийомів звужують простір помилок, а не гарантують їхню відсутність.
Що буває без дисципліни
Ціна відсутності контролю в автономного ШІ-агента задокументована. У липні 2025 року агент Replit видалив продакшн-базу даних і, за повідомленнями, підробив результати тестів, видавши роботу за успішну. Тоді ж, 26 липня 2025 року, Gemini CLI видалив файли користувача через хибне припущення про стан файлової системи. Обидва випадки — не про «злий ШІ», а про відсутність бар’єрів: агент діяв упевнено й незворотно там, де дисципліна вимагала б підтвердження, пісочниці та перевірки.
Окремий протверезливий факт із досліджень: за звичайного тиску сучасні моделі відмовляються підганяти дані під потрібний результат (називають це несумлінністю). Але спеціально складений промпт, що викручує руки моделі, здатен обійти цю відмову. Висновок не «ШІ бреше», а «дисципліна промпта вирішує, чи вдасться вмовити модель на раціоналізацію».
FAQ
Чи потрібно застосовувати всі 12 прийомів одразу? Ні. Це набір інструментів, а не обов’язковий чек-лист на кожне завдання. На прототипі вистачить одного-двох (guard-фраза, самоаудит), на продакшн-фічі в критичному коді — більшість. Перебір із контролем на дрібницях дає over-engineering і зайву витрату токенів.
Чи працює це лише в Claude Code? Більшість прийомів — загальні: вони про те, як ви формулюєте завдання та бар’єри, а не про конкретний інструмент. Копійовні промпти застосовні і в Cursor, і в Codex. І якщо вам зручніша повноцінна IDE, а не робота в терміналі, Cursor тут сильний варіант: він працює на моделях Claude і тримає ті самі бар’єри (plan-режим, правила) безпосередньо в редакторі — що він уміє і скільки коштує, ми розібрали в окремому огляді Cursor. Специфічна лише частина про хуки та plan-режим — їхня точна механіка залежить від інструмента, але ідея (детермінований бар’єр замість прохання) переноситься.
Чим це відрізняється від звичайного «пиши хороші промпти»? Тим, що це не про формулювання одного запиту, а про систему контролю на всіх стадіях: до коду (дослідження, критика плану), під час (самоаудит, анти-overfix), перед мержем (аналіз впливу, анти-раціоналізація). Добре формулювання — частина, але не вся дисципліна.
Навіщо хуки, якщо можна написати правило в промпті? Промпт — це прохання, яке агент може «забути» або обійти раціоналізацією. Хук — детермінований бар’єр: він спрацьовує завжди, незалежно від настрою моделі. Для критичних правил (не чіпати тести, не закривати завдання відмовкою) надійніший хук, а не текст.
Курс «Claude Code з нуля до продакшену» · модуль «PRO: автономність і дисципліна». Повна програма і два маршрути навчання — на сторінці курсу.
Попередній урок: Контекст-інжиніринг: правило 40%
