Нам потрібно перестати називати все «віб‑кодингом»

Я повернувся до програмування після тривалої перерви, і Lovable став місцем, де я знову взявся за це. Додатки виглядали чудово, працювали на перший погляд і збиралися за кілька годин. Спочатку це здавалося надзвичайним. Але це перестало бути достатньо, коли я захотів зрозуміти, що робить код – і чому. Тоді мій підхід почав змінюватися.

Різниця не в інструменті чи в тому, скільки коду ШІ пише за вас. Справа в контракті, який ви приймаєте зі своїм результатом: чи можете ви пояснити, що саме випустили у світ, чи ні.

«Віб‑кодинг» у первісному сенсі означає прийняття програмного забезпечення, згенерованого ШІ, без належного вивчення чи розуміння того, що лежить під ним. Розробка за допомогою ШІ інша. Модель може й надалі писати більшість коду, проте особа, що створює систему, залишається відповідальною за розуміння її поведінки, тестування припущень і вирішення, чи готово вона до випуску.

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

Як «віб‑кодинг» втратив своє значення

Термін «віб‑кодинг» був введений у лютому 2025 року Андрієм Карпаті, співзасновником OpenAI. Його приклад був навмисно неформальним: «одноразовий проєкт на вихідних», створений автоматичним натисканням «Accept All», ігноруючи різниці та дозволяючи коду розростатися поза його розумінням.

Через кілька тижнів розробник і творець інструментів Саймон Віллісон помітив, що термін використовується зовсім інакше: як синонім будь‑якого програмування за допомогою ШІ, що, на його думку, розбавляє термін і створює хибне уявлення про те, чого може досягти відповідальна розробка за підтримки ШІ.

Цікавим є те, що Карпаті зрештою погодився. Через рік він запропонував інший термін для більш дисциплінованої роботи з кодуючими агентами. Він описав «агентську інженерію» як робочий процес, у якому розробники керують і контролюють агентів, а не просто приймають їхній результат. Різниця важлива: професійна розробка за підтримки ШІ вимагає планування, ретельної перевірки та підзвітності, чого не передбачає випадковий віб‑кодинг.

Лінія – це відповідальність

Правило Віллісона просте, і воно служить тестом для будь‑кого: не вносьте код, який не можете пояснити іншій людині. Це не означає читати кожен рядок: коли агенти генерують сотні рядків одночасно, навіть досвідчені розробники вже так не роблять. Це означає розуміти основну логіку і вміти обґрунтувати, чому код робить саме те, що він робить. Якщо ви можете, не важливо, чи його написала модель, чи ви: це не віб‑кодинг, а використання інструмента для створення програмного забезпечення.

Дослідження, опубліковане в грудні 2025 року, підтверджує цю різницю. Спираючись на польові спостереження та якісне опитування професійних розробників, дослідники виявили, що досвідчені практики зберігали контроль над проєктуванням та реалізацією ПЗ, а не передавали весь процес ШІ. Вони розглядали агентів як співробітників, ретельно планували свою роботу та залишалися залученими до контролю.

Отже, лише досвід це не пояснює. Справа в тому, чи готові ви взяти на себе відповідальність за те, що згенерував ШІ. Це рішення кожен розробник приймає знову і знову в кожному проєкті.

Що трапляється, коли контроль відсутній

Наслідки випуску програмного забезпечення без розуміння чи перевірки його безпеки не є абстрактними. Tea, додаток, створений для допомоги жінкам залишатися в безпеці під час знайомств, викрив десятки тисяч фотографій документів та понад мільйон приватних повідомлень у двох інцидентах безпеки. Помилки включали незахищений сховищний бак та окрему базу даних, доступну без автентифікації.

Той самий фундаментальний проблем – програмне забезпечення здавалось працюючим, хоча логіка авторизації була небезпечно неправильною – з’явився в застосунку, створеному на платформі Lovable: дослідження безпеки виявило інвертовану логіку авторизації, що блокувала зареєстрованих користувачів, дозволяючи неавтентифікованим зловмисникам вільно входити, зачепивши понад 18 000 користувачів, включаючи студентів.

Це не окремі випадки, що трапляються лише в «поганих» проєктах. За звітм Google DORA 2025 року, 90 % розробників зараз використовують ШІ у роботі, тоді як приблизно третина повідомляє про низький або відсутній рівень довіри до того, що він генерує.

Використання ШІ тепер поширене, хоча довіра залишилась обмеженою. І саме тому ретельна перевірка особливо важлива, коли згенерований код обробляє автентифікацію, дозволи чи конфіденційні дані.

Контроль будується шарами, а не одразу

У моєму випадку я не починав із формального аудиту безпеки. Я просто відмовлявся продовжувати, коли не міг пояснити, чому щось поводиться так, як воно поводиться – це природний інстинкт, який я застосовую в роботі аналітика. Мене менш турбує синтаксис, ніж те, чи відповідає результат тому, що нам спочатку потрібно було. Якщо ні, я продовжую копати.

Мій робочий процес став більш структурованим, коли проєкти ставали серйознішими. Замість того, щоб покладатися лише на підказки, я почав готувати специфікації перед генерацією будь‑чого. Я задокументував бізнес‑вимоги, технологічний стек і інтеграції. Потім з’явилися юніт‑тести та тести Playwright для основних користувацьких сценаріїв.

Перевірки безпеки додавались подібним чином. Я переглянув бібліотеки, які обрав ШІ, і впровадив сканування на шкідливе ПЗ для завантажених файлів. Кожна перевірка виникала з питання, що може піти не так далі, а не з дотримання заздалегідь підготовленого списку контролю.

Ця звичка виявила проблему в одному проєкті. ШІ додав бібліотеку, несумісну з версією фреймворку, яку я використовував. Додаток не зламався одразу, тому несумісність могла залишитися непоміченою. Виявлення її пізніше ускладнило б визначення причини.

У порівнянні з випадками Tea та Lovable, це була звичайна проблема. Я виявив її рано, виправив і продовжив роботу. Це те, як виглядає перевірка на практиці. У більшості випадків це запобігає перетворенню малих проблем у великі.

Я не підозрюю код лише через те, що його створив ШІ. Я також не довіряю йому лише тому, що додаток працює. Тести та перевірка – це те, як я встановлюю, чи поводиться він згідно з намірами.

Від віб‑кодингу до агентської інженерії

Відхід Карпаті від «віб‑кодингу» до «агентської інженерії» – це не лише зміна словника. «Агентська інженерія» дає нам більш корисну назву для напрямку, у якому розвивається професійна розробка. Розробники можуть писати менше рядків самостійно, але це не зменшує їхньої відповідальності. Це зсуває їхню роботу у бік визначення того, що система має робити, керування агентами, тестування їхнього результату та вирішення, що безпечно випускати.

Небезпека не в тому, що ШІ швидко генерує код.Вона в тому, що генерація може випереджати розуміння. Коли це відбувається, очевидна продуктивність приховує ризики, які ніхто не досліджував належним чином.

Правило, яке варто зберегти

Припиніть використовувати «віб‑кодинг» як мітку для будь‑якої форми розробки за допомогою ШІ – це розбавляє термін і стирає важливу різницю у контролі. Встановіть просте правило: не випускайте те, що не можете пояснити. І впроваджуйте контроль у проєкт по мірі його зростання, шар за шаром, додаючи перевірки у відповідності до виникаючих ризиків.

ШІ може писати більшість коду. Він не може нести відповідальність за його випуск. Це все ще належить нам.