Вайбкодинг: чому всі про нього говорять і коли він справді потрібен

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

Вайбкодинг уже просочився в ІТ-вакансії та в культуру програмування. Тому ми розібрали, що таке вайбкодинг і коли він корисний для розробника, як і для чого вайбкодять українські айтівці та які речі поки не варто довіряти LLM. А ще додали поради для успішного вайбкодингу від українських IT-експертів.

Серед них:

Що таке «вайбкодинг»

Термін «вайбкодинг» завірусився після твіту співзасновника Open AI Андрея Карпати. Ще 2023-го він зазначав, що «нова найпопулярніша мова програмування — англійська». А у лютому цього року розповів про «новий тип програмування» за допомогою ШІ. Його основна думка — LLM настільки розвинулась, що програміст може «віддатися вайбу» і взагалі забути про існування коду.

Андрей Карпати наголосив, що такий спосіб підійде для одноразових проєктів «на вихідні», і називати це програмуванням уже не можна. Це підхід, коли ШІ не асистує — він фактично ведучий розробник, а людина задає тон і напрям.

Твіт зібрав понад 5 мільйонів переглядів і спричинив дискусію про те, як програмування «на вайбі» впливає на якість коду й роботу розробників. А головне: чи здатен ШІ створити надійний код, який працюватиме так само добре, як створений людиною.

Як вайбкодинг допомагає розробникам

Вайбкодинг став можливим завдяки розвитку локальних і хмарних великих мовних моделей, зокрема Cursor (на базі Claude або GPT), GitHub Copilot або Replit Ghostwriter. Під впливом ШІ почалася глибока трансформація розробки програмного забезпечення. Тепер розробник може довіритися ШІ й працювати інтуїтивно.

Втім, як відзначає MIT Technology Review, не вся робота з ШІ вважається вайбкодингом. Щоби бути вайбкодером, треба повністю передати контроль ШІ-асистенту. Тож цей підхід найкраще підходить:

  • досвідченим розробникам, які можуть допрацювати код за потреби;
  • абсолютним новачкам, які мають ідеї, але не мають технічних навичок програмування.

Експерти описують вайбкодинг як інструмент для швидкого прототипування та перевірки ідей, з яким не треба думати про якість коду. CEO DevRain Олександр Краковецький розглядає його як продовження традиційних практик скафолдингу (швидке створення шаблонного коду або структури проєкту, — ред.) і бутстрепінгу (запуск системи або процесу з нуля без зовнішньої допомоги, — ред.), що зараз значно пришвидшились завдяки LLM.

«Саме тому цей підхід насамперед опанують стартапи. Тепер PoC можна не розробляти з нуля, а згенерувати — і не витрачати $20–100 тисяч на реалізацію. Ще один варіант — це проєкти, за які зазвичай ніхто б не взявся. Організації без великих бюджетів нарешті отримують шанс реалізувати власні ідеї та задовольнити потреби», — пояснює експерт.

Machine Learning Engineer в Universe Group Павло Лисий наводить приклади, коли вайбкодинг може стати корисним для розробника:

  • Для прототипування, коли треба швидко перевірити ідею або зробити мінімальний робочий продукт (MVP).
  • У дослідницькій роботі — наприклад, коли вивчаєш новий алгоритм або хочеш швидко перевірити, чи твій спосіб розв’язання задачі працює.
  • У межах хакатонів — коли мало часу і потрібно швидко зробити щось робоче.
  • Після інсайту — коли несподівано прийшла ідея, і її треба швидко записати, поки не забув.
  • У навчанні або дослідженнях — коли експериментуєш з новими технологіями, граєшся з алгоритмами, щоб краще їх зрозуміти.
  • Для побудови особистих інструментів і скриптів — наприклад, прості програми чи автоматизації, які хочеш зробити швидко; можливо, вони не ідеальні, але працюють.

Сам вайбкодинг — це не заміна розробки, але він виконує ті завдання, від яких розробники часто відмовляються, додає CBBO в ЛУН Денис Суділковський:

«Розробка дорога і вимагає чітких очікувань, а коли їх немає — треба експериментувати. Вайбкодинг допомагає швидко створювати перші робочі версії, які не підходять для масштабів чи стабільності, але добре перевіряють гіпотези на ринку. Це робить R&D більш прикладним і виводить його з лабораторії у реальний світ».

Senior Software Engineer в DataRobot Сергій Бабіч жорстко критикує вайбкодинг як явище, водночас наполягає, що вміння працювати з інструментами кодогенерації — це необхідність, особливо для тих, хто тільки входить у професію:


«Я вважаю, що зараз людина, яка не користується інструментами кодогенерації, свідомо стріляє собі в ногу. Головне, щоб код вирішував задачу. Що краще і швидше — то ліпше».

Він додає, що вайбкодинг дозволяє за лічені хвилини згенерувати основу, підставити потрібні параметри та інтеграції і швидко перейти до роботи. Тобто пройти ті процеси, де розробник зазвичай втрачає мотивацію.

«Для мене вайбкодинг — це просто сів, сказав „зроби мені класно“, і чекаєш, що воно зробить класно. Це вже не про вайб, а про системний підхід до кодогенерації».

Head of AI в MacPaw Володимир Кубицький додає: те, що раніше займало тиждень, тепер можна зробити за кілька годин — отримати перші версії й побачити, як усе працює.

«І йдеться не про макет у Figma, а про справжній веб-інтерфейс, з яким можна взаємодіяти. У цій фазі ще не потрібен ідеальний код — важливо швидко перевірити напрям. Натомість для багфіксів вайбкодинг я б не радив: коли система вже стабільна, потрібна точність, а не імпровізація. Інакше є ризик скотитися у „вайб-дебагінг“ — а це займе ще більше часу».

Кодогенерація: досвід українських IT-фахівців

Артур Шевченко, Director of Engineering в Yalantis, наголошує, що вайбкодинг справді підходить для швидкого прототипування ідей, але не для продакшену чи масштабованого R&D. Цю думку він пояснив на власному досвіді кодогенерації:

«Це була функція для R&D в одному з проєктів. Хотів перевірити нову ідею і свідомо почав наосліп — без детального дослідження, просто „на вайбі“ з підтримкою ШІ, радіючи експерименту.


Що сподобалося:

  • Швидкий старт — згенерував код, і щось уже працює.
  • Було весело, драйвово, цікаво.

Що пішло не так:

  • Під капотом усе було нестабільно — невелика кастомізація призводила до поломок..
  • Код став некерованим і обріс „костилями“.
  • Довелося викинути його й переписати з нуля — уже за документацією та з чітким розумінням».

Денис Суділковський з ЛУН, навпаки, зміг автоматизувати рутинні завдання в команді завдяки вайбкодингу, зокрема управління файлами, розподіл та аналіз. Крім того, створив сервіс Mapa.com.ua, що показує напрям ракет і дронів під час повітряних атак:

«Під час обстрілів я читаю телеграм-канали, але не завжди знаю, де саме розташовані згадані села. Тож зробив сервіс, який читає ці канали, аналізує повідомлення і показує все на мапі — це дуже зручно. Крім того, використовую штучний інтелект для створення складніших інструментів для аналізу даних — це все для внутрішніх потреб», — ділиться фахівець.

Сергій Бабіч практикував кодогенерацію для кількох особистих ідей. Одна з них: інструмент для швидкого обміну контактами на конференціях, без реєстрації й акаунтів, на відміну від наявних сервісів. Цей підхід допомагає йому у вирішенні й інших особистих завдань:

«Наприклад, мені треба було порахувати кількість дощок для ящика, і я швидко зробив це за допомогою генератора коду, а потім видалив. Це значно швидше, ніж шукати формули чи рахувати вручну», — ділиться Бабіч.

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

«AI-частину залишили собі, решту генерували на ходу — швидко й на драйві. У підсумку вийшов робочий прототип, який ми змогли показати в дії. І саме тоді я на практиці побачив, наскільки різна якість у ChatGPT, Claude та Cursor саме для коду. Досі я переважно використовував ChatGPT у менеджерських задачах і думав, що у коді він такий самий. Виявилось, що Claude та Cursor справляються значно краще, коли йдеться саме про вайбкодинг», — ділиться експерт.

Як вайбкодинг впливає на якість продукту

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

LLM ще не кодить так, як досвідчені інженери, але здебільшого ідеального коду не потрібно, каже Олександр Краковецький:

«Якість — це не тільки те, що описував Роберт Мартін у „Чистому коді“. Значно важливішими стали архітектура системи, якість даних, поєднання інструментів і, головне, наскільки код реально розв’язує бізнес-завдання», — доповнює співрозмовник.

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

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

Артур Шевченко додає, що без належного контролю і досвіду вайбкодинг створює більше проблем, ніж рішень:

  • Код виходить нестабільним і ламким.
  • Погано читається, що ускладнює підтримку.
  • Тестування та налагодження коду ускладнені.
  • Часто порушуються найкращі практики програмування, що призводить до технічного боргу.

Переписувати або рефакторити великі шматки коду LLM поки що вміє слабко. Часто легше дописати вручну через автодоповнення, ніж змушувати ШІ все перероблювати, ділиться Сергій Бабіч. За його словами, вдаватися до вайбкодингу можна, коли потрібно щось «зліпити на коліні», однак код потрібно перевіряти:

«Заради досвіду я вирішив пройти співбесіду, й мені дали технічне завдання на півтори години — „роби як хочеш“. Було абсолютно нормально використати ШІ — я так і зробив. Згенерував код, усе працювало, і ми обговорювали його з інтерв’юерами. Вони зачепилися за один шматок, і я на ньому „посипався“ — не тому, що не розумів, а через брак практики саме в цьому аспекті», — розповідає експерт.

Як впроваджують вайбкодинг в українських IT-компаніях

Експерти наголошують, що впроваджують елементи вайбкодингу в R&D чи експериментах, однак не всі дозволяють вайбкодити на етапі продакшену.

«У нашій команді вайбкодинг сприймають з гумором, але й з повагою. Часто звучить як мем — „я вайбкодив до третьої ночі“, але всі розуміють, що за цим стоїть реальна цінність: швидкість, інтуїція, гнучкість, робота поза Jira. У нас чітке правило: вайбкодинг — для прототипів, R&D, перших ітерацій. Коли йдеться про продакшен — вмикаються стандарти, код-рев’ю, документація», — ділиться Павло Лисий.

У команді Дениса Суділковського «магію» вайбкодингу розробники сприймають як додатковий інструмент. А для нетехнічних або напівтехнічних фахівців відкриваються нові можливості, зокрема у сфері глибокої аналітики, де раніше потрібно було писати складні запити на R чи Python.

Сергій Бабіч використовує ШІ як підсилювач — наприклад, автокомпліт у Cursor, який розуміє контекст кількох файлів.

«У нас складна внутрішня логіка, власна дизайн-система, структура — ШІ просто не впорається. Іноді навіть на рівні tab complition видає повну нісенітницю. Якщо говорити про нові ідеї чи MVP, тоді так — три години, і в тебе є робочий прототип. Але чим складніший проєкт, тим гірше AI справляється. У великому легасі-коді він „ламається“, не бачить частину контексту, плутає імпорти, вигадує пропси, не може знайти референси», — ділиться експерт.

Як ШІ змінює роль інженерів і впливає на вимоги роботодавців

CEO Y Combinator Гаррі Тан стверджує, що завдяки вайбкодингу стартапи можуть досягати продуктивності, яка раніше вимагала команд у 50-100 інженерів. За його словами, 10 фахівців, які активно використовують LLM, можуть створювати повноцінні продукти, що раніше були під силу лише великим компаніям.

«Коли люди дуже добре використовують найсучасніші інструменти генерування коду, такі як Cursor або Windsurf, вони можуть зробити роботу 10 чи навіть 100 інженерів за один день», — зазначив Гаррі Тан.

Деякі компанії, як-от Visa, Reddit, DoorDash, Snyk зараз зазначають досвід роботи з вайбкодингом як «обов’язковий» (non-negotiable) або «не менш ніж 50% коду має генеруватися ШІ».

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

«Це може виглядати як rapid prototyping skills. Особливо в стартапах або дослідницьких командах. Не називатиметься „вайбкодинг“ офіційно, але суть та сама — швидко діяти, швидко тестувати, не боятися відкидати хибні ідеї й просувати робочі».

У короткостроковій перспективі навичка вайбкодингу вже відрізняє кандидатів, готових до змін, вважає Денис Суділковський:

«Є ті, кому справді важливі інновації. Вони вже шукають людей, які вміють працювати з новими інструментами, експериментувати, мислити гнучко».

Водночас він скептично ставиться до довготривалої перспективи «вайбкодингу як вимоги». На думку експерта, технології розвиваються до зниження вимог до користувача. Тож «супернавички промптингу» можуть виявитися тимчасовим феноменом:

«Я не вірю, що промпт-інженіринг стане максимально популярним. ШІ йде до розуміння поганої людської мови. Так буде і з вайбкодингом. З’являться інструменти, де експертиза користувача буде менш потрібна, а якість результату — вища».

Водночас LLM не можуть замінити розробників: налагодження коду, виправлення багів, безпека все ще потребують участі фахівця.

Наостанок експерти закликають айтівців експериментувати, опановувати генеративний ШІ, вивчати промпт-інженерію й ретельно перевіряти згенеровані результати.

А чи був досвід вайбкодингу у вас? Яким був процес і результат? Діліться у коментарях👇

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному5
LinkedIn



37 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
створив сервіс, який показує напрям ракет і дронів під час обстрілів.
Під час обстрілів я читаю телеграм-канали

ясна, панятна...

Кодогенерація, та в цілому моделі як чат гопоти — це як тіма девов з Індії.
Слухють уважно, роблять швидко, воно працює на виході.

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

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

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

Через декілька років нас очікує покоління девів, які без ШІ не зможуть навіть хело ворлд наваяти самостійно. Це, на справді, вже реальна проблема.

Для мене він доречний, коли проекти не серйозні, а більше для приколу, щось зробити на вечір. А в іншому деградація професійних навичок. (Моя думка🙃)

ChatGpt повністю закриває потреби мого pet-проекту в JavaScript та CSS.
Але той Java код, за який мені платять гроші, він не напише.
ШІ — чудовий інструмент, якщо не очікувати від нього чогось надзвичайного.

Але той Java код, за який мені платять гроші, він не напише.

Чому це?

Напишіть примітивний реактивний фреймворк за допомогою вайбкодінгу.

Для чого писати фреймворк? Мені за таке не платять на роботі

Щоб перевірити тезу, який код напише людина але поки не ШІ.

По роботі мені мені дуже рідко доводиться писати простий код. Хіба що відсотків 5 часу. Тому ШІ тут мені практично нічого не заощадить.
Решта 95 відсотків часу — аналіз складних багів, що виникають при взаємодії різних мікросервісів. Треба багато думати та читати логи. ШІ я пробував, взагалі ніяк не допомагає в цій ситуації.
ШІ може робити більшість роботи джуна і частину роботи мідла. А те, для чого наймають сейньйорів, зазвичай надто складне.

Не бачу причини чому ШІ не може проаналізувати окремі логи, комбінувати логи з різних мікросервісів і скласти все докупи або через timestamp або correlation id/trace id. Особливо якщо йому надати код який ці логи генерує, додати додаткові debug logs якщо йому чогось не вистачає і не завайбкодити можливе рішення з одночасним оновленням unit та integration tests.

Аналіз логів то одне. А накидати новий мікросервіс вайбкодінгом — взагалі не бачу проблеми. Не розумію в чому проблема даного коментатора :)

Накидати новий мікросервіс — на моєму проєкті, де все 300+ мікросервісів, таке відбувається кілька разів на рік і триває 3-4 тижні, це примітивна робота, з якою ШІ чудово допомагає, але й часу вона заощаджує дуже мало, бо я й без ШІ цей код приблизно за той самий час напишу. А далі — тривала підтримка, пошук проблем, допилювання, в якому ШІ мало чим допомагає.

Почнемо по новій

Але той Java код, за який мені платять гроші, він не напише.

То виходить ти код толком то і не пишеш, але на вайбкодінг вирішив наїхати?🤦‍♂️

З чого ти взяв, що я не пишу код?
PS про вайббкодинг пишеш ти. Я про нього взагалі нічого не казав.

Проаналізувати може — не може здогадатися, що не так і з яким саме сервісом.

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

Я користуюся ШІ щодня багато разів на день, і бачу, що він може, а що не може.

Воно може писати досить складний код, але треба завантажити контекст. Результат все ще потребує допрацювання, але це набагато шивдше аніж писати із нуля. Якщо mcp налаштовані «як потрібно», то ви можете йому демонструвати ваші допрацювання щоб наступного разу він генерував кращій код. Спробуйте mcp із векторною базою (у докері), та глобальні інструкції оновлювати її після кодної виконаної таски.

Решта 95 відсотків часу — аналіз складних багів, що виникають при взаємодії різних мікросервісів.

Підозрюю що у 95% випадків це проблема не коду, а дизайну системи.

Тому яким боком тут вайбкодінг я не дуже розумію.

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

Я не справжній «сварщик», але маю досить позитивний досвід від Cursor. Зробив за його допомогою дашборд для HubSpot CRM API під свої вимоги, та продовжую покращувати. Next, React, тести. Головне розуміти шо треба та як то перекласти в слова промта). Мене здивувала швидкість та якість того шо на виході. До цього пробував робити то саме за допомогою чата гпт з платною підпискою, але результат був не дуже.

Хто прийшов почитати коменти — не забудьте скинути донат на Третю штурмову.

ну тут добре підійде фраза з фільму «Області темряви» (ну той де Бредлі Купер закидався таблами, які бустили інтелект) — «.. ця штука працює на порядок краще, якщо з самого початку шариш в цій тємі».

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

просто ви ще не пробували Claude Code 😉

люди поділяться на 2 типу, одні — в кого получилось з першого разу згенерувати шось робоче, а потім з часом все поламалось, другі — в кого не получилось з самого початку і вони одразу забракували.
Хоча в реальності — це дуже крута штука, хоча і зі своїми бзіками як старий вередливий програміст, який хоче робити тільки те, що подобається йому. А те, що ти його просиш робить аби як, або максимально паскудно. Різниця лише в тому, що йому не треба платити зарплату, а обійтися підпискою до 50$ на місяць.А так — результат практично той самий.

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

Це вже якийсь дуже травматичний досвід, це чим вже так треба було обпектися?

Ви дивитися на задачу з тактичної точки зору, а я — зі стратегічної. Якщо ви автоматизуєте частину роботи це не значить, що ви досягнете миттєво кращого результату. Ефект може бути незначним чи навіть негативним на дистанції.

Так ось, ШІ на поточному рівні розвитку є збитковим для бізнесу навіть в середньостроковій перспективі, вже не кажучи про довгострокову

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

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

Ви ж дивилися інтеграцію ШІ в різні IDE? Там це одна кнопочка біля поля для коментаря до коміту. Промпт писати не треба. Тут не тільки економія часу, а й розумових сил. Щоб їх витратити на щось більш корисне. А рутину передати ШІ.

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

Звісно, що перечитую. Але це легше і швидше, ніж писати самому. ШI, як і будь-який інший інструмент, треба вміти правильно використовувати.

Правильно не значить ефективно. Саме про це йде мова.

Робіть пілотний проєкт, заміряйте ефективність, робіть висновки. Срібної кулі немає. Те, що працює для вас, для інших може не працювати — і навпаки.

Дякую за підказки що мені робити ;) Ви думаєте пілотного проекту немає? Є вже декілька, але поки що найкращі результати не в програмуванні, а в інших сферах. Поки що. Чекаю на оновлення моделей, там подивимося

Підписатись на коментарі