Спостерігати за розвитком АІ — як інженер і як керівник продуктової студії — це ще ті емоційні гойдалки. Саме тому провів три вихідні, занурившись у вайбкодинг, щоб на власному досвіді зрозуміти, що це і як це може працювати. Почав із хвацького «Ну що, Скайнет, давай подивимося, на що ти здатний». Але вже скоро прийшов до «Мати Василева» і «Ця штука змінить наш звичний світ, і це неминуче».Але якщо відкласти емоції в бік, варто визнати, що поточні можливості вайбкодингу дивують навіть мене, розробника з 20-річним досвідом і десятками кейсів побудови успішних продуктів.
Попри весь шум навколо цього ШІ-торнадо, де часом складно відрізнити реальність від маніпуляцій заради гайпу, ми в Railsware від початку активно досліджуємо цей напрям. Коли кажу про «нас», то маю на увазі близько 200 класних фахівців, серед яких більше ста інженерів.
Але з АІ «граються» не лише вони, а й маркетологи, рекрутери, фінансисти тощо. І як це зазвичай буває, маємо весь спектр думок: від супероптимістів, які вірять у всемогутність ШІ, до затятих скептиків і прагматиків.
Я завжди відносив себе до останніх та сприймав ШІ як ще один інструмент. Зізнаюся, я трішки проґавив момент релізу Claude Opus 4.5. А він, як виявилося, справді змінив процес розробки. Тож вирішив перевірити це на власному досвіді і провів три тижні в експериментах із Cursor та Antigravity, а згодом і з Claude Code. У більшості кейсів використовував Opus 4.6.
Розказую, що з цього вийшло.
Перші вихідні: дива у greenfield-проєктах
Я вирішив не навантажувати модель складними вихідними даними одразу і почав із простого — створення десктопної версії для нашого Mailtrap.io. І тут я вперше створив робочий застосунок під Mac, Linux та Windows, не написавши власноруч жодного рядка коду. Я не просто зміг згенерувати стандартні форми коду, а й задавати потрібний напрямок роботи моделі та вносити точкові зміни в логіку та UI просто в чаті.
Коли я поділився напрацюваннями з командою, ми знайшли лише кілька місць для дрібних правок. Тож вже зараз готуємо застосунок, згенерований буквально за вікенд, до релізу. І скажіть, як тут не здивуватися. Якщо ще пів року тому ШІ партачив, як тільки його намагалися закрутити в потрібний напрямок, зараз він швидко та доволі якісно генерує величезні шматки коду.
Звісно, результат досі не ідеальний, але користувач навряд чи це помітить, якщо застосунок приноситиме йому користь.
Другі вихідні: піднімаємо планку
Після першого вікенду я не став одразу стрибати в щось зовсім космічне, але підняв планку. Моєю ціллю став власний аналог NotebookLM.
Це вже був не експеримент на формі й кнопках, а повноцінний full-stack вебзастосунок. Я пішов у класичний стек: бекенд на Ruby on Rails, база на PostgreSQL і фронтенд на React. Тобто все те, що в нормальному житті означає команду розробників, синки, рев’ю і тижні роботи.
Отримав дуже живу співпрацю в стилі постійного діалогу. Я ставив задачу, отримував результат, дивився, де воно працює не так, уточнював, переформульовував. І так по колу. Швидкість цього циклу, звісно, не порівняти зі звичайним.
За ці три дні я не просто щось зібрав, а й додав деякі функції, які зазвичай займають час.
По-перше, авторизація через Google. ШІ сам підтягнув потрібні залежності і зібрав логіку так, що система почала нормально впізнавати користувача.
По-друге, робота з даними. Я хотів, щоб система не просто зберігала документи, а дійсно розуміла їх. Таким чином, система могла б знаходити зв’язки між різними файлами.
І ще одна функція — можливість перемикатися між моделями. Таким чином, в одному інтерфейсі можливо працювати з Claude, а потім переключитися на рішення від OpenAI, не втрачаючи контексту.
Нагадаю, це все зʼявилося лише за три дні.
Тож те, що раніше займало кілька тижнів роботи команди, стало ітеративним процесом «подумав → перевірив → підкрутив». Ці вихідні дуже чітко дали зрозуміти, що для greenfield-проєктів (тих, що починаються з нуля) швидкість стала зовсім іншою.
Треті вихідні: холодний душ з brownfield-проєктами
На третій вікенд наш «медовий місяць» з вайбкодингом потрапив під холодний душ.
Я взяв за основу кодову базу того ж Mailtrap.io. Це складний продукт зі своїми складностями архітектури та нашарованими рішеннями, які не так легко змінити. Одним словом, класичний brownfield.
Моєю задачею було реалізувати одну, проте складну фічу, покладаючись на ШІ. Підхід не змінював: формулюю напрямок, уточнюю деталі, перевіряю, ітерую. Якщо спершу він будував логіку чітко, то тут він намагався прикинутися своїм у вже створеному коді. За три дні мені не вдалося зробити хоч щось, щоб було готове до релізу.
Коли ми розбирали вайбкод з нашим лід-інженером, стало зрозуміло, що ШІ наробив чимало помилок. Зокрема, бо не розуміє контексту системи на достатній глибині. Він бачить код, але не бачить зв’язків між різними рішеннями.
Мій досвід перегукується з тим, що я чую від продакт-менеджерів та розробників з таких компаній, як Google та Apple. ШІ виконує справді дивовижну роботу, коли отримує зрозумілий сценарій. Та коли додається складний контекст, як у brownfield-проєктах, він губиться.
Звісно, ШІ можна «підгодувати» документацією та правилами, тоді він менше галюцинує і краще тримається рамок. Утім, без технічної команди, яка перевірятиме кожну запропоновану зміну, реалізувати щось серйозне на рівні продакшну неможливо.
Підсумок моїх експериментів
ШІ однозначно змінює точку входу до розробки продуктів. Він пришвидшує шлях від ідеї до першої робочої версії і робить сам факт «початку» майже безплатним і безболісним. Та все ж на цьому його дива (принаймні станом на березень 2026-го) закінчуються. Далі потрібні все ще класні T-shaped фахівці.
Звісно, якщо раніше потрібно було знайти команду, яка хоча б щось створювала, то тепер кожен може навайбкодити щось близьке до MVP. Але ШІ ще не здатен перетворити сирий результат на систему, яка витримує реальне навантаження, масштаб, залежності й постійні зміни. Як і людина, яка покладається лише на ШІ-інструменти. Принаймні, поки що:)
Якщо захочете більше історій, завжди чекатиму у своєму LinkedIn. Там часто ділюсь успішними (і не дуже) спостереженнями та досвідом.