Ще вчора для створення модуля OpenCart потрібно було знати PHP, розуміти архітектуру системи, розбиратися в базах даних, OCMOD, Events та інших страшних словах. Сьогодні достатньо написати в чат: "Зроби мені модуль для OpenCart, щоб він робив красиво" (некрасиво не роби), і ось ти вже розробник. А якщо ще навчитися правильно формулювати промпти, то можна відкривати власну студію розробки.
ШІ-розробники захоплюють ринок. Чи ні?
Давайте розберемося, що таке вайбкодинг, чому він став таким популярним і чи варто довіряти свій інтернет-магазин людям, які вчора ще не мали жодного рішення, а сьогодні продають модулі пачками.
Вайбкодинг: коли програмувати може кожен
Сам термін vibe coding став популярним у 2025 році. Його суть проста: людина описує бажаний результат природною мовою, а штучний інтелект генерує код. Замість того щоб самостійно писати функції, можна пояснити ШІ, що саме потрібно зробити, отримати готове рішення, перевірити результат і попросити виправити помилки.
І це справді працює.
Більше того, я вважаю, що ШІ відкриває величезні можливості для малого бізнесу. Те, на що раніше потрібно було витрачати значні кошти або шукати розробника, сьогодні можна спробувати реалізувати самостійно. Наприклад, створити невеликий скрипт для обробки прайсів, автоматизувати роботу з Excel, написати парсер або зробити власний інструмент для аналізу продажів. І для цього не обов'язково мати диплом програміста.
Але є нюанс. Згенерувати код і створити якісний програмний продукт - це не одне й те саме.
Чому всі так полюбили вайбкодинг
Почнемо з хорошого, бо його насправді чимало.
Насамперед це швидкість. ШІ може за лічені хвилини написати те, на що розробник витратив би години. Особливо якщо йдеться про типові операції, нескладні скрипти або повторювані завдання.
Друга перевага - умовна дешевизна. Вартість підписки на ШІ-сервіс може бути значно нижчою за оплату роботи програміста. Щоправда, це справедливо лише тоді, коли ми не враховуємо час на тестування, виправлення помилок і можливі наслідки невдалого впровадження.
Ще один плюс - незалежність. Не потрібно шукати розробника, пояснювати йому завдання, чекати своєї черги та погоджувати кожну дрібницю. Можна експериментувати самостійно, а заодно навчатися: ШІ здатен пояснювати незнайомий код, допомагати розбиратися в архітектурі системи та підказувати, чому певне рішення працює саме так.
І, звичайно, є ще одна беззаперечна перевага - відчуття, що ти гуру айтішки. Учора ти не знав, де в OpenCart лежить контролер товару, а сьогодні вже впевнено розповідаєш про оптимізацію архітектури та масштабування бізнес-процесів.
Головне, щоб сам OpenCart про це не дізнався.
Коли швидкість починає працювати проти якості
Найбільша проблема вайбкодингу, на мою думку, полягає не в якості згенерованого коду як такій. ШІ може писати цілком пристойний код, а людина може написати таке, що потім навіть ШІ відмовиться пояснювати.
Проблема виникає тоді, коли людина, яка отримала готове рішення, не має достатньої експертизи, щоб оцінити його якість. Вона не може впевнено визначити, чи правильно реалізована бізнес-логіка, чи безпечний код, чи не конфліктує він з іншими модулями та чи не створює проблем, які проявляться через кілька місяців.
Зараз з'являється дедалі більше рішень, створених за допомогою ШІ. Частина з них безкоштовна, частина продається за цілком пристойні гроші. І я бачу, як деякі новоспечені "розробники", які до появи ШІ не демонстрували особливої активності у створенні програмних продуктів, раптом переживають свій прайм-тайм.
Модулі клепаються пачками. Сьогодні модуль доставки, завтра модуль знижок, післязавтра інтеграція з маркетплейсом. Продуктивність така, що залишається лише позаздрити.
Але вже за характером деяких звернень у підтримку виникає питання: а чи достатньо часу приділяється тестуванню цих рішень?
Адже швидкість створення коду не означає, що пропорційно скорочується час, необхідний для перевірки його роботи. Іноді навпаки: ШІ може за кілька хвилин згенерувати сотні рядків коду, які потім доведеться годинами аналізувати, тестувати та виправляти.
А можна не тестувати. Випустити модуль у продаж, а там користувачі самі розберуться. Знайшли помилку? Чудово, дякуємо за зворотний зв'язок!
Ви не просто купили модуль. Ви стали учасником програми тестування. Безкоштовним тестувальником платного програмного продукту.
Одна історія про те, чому тестування важливіше за швидкість
Розповім одну байку з власного досвіду.
Колись давно я працювала в IT-відділі великого ритейлера. Розробок було багато, завдань ще більше, і, звичайно, все потрібно було на вчора.
Одного разу я працювала над завданням, яке дуже горіло. Керівниця переглянула мою роботу й сказала переносити на прод. Я хотіла спочатку все протестувати, але часу на це, за її словами, не було. Ну, перенесли й забули.
Аж поки не настав час аналізувати дані.
І тут виявилося, що вони записувалися зовсім не за тією логікою, за якою мали. Відповідно, управлінська звітність, м'яко кажучи, не відповідала дійсності.
Вгадайте, хто був винен і хто вигрібав наслідки? Звичайно, я. Бо який же керівник візьме на себе відповідальність за усне розпорядження?
Виправлення даних коштувало мені приблизно тижня безсонних ночей. Удень навантажувати систему було не можна, тому доводилося працювати вночі. Зате урок я засвоїла назавжди: відтоді я просто не давала відмашку, що завдання готове, доки сама не протестую його й не переконаюся, що все працює правильно.
І тут важливий один момент. Не просто працює, а працює саме так, як повинно працювати. Це принципово різні речі, і саме цієї різниці часто не розуміють люди, які починають займатися розробкою за допомогою ШІ без відповідної технічної підготовки.
OpenCart працює. Але є нюанс
Повернімося до наших модулів.
Припустимо, ШІ створив модуль автоматичного застосування знижок. Ви встановили його, перевірили один товар, побачили правильну ціну й задоволено натиснули кнопку "ОК". Усе працює.
А тепер уявімо, що товар уже бере участь в акції. Або клієнт належить до іншої групи покупців. Або в товару є опції з додатковою ціною. А якщо застосовується купон? Якщо покупець змінить кількість товарів у кошику? Якщо одночасно спрацюють дві умови, які змінюють логіку розрахунку ціни?
Це не якісь фантастичні сценарії, а звичайні ситуації, з якими стикаються інтернет-магазини. І перевірити лише те, що модуль встановився, увімкнувся та виконав одну операцію, недостатньо. Особливо якщо він втручається в розрахунок вартості замовлень, облік залишків, роботу з клієнтськими даними або обмін інформацією із зовнішніми системами.
Помилка в оформленні кнопки - це неприємно. А помилка в розрахунку вартості замовлення - це вже гроші. І далеко не завжди гроші розробника.
Ще одна байка. Усі збіги випадкові
Був у мене й інший цікавий досвід.
Одного разу після роботи розробника в моєму магазині виявилася порушеною нормальна робота з товарами в адмінці OpenCart. Причому помітили це не одразу. Сайт працював, замовлення надходили, зовні все виглядало цілком пристойно. А через кілька місяців, коли виникла потреба змінювати товари, з'ясувалося, що дещо працює неправильно.
Я звернулася до розробника із запитанням, чи могли ці проблеми виникнути внаслідок його роботи. Відповідь була впевнена: ні, не могли.
Тоді я запитала, куди саме вносилися зміни. І тут виявилося, що розробник уже не пам'ятає. Я попросила “згадати”, проте відповіді так і не отримала.
Цікаво, правда? Людина впевнена, що її робота не могла спричинити проблему, але не може сказати, що саме вона змінювала.
Зрештою я знайшла причину самостійно. Так, проблема виникла саме внаслідок тих змін. А коментарі в коді давали підстави припускати, що для вирішення завдання використовувався ШІ.
Звісно, самі по собі коментарі не доводять, що код написаний штучним інтелектом. Але в цій історії важливіше інше: розробник не міг відтворити власні зміни та пояснити їхній вплив на систему. І ось це вже проблема незалежно від того, хто саме написав код.
Можна сказати, що я мала все протестувати одразу після встановлення. Так, мала. Але є нюанс: я не знала, що саме потрібно тестувати. Бо не є експертом саме в тій частині, по якій велась робота.
Завдання мало вирішити одну проблему, а проблема з’явилась там, де її ніхто не очікував. Проблема проявилася лише через кілька місяців, коли виникла потреба виконати операцію, яку я не роблю щодня.
І тут ми підходимо до особливостей OpenCart.
Чому для OpenCart це особливо актуально
OpenCart - досить гнучка система. Саме за це ми її й любимо. Можна встановлювати розширення, змінювати логіку роботи магазину, додавати власні функції та інтегрувати зовнішні сервіси. Але гнучкість має зворотний бік.
У OpenCart для розширення функціональності використовуються модулі, система подій Events, механізм модифікацій OCMOD та інші інструменти.
OCMOD, наприклад, дозволяє змінювати поведінку системи без безпосереднього редагування оригінальних файлів ядра. Проте кілька модифікацій можуть впливати на один і той самий файл або ділянку коду.
І якщо розробник не розуміє, як взаємодіють ці механізми, він може вирішити одне завдання та випадково порушити роботу іншого модуля.
Наприклад, змінити логіку збереження товару, не врахувавши, що інше розширення використовує той самий процес. Або втрутитися в роботу контролера, не перевіривши всі сценарії його використання. Або змінити SQL-запит так, що він почне повертати неправильні дані за певних умов.
Найгірше, що такі помилки не завжди супроводжуються повідомленням на весь екран. Іноді магазин продовжує працювати, просто неправильно. І власник дізнається про це тоді, коли проблема вже вплинула на замовлення, залишки, ціни або інші бізнес-процеси.
А чи знає сам розробник, що написав його ШІ?
Ось тут у мене найбільше запитань до нової хвилі ШІ-розробників.
Чи розуміє людина архітектуру рішення, яке продає? Чи може пояснити, які файли змінює модуль і до яких таблиць бази даних він звертається? Чи знає, як працює механізм встановлення та видалення? Чи перевіряла сумісність з іншими популярними модулями?
І найголовніше: чи здатна вона зрозуміти, що ШІ помиляється?
Бо якщо єдиний спосіб перевірити правильність відповіді одного ШІ - запитати іншого ШІ, то в нас виникає досить цікава система контролю якості.
Особливо коли другий ШІ впевнено підтверджує, що перший усе зробив правильно, а третій рекомендує видалити кеш.
І всі троє мають рацію. Принаймні у власних відповідях.
Безпека: про що взагалі не хочеться думати
Є ще одна проблема, яку не можна ігнорувати, - безпека.
Модуль OpenCart може працювати з персональними даними покупців, інформацією про замовлення, обліковими записами, API-ключами та іншими чутливими даними. Помилки в перевірці прав доступу, обробці вхідних параметрів або роботі з базою даних можуть створювати вразливості.
І це не просто мої побоювання. OWASP, міжнародна організація, яка займається безпекою програмного забезпечення, окремо розглядає ризики використання ШІ для генерації коду. Серед них - небезпечні залежності, непередбачені зміни файлів, недостатня перевірка результатів та надмірна довіра до згенерованого коду.
OWASP також наголошує, що ШІ-розробка не повинна обходити звичайні процедури перевірки безпеки, тестування та контролю змін.
І якщо професійні команди розробників приділяють цьому окрему увагу, то чому ми маємо вважати, що людина без відповідної експертизи може просто згенерувати модуль, встановити його в магазин і сподіватися на краще?
Особливо якщо цей модуль отримує доступ до адміністративної частини сайту або бази даних.
ШІ не скасовує професію розробника
І ось тут хочу зробити важливе уточнення. Я не проти ШІ в розробці. Навпаки, вважаю, що це надзвичайно корисний інструмент, який уже змінює підходи до створення програмного забезпечення.
Досвідчений розробник за допомогою ШІ може працювати швидше, автоматизувати рутинні операції, аналізувати код і витрачати більше часу на складні завдання. А людина без технічної освіти може отримати можливість реалізувати ідеї, які раніше залишалися лише ідеями.
Але є різниця між використанням ШІ як інструмента та повною передачею йому відповідальності за результат.
ШІ може написати код. Але він не стає розробником, який відповідає перед вашим бізнесом за наслідки його роботи.
І якщо людина продає модуль, вона продає не просто архів із файлами. Вона продає програмний продукт, який має виконувати заявлені функції, не порушувати роботу магазину та бути придатним до подальшого обслуговування.
Те, що код створювався за допомогою ШІ, не звільняє продавця від відповідальності за його якість. Так само як використання калькулятора не звільняє бухгалтера від відповідальності за неправильні розрахунки.
Як не стати безкоштовним тестувальником
Тепер трохи практики.
Якщо ви купуєте модуль OpenCart, особливо від нового розробника, я б звертала увагу не лише на перелік функцій і красиві скриншоти. Важливо розуміти, що саме ви встановлюєте у свій магазин.
Перед встановленням варто з'ясувати, з якими версіями OpenCart та PHP перевірена робота модуля, які файли, таблиці бази даних і системні механізми він змінює, чи є документація та історія оновлень. Не менш важливо розуміти, що відбувається після вимкнення або видалення модуля та чи можна відновити попередній стан магазину, якщо щось піде не так. Чи звертається модуль до сервера розробника, і що буде, якщо сервер недоступний?
І, звичайно, не варто встановлювати нові модулі безпосередньо на робочий магазин, якщо є можливість спочатку перевірити їх на тестовій копії. Особливо це стосується розширень, які працюють із замовленнями, оплатами, залишками, цінами та клієнтськими даними.
Але навіть тестова копія не гарантує, що ви знайдете абсолютно всі проблеми. Тому я б ще звертала увагу на те, наскільки добре розробник документує власну роботу та чи здатний пояснити, що саме змінює його модуль. І точно не обирала б модулі, по яким навіть відповідь при зверненні в підтримку надає ШІ-бот.
Бо відповідь "це не могло статися через мою роботу" має значно більшу вагу, коли людина пам'ятає, що саме вона робила.
То що, уникати всіх модулів, написаних ШІ?
Ні. Інакше скоро доведеться взагалі перестати встановлювати будь-які модулі, бо визначити, хто і скільки використовував ШІ під час розробки, ставатиме дедалі складніше. Та й сам факт використання ШІ нічого не говорить про кінцеву якість продукту.
Поганий розробник може написати поганий код самостійно. Хороший розробник може створити якісний продукт за допомогою ШІ. А людина без достатньої експертизи може згенерувати цілком працездатний модуль, але виявитися неготовою до першої ж нетипової помилки. А для модулів, які працюють зі стороннім API важливо розуміти, наскільки швидко автор зможе внести правки у разі зміни API.
Тому я б уникала не ШІ-модулів, а розробників, які не розуміють власного коду, не тестують свої рішення та не можуть пояснити, що саме вони змінили у вашому магазині. І неважливо, скільки років вони займаються розробкою та яким інструментом користуються.
Бо врешті-решт відповідальність за роботу вашого магазину залишиться на вас. Не на ChatGPT, не на Claude і навіть не на розробнику, який уже забув, у який файл вносив зміни.
Тому тестуйте, перевіряйте, робіть резервні копії та не дозволяйте нікому перетворювати ваш магазин на полігон для експериментів.
Щоб одного чудового дня не з'ясувалося, що новий ШІ-чатбот у вашому магазині рекомендує покупцям перейти до конкурентів, бо там дешевше.
І, що найобразливіше, він навіть може мати рацію.
