Vibe coding — практика описати, чого хочеш, і дати ШІ згенерувати реалізацію — реальна й продуктивна. Це також надійний спосіб накопичувати техборг зі швидкістю ШІ, якщо ставитися до ШІ як до заміни інженерної дисципліни, а не її прискорювача.
Проблема не в ШІ. Проблема в тому, що звички, які роблять написаний вручну код підтримуваним, не застосовуються самі собою лише тому, що ви перейшли на код за промптами.
YAGNI досі діє
Моделі ШІ навчені бути корисними. Коли ви просите систему автентифікації користувачів, корисна модель часто дасть вам автентифікацію плюс скидання пароля, плюс керування сесіями, плюс адмін-флаг у моделі користувача, плюс верифікацію email — бо ці речі часто йдуть разом, а модель патерн-матчить на кодових базах, де це так.
Це порушення YAGNI на швидкості генерації. Ви не просили цих речей, вони вам поки не потрібні, а тепер вони у вашій кодовій базі й вимагають підтримки, тестування й прийняття рішень.
Виправлення — конкретність у промптах. “Реалізуй JWT-автентифікацію — лише middleware, що валідує токен і встановлює значення контексту, більше нічого” дає драматично інший результат, ніж “реалізуй автентифікацію”.
Специфікація перед кодом
Найпродуктивніше використання ШІ в розробці — не просити його з’ясувати, що будувати. А просити побудувати те, що ви вже з’ясували самі. Це означає спершу писати специфікацію.
Специфікація не мусить бути витонченою. Для однієї задачі це можуть бути чотири пункти:
- Прийняти тіло POST /webhooks/stripe
- Валідувати заголовок Stripe-Signature, використовуючи STRIPE_WEBHOOK_SECRET з env
- На payment_intent.succeeded викликати OrderService.MarkPaid(paymentIntentID)
- Повернути 200 при успіху, 400 при невалідному підписі, 500 при внутрішній помилці
Ця специфікація обмежує ШІ тим, що вам справді потрібно. Без неї модель робитиме вибір — щодо обробки помилок, щодо того, що логувати, щодо того, чи додавати чергу повторів — і частина цього вибору буде неправильною для вашого контексту.
Рев’ю досі важливе
Вивід ШІ вимагає того ж рівня прискіпливості код-рев’ю, що й вивід джуніор-розробника. ШІ не знає ваших конвенцій, вашої моделі безпеки чи того, що ви вирішили минулого спринту. Він знає типові патерни, а це не те саме.
На що конкретно варто дивитися в коді, згенерованому ШІ:
- Вигадані абстракції. Функція, яка мала повертати користувача, натомість повертає тип результату з трьома полями, два з яких ви не просили, а одне затінює ім’я в зовнішньому скоупі.
- Непослідовна обробка помилок. Щасливий шлях у порядку; ШІ часто “втомлюється” від обробки помилок і використовує інший патерн для третього випадку помилки.
- Відсутня валідація вводу. ШІ валідує вводи, що з’являються в його тренувальних даних для подібних функцій. Він пропускає валідацію для вводів, що здаються “внутрішніми” для застосунку.
- Тихі режими відмови. Горутини, що панікують без recovery, канали, що можуть deadlock-нутись, контексти, які не проброшені далі.
Патерн субагента
Одна довга розмова з ШІ — це пастка. Контекстне вікно моделі заповнюється попередніми рішеннями, і подальші виводи неявно обмежені ними — включно з поганими рішеннями, ухваленими рано й ніколи не виправленими.
Патерн субагента: одна задача, один свіжий контекст, одне рев’ю. Ізолюйте кожну задачу у фокусований промпт, що містить усе, що ШІ потрібно, і нічого зайвого. Це дає передбачуваніший вивід і полегшує рев’ю, бо скоуп обмежений.
На практиці це означає використання git worktree на кожну задачу і виклик нової сесії Claude Code на кожен worktree. Накладні витрати низькі; виграш у передбачуваності — значний.
Коли не використовувати ШІ
Є категорії коду, де допомога ШІ активно шкідлива:
Код, чутливий до безпеки. Потоки автентифікації, криптографічні операції, перевірки контролю доступу. Тут треба з першого разу зробити точно правильну річ. ШІ видасть код, що виглядає правдоподібно, але має тонкі вади — атаки за таймінгом, відсутню валідацію в граничних випадках, неправильне використання криптопримітиву. Прочитайте специфікацію, реалізуйте самі, дайте другій людині перевірити.
Нові алгоритми. Якщо алгоритм, який вам потрібен, не існує в поширеній формі в тренувальних даних ШІ, модель наблизить його чимось, що виглядає схоже, але не є правильним. Це найгірший режим відмови: код, що виглядає правильним, проходить очевидні тести й падає в проді на граничних випадках.
Логіка регуляторної відповідності. Розрахунки податків, реалізація права на видалення за GDPR, правила фінансового округлення. Наслідки помилки тут — не сесія дебагінгу, а юридична чи фінансова відповідальність. Зрозумійте специфікацію самі.
ШІ — справжній помножувач продуктивності для переважної більшості рутинної роботи з імплементації. Дисципліна — знати, які частини не рутинні.