Мінуси, проблеми та нюанси розробки сайтів за допомогою ШІ
Нещодавно мені показали оновлення інтернет-магазину, який я колись розробляв, що було виконане за допомогою ШІ. Причому це оновлення робила людина, яка професійно не займається створенням сайтів на WordPress, Woocommerce, але давно працює з АІ та веб-дизайном. Сказати, що я був вражений – це нічого не сказати! Магазин став більш гарний і зручний з точки зору UX, більш швидкий та функціональний.
Але чи все так безтурботно й просто? Сьогодні поговорю про можливі мінуси АІ-кодингу…
Якщо подивитись на використання штучного інтелекту у веброзробці, то на перший погляд це створює враження революції: прототип, який раніше вимагав тижня роботи, тепер збирається за пару годин. Проте для розробників із середнім та високим рівнем підготовки очевидно, що за цією швидкістю ховаються певні нюанси.
Якщо розглядати AI не як маркетинговий інструмент для швидких демо, а як засіб побудови повноцінних серйозних веб-сайтів, то ви можете стикатись з цілим пластом системних проблем.
Варто зауважити, що деякі з цих проблем стосуються в першу чергу роботи з АІ через окремі запити/промпти. Цілком можливо, що незалежна робота АІ-бота над проєктом в повноцінному середовищі цього проєкту позбавлена тих чи інших недоліків та/або має значно менше технічних проблем.
1. Архітектурне «сміття» та складність підтримки коду
Відсутність єдиного стилю та парадигми.
Якщо розробник використовує АІ через окремі промпти, то фінальний результат зазвичай не містить єдиного кодинг-стандарту чи якоїсь єдиної глобальної логіки. У результаті в одному місці ви можете отримати методику роботи із чистими функціями, а в сусідньому — об’єктно-орієнтований підхід зі заплутаним успадкуванням.
Інколи різниться навіть формат найменування змінних, що робить код проєкту важким для читання іншими розробниками.
Надлишковий DOM та спагеті-стилі
Багато AI-генераторів верстки «перестраховуються» і загортають кожен графічний елемент у безліч вкладених контейнерів <div>. Це призводить до об’ємного DOM-дерева, перевантаженого CSS-селекторами та неоптимізованими JS-скриптами.
На практиці це безпосередньо погіршує показники Core Web Vitals (зокрема, INP та LCP), уповільнює рендеринг сторінки на мобільних пристроях і ускладнює адаптивну верстку.
Втрата контексту на складних проєктах
При масштабуванні LLM модель може втрачати зв’язки між модулям/блоками проєкту. Додаючи нову фічу на прохання користувача, ШІ може непомітно змінити інтерфейс функції в іншому файлі, що призведе до регресійних помилок.
Чим більшим стає проєкт, тим частіше виправлення однієї проблеми штучним інтелектом збільшує ризик появи нових помилок в інших ділянках коду. За всім цим треба слідкувати.
Важкий і дорогий рефакторинг
У програмуванні існує правило: читання коду займає значно більше часу, ніж його написання. Коли ви намагаєтеся виправити баг у згенерованому ШІ коді, вам доводиться «пробиратися» крізь чужу, часто нераціональну логіку.
Досвідченому розробнику нерідко простіше повністю видалити згенерований блок і переписати його з нуля, ніж шукати приховані побічні ефекти від «роботи» штучного інтелекту.
2. Ризики безпеки та застарілі патерни
Вразливості та застарілі практики
Моделі навчалися на гігабайтах відкритого коду з GitHub, де накопичилися рішення за останні 15-20 років. ШІ без вагань може згенерувати код на PHP зі старими функціями, застарілими методами роботи з БД або залишити вивід даних без належного екранування. Це прямо відкриває двері для SQL-ін’єкцій та XSS-атак, якщо розробник не проведе суворий аудит.
Фантомні залежності
Моделі іноді «галюцинують» і вигадують назви бібліотек чи npm/Composer-пакетів (Hallucinated packages), які звучать дуже логічно для вирішення конкретної задачі, але насправді не існують.
Це створює критичну вразливість для атак хакерів. Вони можуть знайти подібні назви-галюцинації і зареєструвати шкідливі пакети з відповідними назвами в публічних репозиторіях. Потім недосвідчені розробники просто автоматично завантажують їх у свої проєкти.
Відверті помилки без вагань
В одному цікавому Ютуб-ролику про ШІ я бачив твердження про те, що у ШІ немає вагань. Тобто, якщо штучний інтелект впевнений, що «правильний маршрут для авто проходить через озеро, то він буде вести вас саме так».
Я вже не можу полічити скільки разів перепитував ШІ стосовного його порад/підказок чи точно все має бути так, як він каже. Це дало змогу виправити дуже багато помилок, які ШІ робить абсолютно без вагань. В одному промпті він пише одне, а в наступному визнає, що був не правий))
Проблема «крайових» випадків
ШІ непогано справляється з «ідеальними діями» користувача, коли той натискає правильні кнопки і вводить коректні дані. Але в реальному вебі можливі різні нестандартні ситуації.
В деяких ситуаціях АІ додає стандартні перевірки в код, але не завжди. Розробнику потрібно самому контролювати і продумувати логіку обробки можливих помилок для веб-проєкту.
3. Проблеми з доступністю, семантикою та UX
Низька доступність (Accessibility)
Чесно зізнаюся, в даний момент я не сильно орієнтуюсь на Accessibility під час розробки сайтів, але в певних проєктах і країнах це дуже важливий нюанс. Штучний інтелект майже ніколи не будує інтерфейси з урахуванням WCAG (Web Content Accessibility Guidelines). Він ігнорує коректні aria-* атрибути, не налаштовує логіку видимого фокусу для навігації з клавіатури та не створює правильних текстових альтернатив для скрінрідерів.
Ігнорування HTML5-семантики
Часто ШІ будує каркаси сайтів на універсальних блоках <div> та <span> без використання семантичних тегів <main>, <header>, <nav>, <article>, <aside>. Пошукові роботи (Googlebot) використовують семантику для побудови документального дерева сторінки та оцінки релевантності контенту. Безсемантична верстка може ускладнювати індексацію або негативно впливати на позиції сайту.
Шаблонність та відсутність унікального UX
Ось з цим погоджуюсь на всі 100% — неодноразово бачив наче «візуальні клони сайтів». AI-інструменти витягують рішення з «середньостатистичного» вебу, тому в результаті згенеровані веб-сторінки досить схожі одна на одну. Типові UI-компоненти, блоки та сітки без якихось унікальних сценаріїв користувача. Якщо ви прагнете унікальної впізнаваності бренду, то тут треба бути обережним.
Висновок. Штучний інтелект — це потужний «підрядник» для автоматизації рутини, але архітектор з нього часто виходить не найкращий. Для професійного розробника важливо тримати під контролем питання оптимізації та безпеки, виконувати перевірку та рев’ю отриманого коду.