Vibe coding: сетап під AI — це не інсталяція один раз, а звичка, яку треба оновлювати

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, мене звати Антон Небилиця, я Senior AI-Accelerated Software Engineer в SPD Technology. У першій частині я розібрав, чому AI-assisted розробка часто розчаровує: завищені очікування, швидкість без осмислення та три структурні сліпі зони, які AI в принципі не бачить. В цій статті я розкажу про конкретні прийоми, які змінили мій підхід до роботи з AI-агентами.

Якщо після тих шести кейсів із частини 1 виникло бажання закрити вкладку й повернутись до старого підходу — це нормальна реакція, і ця стаття саме для цього моменту. Головна теза тут проста: працює не одноразовий «ідеальний сетап під ключ», а ітеративний процес. Даєш AI задачу, бачиш, де саме вона зробила не так — не «загалом погано», а конкретний патерн — явно фіксуєш це, і надалі, в межах цього проєкту, вона вже так не робить. Це не одноразова інсталяція, а звичка, яка накопичується.

Планування й перевірка поперед коду

Я не даю моделі писати код одразу. Спершу йде окрема задача на валідацію/планінг: сильна модель отримує мою архітектуру або вимоги і шукає конфлікти з тим, що вже задокументовано або реалізовано в репозиторії, і тільки потім я переходжу до реалізації, часто вже слабшою моделлю. Це розділення (сильніша на планування й перевірку, слабша на рутину) знімає більшість «правдоподібних, але неправильних» рішень ще до того, як вони потраплять у MR.

Уточню, що я маю на увазі під «сильна» і «слабка» модель, бо в 2026 це вже не завжди про різних вендорів, а про рівень reasoning-зусиль (effort) у межах однієї моделі. Мій дефолт — Claude Sonnet 5 зі звичайним ефортом на все рутинне кодування, і піднімаю його до xhigh лише на плануванні й архітектурних рішеннях. Opus 5 вмикаю рідко: тільки коли задача торкається майже всієї кодової бази (великий рефактор, наскрізна міграція), там вища «стеля» міркувань окупається, а для звичайного дня це просто дорожче й повільніше без відчутного приросту.

У Google взагалі інша історія: топової моделі там просто немає. Gemini 3.5 Pro обіцяли ще в травні 2026, а станом на середину серпня вона так і не вийшла — це вже три пропущені дедлайни. Схоже, Google тим часом почав тренувати наступне покоління й фактично обійшов цей реліз. Натомість вони кожні кілька тижнів випускають нову Flash-модель: 3.5 > 3.6 > 3.7 за менш ніж два місяці, і саме 3.7 Flash (13 серпня 2026) зараз позиціонують як найкращу для агентного кодингу — за рівнем десь між Sonnet 5 і Opus 5/GPT-5.6 Sol. Пряма аналогія «дефолт/топ» тут просто неможлива, поки топ не вийшов — раджу перевіряти актуальний лідерборд, а не орієнтуватись на назву лінійки.

Окремо про локальні моделі: свідомо не рекомендую їх тут, бо вони потребують окремого заліза й суттєво тоншого тюнінгу, щоб наблизитись до якості хмарних. Розробляти на них можна, але тільки з жорсткішим людським рев’ю: банальних багів і прогалин там типово більше.

І ще один нюанс, який легко проґавити: дешевший токен не означає дешевшу задачу. Свіжий бенчмарк Databricks на промисловому кодбейзі (ще на Opus 4.8, до релізу Opus 5) показав: Sonnet 5 вийшов дорожчим за задачу, ніж Opus 4.8 ($2.09 проти $1.94), попри дешевший токен — просто тому, що витрачав у 1.9 раза більше токенів на дослідження коду в межах задачі й частіше не доводив її до кінця з першого разу. Рахувати варто cost per completed task, а не ціну за токен.

Мета замість покрокового скрипту

У тій самій задачі на планування з початку статті є ще один шар, який довелось напрацювати окремо: як формулювати задачу для сильної моделі, щоб вона не перетворилась на покроковий скрипт. Anthropic оформили цей принцип як context engineering: курація того, що потрапляє в контекст моделі, замість детального переліку кроків. Тобто мета, обмеження й потрібна для рішення інформація — зібрані так, щоб модель сама знайшла шлях до результату. Це не суперечить прийому з інваріантами нижче: інваріанти та зчеплені значення теж контекст, обмеження, які модель сама не виведе з коду. Мікроменеджмент — це коли я замість цього розписую кожен крок. Перше лишаю й навіть підсилюю. Друге прибираю з промпту — моя задача описати, куди рухатись і в яких межах, а не якою послідовністю рухів.

Друга половина цього зсуву стосується не мене, а моделі: я хочу, щоб вона питала, коли задача недоспецифікована, а не мовчки вгадувала. OpenAI прямим текстом пишуть про це у власному блозі, пояснюючи свій Model Spec: «it is better to indicate uncertainty or ask for clarification than provide confident information that may be incorrect». Недоспецифікована задача — це норма, а не виняток, і краще, щоб агент проговорив, чого саме не вистачає, ніж підставив правдоподібне, але неправильне припущення — те саме, з чого, по суті, почалась перша частина цієї статті.

Тут варто бути чесним: сама порада «формулюй мету, а не скрипт» не закриває питання, і цифри це показують. Дослідження на кодових агентах (Edwards & Schuster, подано 27 березня 2026, оновлено 3 червня) міряло це напряму. На недоспецифікованій задачі без можливості перепитати Claude Sonnet 4.5 виконує її правильно у 54.80% випадків. Та сама задача з повною специфікацією наперед — 70.80%, розрив у 16 пунктів. А окрема конфігурація агента, яка явно перевіряє недостатність контексту перед тим як діяти (не просто рядок «питай, якщо не ясно» в промпті, а окрема логіка перевірки), піднімає результат лише до 61.20% — це закриває близько 40% розриву, менше половини. Автори пишуть чому: «existing agents are optimized for autonomous completion rather than interactive collaboration». Модель тренована завершувати задачу, а не зупинятись і уточнювати.

Консенсусу тут немає навіть усередині одного вендора. Той самий OpenAI, чий Model Spec радить перепитувати при невизначеності, у GPT-5.2 Prompting Guide для дослідницьких/пошукових задач радить «constrain ambiguity by instruction, not questions», а приклад промпту для deep-research агента з того ж гайду прямо забороняє уточнюючі питання, якщо користувач сам про це не попросив. Два різні сигнали в одному документі: інтерактивний чат, де питання дешеве, і автономний агентний прогін, де кожна зупинка на уточнення зупиняє весь конвеєр. Порада залежить від режиму. І сценарій «нехай просто вгадає» теж не рятує: за даними ACL Findings 2026, моделі вгадують відсутні вимоги правильно у 41.1% випадків, але точність падає, іноді більш ніж на 20%, коли міняється промпт чи сама модель — здогадка нестабільна саме там, де стабільність потрібна найбільше. Індустрія тут не домовилась ні про що. Сама фраза «уточнюй, якщо не ясно» в промпті проблему не закриває — потрібен механізм, а не формулювання.

Механізм, який реально спрацював у цьому ж дослідженні, — інша архітектура, не краще формулювання: multi-agent scaffold, де окремий агент відповідає за уточнення, а окремий за виконання, підняв результат до 69.40%, майже до рівня повної специфікації наперед. Є в тому ж дослідженні і вищий результат — 70.40%, коли агенту наперед прямо сказали, що опис задачі неповний, і зобов’язали спитати, перш ніж діяти. На сильній моделі (Claude Sonnet 4.5) це спрацювало навіть краще за архітектуру. Але на слабшій (Kimi K2.6) той самий прийом обвалюється до 47.20% — модель плутає інструмент для відповіді з інструментом для завершення задачі, — тоді як multi-agent scaffold тримає 69.40% на обох моделях. Тобто жорстко закодована інструкція «спитай» — це ставка на конкретну модель, а окрема задача на уточнення — механізм, який не залежить від того, наскільки добре саме ця модель уміє слухати. Розрив закриває структура, а не вдаліша фраза в промпті — те розділення, з якого я почав цю статтю. Індустрія вже рухається в цей бік практично: xAI з командою /goal у Grok Build (запущено 22 червня 2026), і Claude Code з власною командою /goal реалізують той самий примітив — «мета плюс критерій готовності», перевірений незалежно від думки моделі про власну роботу: тестами, білдом, скріншотом. Spec-Kit від GitHub, який зібрав 111 тисяч зірок до червня 2026, іде схожим шляхом — детермінізм замість вгадування, і цей імпульс по-своєму логічний. Чому я все одно скептично ставлюсь до нього як до готового фреймворка, поясню нижче. Квінтесенція тут проста: критерій готовності мусить бути перевірюваним чимось, що не є думкою моделі про власну роботу. Інакше «мета замість скрипту» — просто інша форма того самого вгадування.

Тімлід чи парне програмування

Усе, що я описав вище — це, по суті, модель «тімліда»: ставлю задачу, AI виконує, я перевіряю. Вона добре масштабується — можна вести кілька задач паралельно, але має зворотний бік: чим більше задач одночасно, тим менше уваги лишається на кожне окреме рев’ю.

Є другий режим, який я вмикаю свідомо: парне програмування, де AI не підлеглий, а рівний партнер — іноді код пишу я, а AI підказує чи рев’ює на льоту, іноді навпаки. Головна відмінність — я не можу вести так більше однієї задачі, тому він гірше масштабується, зате тримає повний контроль над усіма етапами.

На практиці обираю режим під задачу: рутинне — «тімлідом» паралельно, а там де важливо не втратити відчуття коду (нова частина домену, критична ділянка безпеки) тоді свідомо переходжу в парний, навіть якщо повільніше. Є й економічний аргумент: рев’ю AI-коду в підсумку виходить дорожчим за його генерацію тому парний режим цю проблему просто знімає, бо там немає черги на рев’ю, ти й так усе бачиш по ходу.

Інваріанти — у промпті, а не в голові

Друге, що реально працює, це тримати інваріанти в промпті, а не в голові. AI бачить константи в різних файлах як незалежні одна від одної. Тож якщо два значення зчеплені, це треба сказати прямо. Замість «напиши валідацію CSRF-токена» я пишу: «час життя CSRF-токена не може бути меншим за SESSION_LIFETIME = 3600; ці два значення зчеплені: скоротиш одне, зламаєш сесію». Це не моя примха: за дослідженням з конференції FORGE 2025 один лише security-префікс перед промптом зменшував кількість вразливостей аж до 56% (заміряно на GPT-4o і GPT-4o-mini). Той самий принцип працює проти «спрощень», коли модель викидає другий шар захисту як зайвий. RLS на таблиці не скасовує явного WHERE org_id = $current_org, і це треба проговорити, бо для AI happy-path два шари виглядають як дублювання.

Adversarial-перевірка згенерованого

Третій прийом — adversarial-перевірка згенерованого. Після того як код написаний, я перемикаю модель у роль атакувальника: «ти User B з валідною сесією, рядки User A читати не можна, перелічи всі запити й заголовки, якими спробуєш їх дістати, і скажи, які RLS-політики тебе не зупинять» або «запусти саб-агента критика, не передавай поточний контекст сесії, докажи що дана реалізація має прогалини». Так само я ставлюся до сторонніх API як до ворожих: present-but-null — це не те саме, що absent, і модель про це треба питати прямо. Тут працює загальніший принцип, ніж просто безпека: питання «чи все ок з цією реалізацією?», задане тій самій моделі, яка щойно її написала, дає відповідь із вбудованим confirmation bias — вона знайде, чим підтвердити власну роботу, бо саме так сформульоване завдання. Тому формулюю задачу критику не як «підтверди, що працює», а як «рознеси це і скажи, що саме упущено» — атакувальник із прикладу вище це один окремий випадок такої постановки, а не вся вона. Так само ставлю критика на «що зламається в рантаймі при пікових навантаженнях», «які кейси на межі не покриті» чи «яке припущення тут узагалі не проговорене» — форма питання та сама, змінюється тільки фокус атаки.

Одна задача за раз

Ще один принцип, який довелось засвоїти на власних граблях: не заливати одну сесію агента кількома задачами в одному контексті одразу «щоб швидше» — це не те саме, що вести кілька окремих задач паралельно з режиму «тімліда» вище, кожну у своєму контексті. Це не пришвидшення, а гарантований програш у якості. Контекстне вікно деградує задовго до формального ліміту токенів — офіційна документація Claude Code прямо попереджає, що продуктивність падає в міру заповнення контексту, і модель починає «забувати» ранні інструкції. Свіже дослідження на 9374 траєкторіях (квітень 2026, 19 агентів на 500 задачах) підтверджує: навіть топові coding-агенти провалюють понад 20% задач. Практичний висновок простий: одна задача > довести до кінця > коміт > наступна.

Це ще гостріше стає, коли в проєкті не один розробник, а команда з двох і більше людей, і кожен взаємодіє з кодовою базою через власного AI-агента. Дослідження на 33 596 PR від п’яти популярних агентів (Codex, Copilot, Devin, Cursor, Claude Code) показало: конфлікти між PR різних агентів трапляються у 41.7% випадків, тоді як між PR одного й того самого агента — лише у 19.8% (щоправда, самих cross-agent перетинів у вибірці поки менше 1% — сценарій рідкісний, але коли трапляється, боляче). Причина проста: агенти не знають про існування один одного, тож два «чисті» з точки зору git PR можуть незалежно ухвалити несумісні архітектурні рішення, і жоден merge queue цього не зловить, бо він перевіряє git-конфлікти й CI, а не бізнес-логіку. Практичний висновок той самий, що й для одного агента, тільки на рівні команди: чим менший і чіткіше окреслений скоуп задачі, тим менше шансів, що два паралельні AI-потоки в команді наступлять один одному на ноги — і тим частіше варто мержити, а не тримати PR відкритим днями.

Чекліст

Якщо звести до короткого чекліста:

• окрема задача на валідацію вимог до написання коду;
• сильна модель (чи вищий ефорт) на план і перевірку, слабша (нижчий ефорт) на реалізацію;
• мета + критерій готовності замість покрокового скрипту; «спитай, якщо не ясно» — окремим етапом, а не рядком у промпті;
• інваріанти та зчеплені значення явно в промпті;
• після генерації запустити adversarial-прохід: питання не «чи працює?», а «що тут упущено?», особливо це ціно якщо іншою сесією/саб-агентом;
• одна задача за раз — не заливати агента кількома одразу в межах однієї сесії;
• у команді — менший скоуп і частіші мержі, щоб паралельні AI-потоки не наступали одне одному на ноги;
• часті дрібні коміти, щоб не втрачати розуміння власної кодової бази.

CLAUDE.md — карта, а не енциклопедія

І тут є ще один шар, до якого я дійшов не одразу, власне, він і є позитивним контрапунктом до всього написаного вище. Усю цю системну специфіку не обов’язково тримати в голові й повторювати в кожному промпті. Її можна один раз винести у проєктний контекст CLAUDE.md (або AGENTS.md) у корені репозиторію. До речі, у 2026 AGENTS.md став де-факто крос-інструментальним стандартом — його нативно читають Codex, Cursor, Copilot, Antigravity(Gemini) CLI. Claude Code — поки ні (є давній відкритий issue з тисячами голосів), тому практичний патерн, який я тепер використовую: AGENTS.md як основний файл, а CLAUDE.md — тонкий stub з @AGENTS.md-імпортом плюс кілька Claude-специфічних деталей. Тільки це не звалище всіх правил: теоретична стеля такого файлу — пара сотень рядків, а практична ціль набагато нижча (нижче поясню, наскільки), тому я ставлюся до нього як до карти, а не енциклопедії. У ньому зберігається загальний опис проєкту й де що лежить, як зібрати/запустити/протестувати, які неочевидні інструменти в ходу і кілька стартово-критичних особливостей, без яких модель спіткнеться на першому ж кроці. А деталі, конкретні інваріанти на кшталт «час життя CSRF ≥ session lifetime» чи «org_id обов’язковий навіть при RLS», лежать в окремих файлах (docs/, ADR), і CLAUDE.md лише веде до них. Принцип як з онбордингом джуніора без нормального стартового документа: перший раз за разом наступає на ті самі граблі, а з коротким вступом і «детальніше ось тут» — стартує вже з контекстом. Проблеми зменшуються не тому, що модель раптом порозумнішала, а тому, що невидимі системні зв’язки нарешті стали для неї видимими.

Окремо варто згадати функцію пам’яті — це не те саме, що CLAUDE.md. У Claude Code є вбудована auto-memory: агент сам пише собі нотатки (характерні патерни багів, що саме зламалось і чому) у окрему пам’ять проєкту, без мого втручання, і підвантажує їх у наступних сесіях. Це доповнення, не заміна: CLAUDE.md пишу я — це план проєкту, memory пише сам агент — це його робочі нотатки, або коли я явно його прошу якусь думку/підхід запамятати. Така функція вже є в GitHub Copilot і OpenAI Codex; виняток — Cursor, який навпаки прибрав нативну Memories (ще торік) на користь статичних Rules. Раджу просто перевірити, чи є вона у твоєму інструменті, і ввімкнути — це майже завжди дефолтна опція без окремого налаштування. А далі цей документ варто тримати живим. Я роблю щось на кшталт AI-ретроспективи після спринту. Є два варіанти, і обидва робочі. Перший — віддати AI самому розбір: «ось три фікси з цього спринту, які патерни промптів їх спричинили і що варто додати в проєктний контекст, щоб це не повторилось?». Другий, простіший — самому дописати кілька рядків у CLAUDE.md чи в docs/ після кожного нетривіального фіксу. Тут є нюанс, якого мені на початку бракувало: не кожен збій вартий окремого рядка в CLAUDE.md. Одна невдала спроба нічого не доводить — це може бути шум конкретної сесії, а не системна проблема. Тригер, яким я для себе користуюсь, та сама граблина двічі-тричі поспіль: якщо модель наступає на неї вдруге чи втретє в різних сесіях, це вже патерн, і тільки тоді він заслуговує на правило. І тут важливо, що саме робити з цим правилом: не просто дописати ще один рядок унизу файлу, а подивитись, чи не дублює або не суперечить воно тому, що вже написано, і за потреби замінити старе формулювання, а не нарощувати текст зверху. Ефект тут компаундний: з кожним спринтом AI працює краще саме в цьому проєкті, бо вчиться не абстрактно, а на конкретних граблях, на які ви вже наступили. Так «AI як статичний інструмент» поступово перетворюється на «AI, що адаптується до проєкту». І це, мабуть, головне, що я хочу сказати про баланс: неналаштований AI — це програш на дистанції, а налаштований і доглянутий — це compound gain.

Сетап старіє разом із проєктом

І тут важливо не сплутати сетап зі статичним артефактом, який зробив один раз і користуєшся місяцями. Це живий організм: те, чого вистачало на старті грінфілд-проєкту з порожнім CLAUDE.md, вже мало на 50 файлах і зовсім не вистачає на кодовій базі з роками історії. Він змінюється не тільки від знайдених помилок, а й від стадії проєкту, розміру кодової бази і того, які саме задачі ти зараз даєш AI — сетап під великий рефактор відрізняється від сетапу під нову фічу з нуля.

...і разом із моделлю під ним

Досі я говорив про зміни, які йдуть від проєкту — стадія, розмір кодової бази, тип задач. Є друга вісь, яку я довго не бачив: сетап старіє не тільки тому, що росте кодбейза, а тому що під ним із часом міняється сама модель. Anthropic описали це на власному прикладі в постмортемі від 23 квітня 2026: новий системний промпт — з лімітом фінальної відповіді до 100 слів, «якщо задача не вимагає більше деталей» — вийшов разом з Opus 4.7 і зачепив одразу три моделі (Sonnet 4.6, Opus 4.6, Opus 4.7); коли пізніше прогнали ширші евали, знайшли мінус 3% і для Opus 4.6, і для Opus 4.7, і зміну відкотили. Окремий випадок із того ж постмортему: дефолтний reasoning effort знизили з high до medium 4 березня, пішли скарги користувачів на «diminished intelligence», і 7 квітня це теж відкотили. Наслідок для їхнього внутрішнього процесу — тепер кожна зміна системного промпту йде через евали і soak-період перед розкатуванням на всіх. Якщо вендор із власними евалами й телеметрією все одно ловить такі речі постмортемом, то мій CLAUDE.md, який взагалі ніхто не міряє, точно не «просто працює» сам по собі роками.

Контрінтуїтивний наслідок цього — на апгрейді моделі правильний рух це відняти, а не додати. Thariq Shihipar з Anthropic описав це в офіційному дописі від 24 липня 2026: для тодішніх нових моделей, Opus 5 і Fable 5, вони прибрали понад 80% системного промпту Claude Code — і не втратили в якості на власних евалах. Їхня порада після цього: почати знову з малого, орієнтованого на результат промпту, і додавати назад лише те, що евали доводять як справді потрібне — а не переносити накопичене з попередньої моделі за замовчуванням. Застереження там теж є, і його не варто відкидати: скорочені правила не переносяться назад на старі моделі — це порада для конкретного напрямку міграції, а не універсальний рецепт «менше завжди краще».

Механізм, чому старі правила саме шкодять, а не просто марнують місце, описує modemguides.com: інструкції на кшталт «завжди перевіряй ще раз» чи «re-check перед тим як здати», написані під слабшу модель, у новішої спричиняють over-verification — вона й так робить self-verification нативно, а додаткова інструкція змушує робити це двічі. Проблема глибша, ніж здається: «instructions compound rather than override» — нове правило не перекриває старе в контексті моделі, вони накладаються одне на одне, і модель намагається задовольнити обидва одночасно. У файлу немає «строку придатності» для окремого рядка, тому єдиний робочий підхід — старе правило видаляти, коли воно застаріло, а не обкладати його уточненнями зверху. Це той самий принцип, що я описав вище про тригер «двічі-тричі» для нових правил, тільки тепер зрозуміла причина: заміняй, а не дописуй, бо дописане нікуди не дівається й далі диктує моделі поведінку.

Це підкладається під те, що я вже казав вище про CLAUDE.md як карту, а не енциклопедію, і дає цьому конкретну цифру. Дослідження Jaroslawicz et al. (IFScale, 2025) міряло не CLAUDE.md і не кодових агентів, а загальніше — як падає compliance моделі зі зростанням кількості одночасних інструкцій у промпті: чим більше правил модель мусить тримати одночасно, тим менша частка з них реально виконується, і навіть найкращі моделі в дослідженні тримали не більше 68% зі списку в 500 інструкцій. Мораль та сама, навіть якщо дослідження не про CLAUDE.md буквально: пара сотень рядків, про яку я казав вище, — це стеля, а не ціль. На практиці я тепер намагаюсь тримати CLAUDE.md ближче до 30 критичних рядків, а не наближатись до двохсот, а решту enforcement — типи, лінтери, CI-перевірки — переносити в hooks і pipeline, а не в текст, який модель має щоразу заново пригадувати.

Це не лише теорія — те саме видно й у полі. У GitHub issue #57200 в репозиторії anthropics/claude-code (8 травня 2026) користувачі описують типову картину: власний rules-файл, який раніше стабільно відпрацьовував, посеред сесії просто перестає братись до уваги, і «стало помітно гірше за останній місяць», а хронологія скарг збігається не зі зміною файлу, а зі зміною моделі під капотом. Типовий симптом саме такий: «раніше слухалось, тепер ні» — і перше місце, куди варто дивитись у такому разі, це не власний файл, а те, яка модель зараз під ним працює.

Найточніше це сформулював Sascha Corti у статті на corti.com «Your Prompts Are Technical Debt» (28 липня 2026): «a model upgrade is a migration, not a config change» — апгрейд моделі це міграція, а не зміна конфігу. Промпт у продакшені — це контракт, який анулюється при зміні моделі, навіть якщо жодне слово в ньому не змінилось. У кількох джерелах паралельно вживають для цього різні терміни — «prompt drift», «prompt rot», «model migration debt», але суть та сама: конфіг, який мовчки старіє під моделлю, а не разом із нею.

Задокументованої рекомендованої каденсії такої ревізії не існує, принаймні я не знайшов нікого, хто б це формалізував. На практиці це радше event-driven процес: справжній тригер — не календар, а подія. Вийшла нова версія моделі, на якій я працюю, сідаю й перечитую конфіг заново; та сама граблина, описана вище, спрацювала двічі-тричі — теж тригер, тільки зсередини проєкту, а не ззовні. А якщо потрібен якийсь орієнтир у часі для самодисципліни — у мене це моя власна евристика, не результат дослідження: раз на 3-6 місяців я все одно сідаю й перечитую весь файл цілком, навіть якщо жодної події не було.

Для себе я тримаю CLAUDE.md, AGENTS.md і settings у git не менш дбайливо, ніж сам код, і сюди ж варто додати кастомні skills, system prompts, hooks-конфіги, правила субагентів, якщо вони встигли накопичитись: усе це господарство старіє за тим самим механізмом і потребує тієї самої ревізії. Коли переписав файл під нову модель і стало гірше, а не краще, просто відкочуюсь до версії, яка реально давала результат, замість того щоб латати поверх. Сама Anthropic у 2026 відкочувалась так двічі і промпт під Opus 4.7, і дефолтний reasoning effort, тож ревізія конфігу це експеримент, а в експерименту завжди мусить бути шлях назад.

Обидві причини і те, що сетап тягнеться за стадією проєкту, і те, що модель під ним із часом змінюється, разом пояснюють, чому я скептично ставлюсь до важких «під ключ» spec-driven фреймворків (Spec-Kit, BMAD-method і подібні): навіть вони, за відгуками спільноти останніх місяців, натикаються на той самий недетермінізм — що спрацювало вчора, не спрацьовує сьогодні, і без живого циклу «зроби > побач де зламалось > зафіксуй» жоден жорсткий процес, хай який детальний наперед, цього не вирішує.

А що з твоїми власними навичками?

І тут варто бути чесним із собою: усе, що я описав — CLAUDE.md, ретроспективи, делегування планування сильній моделі — робить AI ефективнішим. Воно нічого не робить для того, щоб ти сам залишався ефективним без AI, а це різні задачі.

Механізм простий і трохи неприємний: коли прикидаєш, що написати щось руками — це години чи дні, а AI зробить те саме за годину, мотивація писати самому природно зникає. Проблема не в лінощах — це раціональний вибір у моменті з нераціональною ціною в перспективі кількох місяців: швидкість писати й дебажити код руками: навичка, яка просідає без практики так само, як будь-яка інша.

Другий симптом — рев’ю, що вихолощується з часом: перший-другий раз вчитуєшся уважно, а на п’ятому це вже формальний апрув. Розмір фрагмента ролі не грає, а коротший AI-код читати не легше, ніж довгий, якщо він не твій.

Що я з цим роблю практично: тримаюсь вибору режиму, який описав вище — парний саме для нового й критичного, а не тільки як спосіб зекономити на рев’ю; окремо, періодично і без AI, пишу чи дебажу щось руками — не тому що так швидше, а щоб рука не забула; і коли ловлю себе на «апрув та й все» — це сигнал зупинитись, а не показник, що код став простішим.

Чесна відповідь на «AI руйнує навички розробника?» — так, якщо користуватись бездумно і завжди в режимі повного делегування. Але це керований ризик: він залежить від того, скільки свідомого зусилля лишаєш собі, а не тільки AI.

Або тут варто вже піднімати кардинальне інше питання, яке диктує бізнес, що з приходом АІ відбувається завершення ери мануального написання коду. Дану тему спробую розкрити в наступних публікаціях.

До речі, те, що я описав вище — CLAUDE.md/AGENTS.md, вибір моделі й ефорту, пам’ять проєкту — це вже базовий рівень «harness engineering» (в індустрії прижилась формула agent = model + harness, і сама Anthropic активно оперує терміном harness у своїх інженерних постах). Просунутий рівень — subagents, кастомні skills, MCP-екосистема, системні промти під конкретний процес — свідомо не йду туди в цій статті: це теж спокуса «зробити один раз під ключ», а поки не напрацьована базова ітеративна звичка, ускладнювати харнес немає сенсу. Про це — окремо і пізніше.

Підсумок

Якщо звести все докупи, то для мене висновок такий: справа не в назві «vibe coding», «agentic engineering» чи ще в чомусь, і не в тому, хто фізично набирає код. Шість кейсів із першої частини і всі прийоми, які я описав тут, мають один корінь: AI чудово закриває локальну, видиму задачу, але системний контекст, зв’язки між компонентами, інваріанти безпеки, поведінка в рантаймі залишаються на людині. Той, хто тримає цей системний погляд, отримує від AI швидкість. Той, хто очікує, що AI вивів ці інваріанти сам, рано чи пізно знаходить їх на staging або під час аудиту.

Simon Willison (один із творців Django) сформулював хороший практичний підхід: «Якщо AI написав код, а ти його переглянув, ретельно протестував і можеш пояснити комусь іншому, як він працює, — це не vibe coding, це розробка програмного забезпечення.» Різниця не в тому, хто пише код. Різниця в тому, хто відповідає за розуміння.