Чому з AI я все частіше бачу гірший дизайн — і що показав мій експеримент Figma ↔ code

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мене звати Олена Івлєва. Мій професійний шлях — від UX/UI Designer до UI Engineer і Front-End Developer. Сьогодні я працюю в Kavita Systems і фактично знаходжуся між двома світами: дизайном і його реалізацією в коді. Я починала працювати у вебі ще до Figma та того набору інструментів, який сьогодні здається нам звичним. Тоді дизайнер готував макет, передавав його розробнику, а зв’язок між дизайном і кодом багато в чому тримався на домовленостях між людьми.

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

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

AI генерує екрани, вони швидко переходять у код — і виникає відчуття, що продукт уже готовий.

Але чернетка ще не дизайн, а код, який запустився, — ще не готовий продукт.

Ми вже один раз навчилися будувати продукти системно

Ранній веб створювали переважно технічні фахівці. Дизайн часто передавали розробникам як статичні макети, а в частині проєктів інтерфейс узагалі формувався одразу в коді.

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

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

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

Тому мій принцип простий: спочатку система — потім код.

У продукту має бути не лише технічна, а й візуальна система, яку потрібно підтримувати й розвивати. Компоненти, states, tokens, правила та обмеження мають бути визначені до того, як кожен учасник команди почне трактувати їх по-своєму.

За понад 30 років розвитку Web індустрія поступово прийшла до design systems, component libraries, design tokens, документації, version control, автоматизованого тестування, CI/CD та аналітики. Сам Web бере початок з пропозиції Тіма Бернерса-Лі 1989 року.

Усі ці практики з’явилися не випадково. Вони допомагають робити продукт послідовним, підтримуваним і масштабованим.

І тут з’явився AI.

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

Але замість того, щоб додати до механізму турбіну, ми чомусь вирішили: «А навіщо нам узагалі двигун?»

Продукт — це не просто набір функцій

AI може згенерувати екран — але це ще не дизайн. Написати код — але це ще не якісна розробка. Зібрати кілька функцій у сервіс — але це ще не продукт.

Продукт починається із системи: задач користувача, бізнес-логіки, архітектури, дизайн-системи, сценаріїв, метрик та обмежень.

Якщо людина не розуміє цих основ, AI не компенсує відсутність експертизи. Він працює в межах контексту, правил і задач, які отримав.

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

Що відбувається, коли AI потрапляє до рук професіонала

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

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

У мене є просте правило: я делегую агенту те, що сама можу розкласти на кроки, описати й перевірити. Інакше я просто не зможу зрозуміти, чи хороший результат отримала.

Тому професіонал сьогодні — це не той, хто обов’язково все робить руками. Це той, хто розуміє, як має бути правильно, і вміє використати AI, щоб зробити більше й якісніше.

AI між Figma і кодом: мій експеримент

У 2026 року Figma відкрила Canvas для зовнішніх AI-агентів через MCP. Агенти отримали можливість працювати безпосередньо з Figma-файлами, використовувати контекст дизайн-системи, створювати та змінювати об’єкти на Canvas. Серед MCP-клієнтів Figma прямо згадує й Codex.

Мені стало цікаво перевірити цей workflow на реальному проєкті.

У мене вже були дизайн-система у Figma, робочий frontend і компонентна бібліотека. Я відкрила PhpStorm, підключила Codex до Figma через MCP і поставила конкретну задачу: перевірити, наскільки добре AI може підтримувати зв’язок між дизайн-системою та її реальною реалізацією в коді.

Перший висновок з’явився дуже швидко:

робота з AI починається не з prompt. Вона починається з правил.

Спочатку — контекст

Моя дизайн-система побудована за принципами Atomic Design. Я вручну визначала design-to-code mapping: який компонент у Figma відповідає компоненту в codebase, як співвідносяться variants, states, properties і props та які tokens потрібно використовувати.

AI допомагав уже з формалізацією цієї інформації: оновлював component descriptions, implementation paths і документацію.

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

Для прямого зв’язку між дизайн-компонентами та кодом Figma має Code Connect. Він зв’язує компоненти у Figma з реальною реалізацією в repository та дає MCP-агентам точніші implementation references. Зараз Code Connect доступний на Organization та Enterprise plans і потребує Full або Dev seat.

Я проводила експеримент на Professional plan, тому Code Connect не використовувала. Замість нього побудувала mapping через naming, descriptions, paths, документацію та правила для агента.

Це не заміна Code Connect, а свідоме обмеження мого експерименту.

І тут структура Figma-файлу справді має значення. Сама Figma рекомендує для AI workflow reusable components і blocks, meaningful naming, Auto Layout, properties, variants, variables та component descriptions. Чим чіткіше система описана, тим менше агенту доводиться відновлювати її логіку самостійно.

Тест № 1: code → Figma

Для першого тесту я взяла не кнопку, а невеликий composite component. Усередині були responsive grid, картки, вкладені компоненти, іконки, текст, CTA, button і кілька breakpoint states.

Завдання було не «намалюй щось схоже», а перенеси існуючу реалізацію з codebase у Figma та збережи структуру дизайн-системи.

У моєму тесті агент виконав перенос приблизно за 29 хвилин.

Результат мене влаштував. Компонент не перетворився на один плоский frame: збереглися hierarchy, layers, instances, responsive states, tokens, spacing, typography та редагована структура.

Але тут є дуже важлива деталь:

це був далеко не перший запуск.

29 хвилин — це час конкретної успішної ітерації. До цього були документація, правила, помилки, переписування документації, нові спроби й перевірки.

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

Чим складніший компонент, тим важливіше дробити задачу

На складніших компонентах межі AI видно значно краще.

Nested components, custom logic, abstractions поверх Tailwind, власні utility classes або нестандартні responsive rules збільшують кількість контексту, який агент повинен правильно інтерпретувати.

Він може перенести основну структуру, але пропустити підкомпонент, state або специфічне layout rule. І навіть якщо один компонент перенісся ідеально, це не означає, що наступний матиме ті самі умови.

Тому мій workflow став ітераційним:

невеликий компонент → перенос → перевірка → наступний компонент → перевірка → composition.

Atomic Design тут виявився корисним не лише як спосіб організації дизайн-системи. Він природно допомагає розбити роботу агента на невеликі перевірювані частини.

І це добре узгоджується з актуальними рекомендаціями Figma: AI краще працює, коли система містить не лише атоми, а й добре описані reusable blocks, де вже закодовані layout, spacing і token logic.

Тест № 2: Figma → code

Далі я зробила зворотний тест.

Я прибрала документацію, яка напряму описувала mapping конкретного компонента з кодом, і попросила агента створити нову frontend-реалізацію вже на основі компонента у Figma.

Приблизно через 8,5 хвилин я отримала код. У моєму тесті візуальний результат відповідав макету, responsive states працювали, а структура була близькою до тієї, яку я очікувала для цього проєкту.

Це хороший результат.

Але це не означає, що Figma тепер автоматично генерує production-ready code.

Мій висновок інший: добре структурований компонент у Figma дає агенту якісніший вхідний контекст.

Генерація — це не завершена задача

Я б не запускала автоматичний перенос десяти чи п’ятнадцяти складних блоків із думкою: «Увечері швиденько все перегляну».

Принаймні я так не можу.

Після генерації потрібно перевірити component reuse, props, tokens, responsive behavior, accessibility, dependencies, naming і відповідність архітектурі конкретного проєкту.

Тому мій реальний цикл виглядає так:

Figma → component → code → review → наступна ітерація.

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

Але найдорожчою частиною такого workflow виявилася не генерація.

Найбільше часу пішло на правила, mapping, документацію та ітерації, після яких автоматизація стала достатньо передбачуваною.

Головний ризик — error propagation

У двостороннього workflow є ще одна проблема.

Припустимо:

code → Figma → зміни → code

На першому кроці агент допустив невелику помилку. Її не помітили.

На наступній ітерації вже працюють із цією Figma-версією, додають нові зміни й відправляють компонент назад у codebase.

Для агента попередня помилка не обов’язково виглядає як помилка. Це просто новий input.

У результаті неточність повертається в код, поверх неї з’являються наступні зміни — і починається error propagation.

Тому між ітераціями потрібен validation layer.

І validation — це не відкрити Figma поруч із браузером і сказати: «Ну, схоже».

Потрібно розуміти конкретну систему: компоненти, variants, states, tokens, responsive rules, code architecture, dependencies та обмеження.

Щоб якісно перевірити AI, потрібно знати, яким має бути правильний результат.

Документація допомагає, але не робить AI детермінованим

Одна з речей, у яких AI виявився для мене особливо корисним, — документація.

Я змінюю component, property, token або prop, а агент може оновити descriptions, paths і знайти старі references у codebase.

Тобто прекрасну задачу: «Ми перейменували компонент. Знайди всі місця, де ще використовується стара назва, заміни її на нову та онови відповідну документацію.»

— я із задоволенням віддаю AI.

Але документація не перетворює LLM на звичайну детерміновану програму. OpenAI прямо зазначає, що поведінка мовних моделей за своєю природою недетермінована; навіть коли output технічно обмежений схемою, це окремо не гарантує коректності змісту.

Тому поведінку агента можна зробити значно стабільнішою через:

context → rules → examples → tokens → tests → validation.

Але конкретний результат я все одно перевіряю.

Мій workflow дуже простий:

дала задачу → отримала результат → перевірила → прийняла або виправила.

Я не стала працювати швидше — я стала робити більше

І це, мабуть, найцікавіший результат мого експерименту.

Чи стала я працювати швидше? — Не завжди.

Раніше я навряд чи робила б вісім чи більше контрольних точок, настільки детально документувала компоненти, перевіряла всі states або готувала кілька варіантів одного рішення...

Не тому, що це не потрібно. Просто на все це не вистачало часу.

Частину механічної роботи тепер можна передати агенту. І цей час я витрачаю на інше: краще дроблю компоненти, перевіряю більше states і responsive scenarios, точніше синхронізую Figma з кодом, тестую альтернативи й раніше знаходжу проблеми.

Тобто моя робота стала не обов’язково швидшою, але глибшою й системнішою.

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

AI тут сильний не тим, що «вирішив за дизайнера», а тим, що збільшив кількість матеріалу для професійного аналізу.

І саме тому дизайн-система для мене не стала менш важливою. Навпаки.

У моєму workflow Figma залишається візуальним source of truth, а codebase — source of implementation. У Figma я можу побачити components, variants, states, tokens і hierarchy як одну візуальну систему. У codebase — їхню реальну технічну реалізацію. Між ними потрібен чіткий mapping.

І не варто думати, що достатньо відкрити лише технічну реалізацію — і вся система одразу стане зрозумілою. Спойлер: не стане. Код розкладений по компонентах, файлах, dependencies, стилях і логіці, тому відновити з нього цілісну візуальну картину значно складніше. AI теж не «розбере всю систему за вас» автоматично. Він працює лише з тим контекстом, який отримав у конкретній задачі, і в межах доступних йому обмежень.

Що я винесла з цього експерименту

Найцікавіше для мене — не те, що AI може перенести компонент із Figma в код і назад.

Змінюється точка, де починається проєктування frontend-архітектури.

Якщо раніше частину архітектури інтерфейсу фактично визначали вже в коді, то тепер дедалі більше цієї логіки можна закласти ще у Figma: components, states, variants, tokens, responsive rules, constraints і зв’язки між ними.

У такому workflow Figma — це вже не просто місце, де лежить макет. Це структурована модель інтерфейсу, підготовлена до реалізації.

І тут починають змінюватися ролі. Частину механічної frontend-роботи може забрати AI. Але інженерна експертиза від цього не зникає — вона переїжджає вище по процесу. Людина, яка будує таку дизайн-систему у Figma, уже повинна думати не лише як дизайнер. Вона має розуміти component architecture, states, tokens, responsive behavior, reuse, constraints і те, як усе це буде жити в коді.

Тому я не бачу майбутнє як «дизайнер замінив frontend-розробника» чи навпаки. Швидше, межа між дизайном і frontend стає тоншою. Частина роботи переходить вище — у структуру дизайн-системи. Частина автоматизується. А спеціаліст поступово переходить від ручного створення кожного елемента до побудови правил і системи, з якою можуть працювати і люди, і AI.

Мій головний висновок після експерименту: AI не прибирає архітектуру. У моєму workflow він змушує визначати її значно раніше. І якщо система правильно побудована ще на рівні Figma, AI може взяти на себе значну частину шляху до коду.

Але хтось усе одно має цю систему спроєктувати, зрозуміти її цілком, перевірити результат і відповісти за те, що врешті потрапить у продукт.