Стаття дуже цікава. Але тут, як на мене, важливо додати ще один момент:
ще на старті проєкту команда має розуміти, на чому буде будуватися frontend.

Якщо використовується готова UI-бібліотека, то дизайн-система має проєктуватися з урахуванням її архітектури, обмежень і логіки компонентів. Тоді між дизайном і кодом не виникає розриву: однакові правила неймінгу, variants, стани, токени та структура компонентів.

Якщо бібліотека створюється з нуля — це теж абсолютно нормальний сценарій. Але тоді особливо важливо спиратися на перевірені принципи побудови design systems: Material Design, Human Interface Guidelines та інші системні підходи. Тому що все, що закладається в дизайн-систему, потім напряму переноситься у frontend і впливає на підтримку продукту роками.

Проблеми зазвичай починаються тоді, коли дизайн-система створюється повністю кастомно, без опори на системний підхід чи майбутню frontend-архітектуру, а потім її намагаються адаптувати під конкретну UI-бібліотеку або існуючий frontend. У таких кейсах AI навряд чи стане «чарівною кнопкою». Якщо компоненти мають різні назви, змінні, стани та структуру — це вже питання ручної синхронізації дизайну й коду, великої кількості документації та визначення єдиного джерела правди всередині команди.

І тут важливо чесно сказати: якщо навіть людині складно розібратися в такій системі, то не варто очікувати, що AI автоматично вирішить цю проблему. Більше того — кожне додаткове пояснення для AI означає додаткові витрати часу, контексту й токенів, особливо якщо працювати з інструментами на кшталт Claude Code. У певний момент систему все одно доведеться переписувати або у frontend, або в дизайні — залежно від того, де у вас знаходиться джерело правди. Дякую!

Класна стаття, але важливо зафіксувати контекст.

Тут ідеться саме про продуктові інтерфейси — де задача: довести користувача до дії, зменшити тертя і впливати на метрики.

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

Але в продуктових сценаріях усе стає прагматичнішим.

Дизайн — це не про «красиво» чи «некрасиво».
Дизайн — це про те, наскільки ефективно інтерфейс вирішує задачу бізнесу через користувача.

Дизайн — це не просто html+css+js, це ще рішення: що, як і навіщо працює. Код — це вже реалізація.

Про «довести» — так, але бізнес думає наперед, тому ризики враховують.

Про заміну — це скоріше про підвищення рівня складності задач. З’являється можливість робити те, на що раніше не було часу. І тут все залежить від бізнесу: чи він скорочує, чи навпаки використовує це, щоб робити більш складніші речі.

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

Антон, я вибачаюсь але запитаю
«А як зараз актуально?»

Удачі Вам, будемо тримати кулачки ✊

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

AI зараз реально прискорює цей етап — швидше зібрати базову структуру, щось перевірити, запустити MVP. Але далі все залежить від продукту: частина проєктів на цьому і закінчується, а частина росте — і там вже з’являються питання логіки, сценаріїв, консистентності, дизайн-системи.

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

І в будь-якому випадку буде цікаво подивитись на результат — якщо зможеш, поділись, будь ласка, фідбеком, посиланням або хоча б скріншотами 🙂

Дякую!

Я б не сказала, що там «no risks». Ризики все одно є — просто вони контрольовані. І відповідальність все одно на людині, AI тут лише інструмент.

Я якраз про це і кажу: у компанії повний контроль над результатом роботи, і якщо ти використовуєш корпоративні AI-інструменти, відповідальність все одно лежить на тобі, а не на AI. AI не замінює людину — він лише прискорює процес, але рішення за результатом — все одно приймає людина!

Володимир, ваше право так вважати! Дякую за дискусію 🙂

По першому пункту — слабо уявляю, що розробники в Apple роблять ключові речі через умовний клауд без контролю. Невеликі або аутсорс-компанії — вони можуть використовувати LLM ....

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

По Copilot — Microsoft це не просто обгортка. Моделі можуть бути сторонні (я так глибоко не розбиралась), але сам продукт, інтеграція і екосистема — їхня.

1) Так, великі компанії вже використовують LLM, але не «як є». Вони працюють через enterprise-рішення з обмеженнями, контролем доступу і політиками безпеки, тому це контрольований ризик, а не хаос.
2) Якщо там справді немає цінності, то чому на багатьох сайтах намагаються обмежити доступ до інструментів розробника (DevTools)?
3) Microsoft розвиває цілу екосистему: Copilot, Azure AI, Copilot Studio.

Ми можемо по-різному ставитися до законів у нас, але якщо дивитися на США чи Європу, великі компанії не будуть ризикувати такими речами. Для них питання прав, безпеки і відповідальності — критичні. Вони не будуть будувати продукт на чомусь, що юридично «сіра зона» або не захищається.

І тут є ще один важливий момент — дані. Коли розробники чи дизайнери користуються сторонніми AI-інструментами, теоретично частина контексту (запити, код, ідеї) може проходити через ці сервіси. Чи продаються ці дані — це вже інше питання, і зазвичай серйозні компанії прямо пишуть, що не використовують їх таким чином. Але сам факт залежності від сторонніх інструментів — це ризик.

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

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

Головне — в юридичній природі результату. За позицією U.S. Copyright Office, якщо щось створено повністю AI без участі людини, воно може не отримати авторського захисту. Тобто питання не в тому, чи хтось це доведе, а в тому, чи зможеш ти сам це захистити, якщо буде потрібно.

Історія з «компанією без людей» поки що теоретична. У реальності завжди є компанія або людина, яка запускає AI, ставить задачі і використовує результат — і саме вона вважається власником. Але якщо результат взятий «як є», без нормальної доробки, він може бути слабко захищений.

Тому бізнеси не покладаються на чисту генерацію. Вони все одно додають людський контроль і доопрацювання.

Тут є ще простіший і дуже практичний момент. У США позиція U.S. Copyright Office така: якщо щось створено повністю AI без участі людини — воно не має авторських прав. Тобто якщо ти береш згенерований код або дизайн «як є», без нормальної переробки — це по суті нічий результат. Його теоретично може використовувати будь-хто =)

Volodymyr, ти трохи спрощуєш дизайн до «картинки», але насправді це система з компонентів, станів, логіки, сценаріїв і взаємодії, яка постійно змінюється через ітерації. Жоден інструмент зараз не здатен зібрати весь UI «фронтом» адекватно — не вистачає контексту, стабільності й обчислювальної потужності. Той же Claude — це більше про старт, ніж про готове рішення, і він прямо про це пише у своїй документації. Далі все одно доводиться допрацьовувати, наприклад у Figma, у звичайному дизайн-процесі. Плюс ліміти: у дизайні через постійні ітерації вони згорають дуже швидко, бо це не один чіткий запит, а постійний пошук.

І якщо ширше — це стосується всієї IT: усе, що цифрове, автоматизується. Але швидше це відбувається там, де процес лінійний. У дизайні ж немає одного «правильного» результату — є баланс між користувачем, бізнесом і контекстом. Тому AI тут поки що не замінює процес, а лише прискорює.

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

З часом, коли IT виросло і з’явився цей «зоопарк» технологій, процес почав ускладнюватися. Людей ставало більше, ролі дробилися, і будь-яка фіча починала проходити через велику кількість рук, погоджень і компромісів. У результаті — повільніше, складніше і часто гірше за початкову ідею.

І тут цікавий момент: AI фактично почав повертати все на свої місця.

Розробник — не дизайнер. І давайте чесно: у більшості з них немає ні задачі, ні часу розвивати «відчуття прекрасного». Так само дизайнер — не програміст.

І замість того, щоб намагатися замінити одне іншим, зараз формується більш логічна модель:
дизайнер + розробник + AI як підсилювач

Де:
— дизайнер відповідає за систему, UX і візуальну логіку
— розробник — за реалізацію і архітектуру
— AI — прибирає рутину і скорочує розрив між ними

А скорочення — так, вони будуть.

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

І це, як на мене, нормальна еволюція індустрії.

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

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

Але в IT, як і раніше, правило просте:
або адаптуєшся — або відстаєш.

Дякую!

Так, все вірно 🙂

З Figma у фронтенд уже давно можна забирати — inspect, плагіни, експорт... Агенти — це просто новий рівень. Але головне тут інше — тепер це не один напрямок.

Було: Figma → Frontend → Cleanup

Стало: Figma ⇄ AI ⇄ Frontend

Тобто вже не просто «забрали і підчистили», а двосторонній процес, де агент може і згенерити код, і щось створити в самій Figma.

Дякую!

Все вірно 🙂 «Робіть добре — і буде добре» ніхто не скасовував.

Я з цим повністю погоджуюсь: якісна документація, правильні назви, структура, відсутність хаосу — це база. І так, якщо все це є, продуктивність команди (і людей, і AI) зростає.

Але тут є важливий нюанс.

Якщо дизайнеру дати ідеальні умови:
— повну документацію
— чітко описані компоненти
— всі стани (hover / active / disabled / loading)
— варіанти розмірів (S / M / L)
— теми (light / dark)
........
— поведінку компонентів

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

І саме дизайнер історично все це і створює:
він у Figma сам проєктує компоненти, варіанти, властивості, слоти, логіку поведінки.

Різниця зараз у тому, що:
— раніше дизайнер робив це вручну,
— а тепер він може це задати як систему через «промпт» — і агент згенерує структуру.

І найцікавіше тут не в «AI зробив швидше». А в тому, що: цей компонент можна одразу перенести у фронтенд — і він буде 1 в 1 або максимально близький до продакшну. Тобто змінюється не тільки швидкість.

Змінюється сам підхід:
з «намалювати і передати» → на «задати систему, яку можна виконати».

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

Дякую!

Мені дуже приємно, що цей розділ відгукнувся. Справді, усвідомлення відповідальності й бажання діяти часто стають тією точкою, де починається справжнє зростання.💛