- Вайбкодинг допомагає швидко перевірити ідею; готовність до клієнтів перевіряють окремо.
- Перевіряйте кінцевий результат: збережену заявку, підтверджену оплату та доставлений лист.
- Домен і хостинг залишаються на акаунті власника; код і дані потребують окремих копій.
- Після безкоштовного розбору можна обрати доопрацювання, підтримку або перебудову потрібної частини.
Вайбкодинг - це спосіб створювати програми, описуючи бажаний результат штучному інтелекту звичайними словами. Ви просите зробити сайт, форму запису чи особистий кабінет, інструмент пише код, а ви дивитеся на результат і просите зміни. Так можна швидко перевірити ідею. Щоб довірити цьому сайту клієнтів, гроші й особисті дані, потрібна окрема перевірка того, що відбувається за екраном.
Якщо ви вже зібрали сайт у Lovable, Bolt або за допомогою Cursor і застрягли, почніть із конкретного збою. Заявка не доходить? Після оплати замовлення залишається неоплаченим? Кожне виправлення ламає іншу сторінку? Це задачі з перевірюваним результатом. Походження коду саме по собі не означає, що проєкт доведеться викинути.
Що таке вайбкодинг і звідки взялася назва
Назву vibe coding запропонував дослідник штучного інтелекту Andrej Karpathy у 2025 році. У первісному сенсі людина майже не заглиблюється в код: описує задум, запускає отримане й рухається за відчуттям, чи схожий результат на бажаний. Сьогодні цим словом часто називають узагалі розробку через розмову з ШІ.
Між цими підходами є практична різниця. Розробник теж може генерувати код, але потім читає зміни, перевіряє правила доступу й запускає тести. Це перевірки очікуваної поведінки програми. Фраза «зроблено з ШІ» нічого не говорить про те, чи пройшла робота ці етапи. Для власника важливий результат: хто бачить дані, куди потрапляє заявка, як відновити сайт після невдалої зміни.
Lovable і Bolt дозволяють будувати сайти та застосунки через опис у чаті. Cursor працює як редактор коду з помічником, який може змінювати файли проєкту. Це різні інструменти, тому переносити обмеження одного на всі інші неправильно. Вайбкодингом користуються підприємці, дизайнери, працівники компаній і самі розробники. Спільне тут бажання швидко перетворити задум на щось, що можна спробувати.
Де сайт, створений за допомогою ШІ, справді корисний
Найкраща стартова задача має невеликий обсяг і зрозумілий результат. Наприклад, чернетка посадкової сторінки допомагає перевірити пропозицію та порядок блоків до повної розробки. Прототип особистого кабінету дає змогу показати майбутнім користувачам екрани й побачити, де вони губляться. Для цього не обов'язково відразу підключати справжні платежі та клієнтську базу.
Внутрішній інструмент теж може бути вдалим початком: список задач, підготовка чернетки звіту, невеликий калькулятор. Спочатку використовуйте вигадані або знеособлені дані. Слово «внутрішній» не робить застосунок безпечним автоматично, якщо він доступний з інтернету. Але обмежений процес легше описати, перевірити й підтримувати.
Економія виникає, коли ви рано відмовляєтеся від невдалої ідеї або уточнюєте потрібну функцію без тривалого замовлення розробки. Вона не означає гарантовано дешевий готовий продукт. Макет, який переконав вас рухатися далі, уже виконав свою роботу. Наступний етап варто оцінювати за вимогами реального бізнесу.
Що перевіряти перед приходом реальних клієнтів
Це не перелік вад кожного ШІ-сайту. Це місця, де гарний екран ще не доводить, що процес завершиться правильно. Частину перевірить власник, частина потребує людини, яка читає код і налаштування.
Вхід, ролі та доступ до чужих записів
Вхід підтверджує, хто перед вами. Роль визначає, що цій людині дозволено: клієнту, менеджеру чи адміністратору. Схована кнопка адміністратора не є захистом. Сервер, тобто частина програми, що обробляє запити поза браузером, має відмовляти в забороненій дії незалежно від вигляду сторінки.
Перевіряйте двома тестовими обліковими записами: кожен бачить тільки свої замовлення. Окремо спробуйте вийти, відкрити збережене посилання на кабінет і відновити пароль. Не експериментуйте з чужими даними. Перевірку обходу прав доручіть розробнику на тестовій копії.
База даних зберігає записи сайту. У рішеннях із Supabase правила RLS обмежують доступ до окремих рядків таблиць. Якщо таблиця доступна через публічний інтерфейс, а відповідних обмежень немає, сторонній може отримати більше, ніж показує сторінка. Увімкнути RLS недостатньо: самі правила теж мають відповідати власникам записів.
Секретні ключі та персональні дані
API - це спосіб, яким програми звертаються одна до одної. Секретний API-ключ може дозволяти надсилати листи, витрачати баланс або керувати сервісом. Код, який завантажився в браузер відвідувача, можна прочитати. Тому секретам там не місце. Публічні ключі існують окремо: їхню видимість не слід автоматично вважати витоком.
Перевірте, які саме дані збирає форма, навіщо вони потрібні й хто їх отримує. Не просіть зайвого «про всяк випадок». Політика конфіденційності має описувати справжню обробку даних. Якщо для вашої аудиторії та використаних файлів cookie, невеликих записів у браузері, потрібна згода, банер повинен керувати їхнім увімкненням, а не просто закриватися. Правові вимоги залежать від ринку й даних, шаблонний текст їх не визначає.
Оплата та підтвердження замовлення
Сторінка «Дякуємо за оплату» не доводить, що гроші надійшли. Платіжний сервіс має передати підтвердження серверу, а сайт перевірити його. Таке повідомлення часто називають webhook. Замовлення повинно отримати правильну суму, валюту та стан; повторне підтвердження не має створювати ще одну видачу товару.
На тестових платежах перевіряють успіх, відмову та випадок, коли покупець закрив вкладку після оплати. Окреме питання: що побачить менеджер, якщо підтвердження затримається? Не обіцяйте клієнту виконане замовлення, доки система цього не підтвердила. Наявність готового підключення не скасовує перевірку всього шляху.
Листи та повідомлення
Форма може показати успіх, хоча менеджер нічого не отримав. Зробіть тестове звернення, знайдіть його в місці зберігання та перевірте кінцеву поштову скриньку. Для листів важливі налаштування відправника, відмова поштового сервісу й потрапляння в спам. Якщо лист не прийшов, має залишитися запис заявки та зрозумілий спосіб її обробити.
Перевіряйте також відновлення пароля і повідомлення покупцеві. Простий тест головної форми не доводить, що працюють усі листи. Після зміни відправника чи поштового тарифу повторіть цей шлях.
Google, прев'ю посилань і мобільна швидкість
Клієнтський рендеринг означає, що сторінку збирає JavaScript, код у браузері. Google вміє його виконувати, але помилки завантаження чи обмеження доступу можуть залишити пошуку порожню оболонку. Не кожен робот, який створює прев'ю посилання в месенджері, виконує такий код. Тому перевіряють текст сторінки, заголовок, опис і картинку прев'ю.
Не варто повторювати старе узагальнення, що всі сайти Lovable невидимі для пошуку. Платформа зараз описує серверний рендеринг для нових застосунків і попереднє формування сторінок для перевірених роботів у старіших. Після експорту на інший хостинг поведінку треба перевірити знову. У Google Search Console подивіться перевірку конкретної URL-адреси, а не тільки наявність головної сторінки в пошуку.
На телефоні відкрийте сайт через мобільний інтернет, перейдіть до форми, заповніть її та дочекайтеся результату. Великі картинки, зайвий код й повільні запити можуть зробити красивий екран незручним. Початкові технічні проблеми допоможе помітити безкоштовна перевірка наявного сайту. Вона не замінює перевірку прав доступу та платежів.
Хостинг, домен і можливість відновлення
Хостинг - це середовище, де працює опублікований сайт. Домен - його адреса. Обидва залишаються на акаунті власника. Перевірте, чи отримуєте ви повідомлення про оплату та продовження, чи можете самі увійти й відновити доступ. Робочий сайт не повинен залежати від особистого акаунта випадкового виконавця.
Lovable і Bolt мають інтеграцію з GitHub, сервісом зберігання коду та історії змін. Репозиторій, тобто сховище файлів проєкту, корисно контролювати власнику. Але копія коду не є копією бази, завантажених файлів чи налаштувань зовнішніх сервісів. Уточніть, що резервується, за який період і як це відновлюється. Сам факт наявності архіву ще не доводить можливість відновлення.
Витрати й виправлення, які ходять по колу
Кредити й токени - одиниці обліку використання інструмента, а не кількість готових функцій. Lovable використовує кредити, Bolt описує витрати токенів. Перевіряйте актуальні умови свого тарифу. Окремо враховуйте роботу опублікованого застосунку, пошту, сховище, платіжні комісії та інші підключені послуги.
Якщо після «виправ усе» зникає форма, поверніться до останнього робочого стану й опишіть один збій. Запишіть кроки, очікуваний результат і фактичний. Після виправлення повторіть також сусідні сценарії. Історія версій допомагає повернути код, але її можливості щодо даних треба перевіряти окремо. Не погоджуйте невідоме очищення бази заради зникнення помилки.
Хто помітить проблему після передачі сайту
Окремо домовтеся про звичайний робочий день після запуску. Хто дивиться нові заявки? Де власник побачить, що поштовий сервіс відмовив або закінчився оплачений ресурс? Чи залишиться звернення доступним, якщо повідомлення не надійшло? Такі питання корисніші за обіцянку «все буде автоматично». Сайт може працювати сьогодні й втратити одне з підключень пізніше без жодного редагування коду.
Передайте відповідальному короткий опис головного сценарію та місця, де видно результат. Наприклад, для тестового звернення зафіксуйте сторінку відправлення, запис у списку звернень і отриманий лист. Це приклад перевірки, а не історія клієнтського проєкту. Після оновлення повторюють той самий шлях. Якщо результату немає, спершу зберігають наявні дані й з'ясовують стан операції, потім повторюють її без дублювання. Власнику не потрібно читати весь код, щоб вимагати зрозумілого підтвердження та знати, кому передати збій. Перелік таких перевірок зберігайте разом із домовленістю про підтримку, а не тільки в історії чату з інструментом.
Чекліст власника перед запуском
Проходьте його на опублікованій тестовій версії з вигаданими записами. Біля непідтвердженого пункту залишайте питання й відповідального. Позначка «працює» має означати побачений результат, а не обіцянку в чаті.
Клієнтський шлях
- Відкрив сайт на телефоні, прочитав пропозицію та знайшов контакти.
- Відправив форму кнопкою й Enter. Заявка збереглася та дійшла відповідальному.
- Помилкові поля пояснюються зрозуміло; введений текст не губиться.
Дані та гроші
- Два тестові клієнти не бачать записи один одного. Після виходу кабінет закритий.
- Розробник перевірив серверні права, правила бази та розміщення секретів.
- Тестова оплата, відмова й закрита вкладка дають правильний стан замовлення без дублів.
Видимість і довіра
- Основні сторінки доступні за прямим посиланням, зокрема після оновлення.
- Перевірені читабельність для пошуку та прев'ю посилання в месенджері.
- Контакти справжні, політика відповідає даним, згода на cookie налаштована там, де потрібна.
Контроль після запуску
- Домен, хостинг і потрібні сервіси на моєму акаунті, продовження під контролем.
- Є копія коду, окрема копія потрібних даних і перевірений спосіб відновлення.
- Зрозумілі платежі за сервіси й людина, яка перевіряє збої після оновлень.
Якщо платежів або кабінету немає, відповідні пункти можна пропустити. Якщо є чужі записи чи непідтверджені оплати, зупиніть саме ці функції до виправлення. Колір кнопок може зачекати.
Залишити як є, доопрацювати чи перебудувати?
Коли можна залишити поточну версію
Якщо сайт виконує невелику задачу, перевірки пройдені, витрати зрозумілі й є спосіб відновлення, причина переписувати його тільки через ШІ відсутня. Для раннього прототипу достатньо чесно позначити межі: демонстраційні дані, без реальних оплат, обмежене коло користувачів. Публічна посадкова сторінка теж може працювати на такій основі після перевірки форми, швидкості та доступності для пошуку.
Коли потрібен розробник
Залучайте його, коли не можете пояснити, де зберігаються заявки, хто має права адміністратора або що підтверджує оплату. Інший сигнал: одну помилку виправляєте знову після кожної зміни. Просіть спочатку відтворити збій і назвати межі виправлення, потім перевірити результат у кінцевому місці. Для листа це скринька, для оплати це запис замовлення.
Коли перебудова може бути дешевшою
Порівнюйте дві оцінки однакового результату: виправлення поточного коду й створення потрібної частини заново. Перебудова має сенс, якщо основа суперечить процесу бізнесу, зміни зачіпають усе або наявну версію неможливо відтворити. До її ціни включають перенесення даних, збереження адрес сторінок, перевірки й запуск. Рішення «перепишемо все» без огляду настільки ж слабке, як «чат усе полагодить».
Як звернутися по допомогу без зайвої підготовки
Artbrain розробляє та підтримує сайти й бізнес-системи, бере в роботу сайти інших виконавців. Починаємо з безкоштовного розбору сайту та задачі, потім погоджуємо оцінку. Разові виправлення й доопрацювання коштують $25 за годину, щомісячне обслуговування починається від $100 на місяць із погодженим складом робіт. Детальніше про регулярні задачі є в поясненні вартості обслуговування сайту.
Для проєкту після вайбкодингу спершу з'ясуємо, чи доступний код і чи можемо взяти його в роботу. Закриті конструктори не беремо у звичне обслуговування. Експортований застосунок оцінюємо за його технологіями, залежностями й потрібними змінами, а не тільки за назвою інструмента, який його створив.
Надішліть посилання та коротко опишіть, що не працює або чого бракує. Додайте кроки до помилки й бажаний результат. Для перевірки коду підійде експорт проєкту або погоджений доступ до репозиторію. Паролі в першому повідомленні не потрібні; домен і хостинг залишаються на вашому акаунті.
Замовте безкоштовний розбір сайту та оцінку доопрацювань. Навіть якщо зараз є тільки робочий прототип, почати можна з одного питання: який шлях клієнта потрібно довести до підтвердженого результату?
Часті питання
Що таке вайбкодинг простими словами?
Це створення програми через опис бажаного результату штучному інтелекту. Інструмент пише код, людина перевіряє отримане й просить зміни. Такий підхід допомагає швидко перевірити ідею, але перед роботою з клієнтами потрібно перевірити дані, права, платежі та відновлення.
Чи можна запустити бізнес-сайт, створений у Lovable або Bolt?
Так, якщо конкретний сайт проходить потрібні перевірки. Для посадкової сторінки та застосунку з оплатами вони різні. Перевірте кінцевий результат форм, доступ до записів, пошук, мобільну роботу й резервні копії. Назва інструмента сама по собі не визначає готовність до запуску.
Чи безпечний сайт, створений за допомогою ШІ?
Безпеку визначають код, налаштування та перевірки. Потрібні серверні обмеження прав, правила доступу до даних і зберігання секретних ключів поза браузером. Автоматична перевірка корисна, але не гарантує відсутності проблем, особливо з особистими даними й оплатами.
Скільки коштує доопрацювати сайт після вайбкодингу?
В Artbrain розбір сайту та задачі безкоштовний, після нього погоджуємо оцінку. Разові виправлення й доопрацювання коштують $25 за годину, обслуговування починається від $100 на місяць із погодженим складом робіт. Спочатку перевіряємо, чи доступний код і чи можемо взяти проєкт; закриті конструктори не беремо у звичне обслуговування.
Чи буде Google індексувати сайт після вайбкодингу?
Походження коду не забороняє індексацію. Потрібні доступні для пошуку сторінки з читабельним вмістом і коректними налаштуваннями. Google виконує JavaScript, але помилки можуть завадити. Перевіряйте конкретні адреси в Search Console та повторюйте перевірку після перенесення. Індексацію й позиції гарантувати не можна.
