AI-інструменти для прототипування здатні швидко зібрати робочий інтерфейс, але часто роблять це поза дизайн-системою команди. Вони генерують компоненти-двійники: вони виглядають правильно для людини без коду, проте не є справжніми компонентами продукту. Коли розробники переглядають код, ці двійники доводиться переписувати, а витрати на переробку зазвичай не закладені в план. Автор гайду, який опублікував UX Design, називає це «стіною прототипу» і посилається на матеріали Forbes та дослідника Yunhao Jiao.
Найважче в цій історії те, що проблему не вирішує ні точніший промпт, ні додавання markdown-файлів з інструкціями для агента. Тобто команда не може просто довше пояснювати моделі, яку систему використовувати. Розрив виникає на рівні того, як агент бачить компоненти, а не на рівні формулювання завдання. Саме тому прототип, який на екрані виглядає бездоганно, може зіпсувати графік уже на етапі передачі в розробку.
Автор протестував Claude Design на власному репозиторії. Токени дизайну та пропси інструмент зберіг, але змінив залежності, область видимості стилів і типи. Прототип виглядає коректно, а при переносі в продукт ламається. Більше того, власна довідкова нотатка Claude Design визнає, що результат є відтворенням для прототипування, а не кодом, який можна злити в основну гілку. За даними автора, Claude Design переїжджає в Claude у грудні 2026 року, а маршрут через Claude Code він описує як такий, що дає вищу точність для React.
Запропоноване рішення полягає в машиночитному маніфесті компонентів у форматі JSON. Він містить назви компонентів, їхні пропси, дозволені значення та значення за замовчуванням. Маніфест не пишуть вручну, а генерують із коду, наприклад за допомогою Storybook. Далі в гру вступає MCP (Model Context Protocol), який дає агентам змогу запитувати живу дизайн-систему замість того, щоб вгадувати. Автор не називає жодного універсального інструменту, але для Storybook MCP наводить свої результати: приблизно на 27% менше токенів і майже втричі швидша робота в його тесті.
Чому це важливо саме для команд, а не лише для інженерів? Сирий код містить багато шуму і поступово розходиться з дизайном, тоді як маніфест обмежує агента затвердженими компонентами. Для команди це означає менше випадкових варіантів кнопок, полів і карток, які потім доводиться зводити докупи. Автор пропонує п'ять запобіжників: пошук у системі, вибір із закритого списку, автоматичні перевірки, візуальне рев'ю і рішення, яке ухвалює людина. Кожен із них закриває окремий тип помилок, і жоден не є достатнім сам по собі.
Автор описує два маршрути роботи, а третій, через бібліотеку Figma, обіцяє розглянути в наступній статті. Storybook MCP він називає швидшим шляхом, але з обмеженням: потрібен агент, який працює всередині самого проєкту. Для команд без такого налаштування це означає, що спершу варто розібратися з інфраструктурою, а вже потім переходити до генерації прототипів.
Для початку автор радить випробувати підхід на невеликій тестовій дизайн-системі, а не одразу на продукті. Поріг, за якого агенти, що працюють лише з кодом, починають ламатися, він сам не визначив, тому запрошує читачів ділитися даними. Для українських продуктових команд, які вже користуються AI-генераторами інтерфейсів, сенс простий: перш ніж довіряти прототипу графік, варто перевірити, чи компоненти в ньому справжні або хоча б взяті з офіційної бібліотеки.
8
Джерело: AI Prototyping inside your design system. A hands-on guide for design & product teams.
