Чому я використовую Cursor із Figma MCP — і чому все одно тестую на iPhone через кабель

"Фронтенд з AI" раніше означало вставити скриншот у чат і отримати CSS, який був близько, але ніколи точно з тим самим відступом, тим самим сірим, тим самим line-height. Model Context Protocol змінив саме цю частину — передачу дизайну в код. Cursor спілкується з MCP-сервером Figma, і замість того, щоб сплющувати фрейм у пікселі, за якими модель має вгадувати, він отримує реальне дерево нод: auto-layout, значення відступів, прив'язані змінні, назви компонентів, шкалу типографіки. Саме на цю частину я реально спираюсь щодня.

1. Що MCP справді робить правильно

Я обираю фрейм у Figma, даю Cursor посилання — і він запитує MCP-сервер саме про цю ноду. У відповідь приходять структуровані дані: gap 8px — це буквально число 8, а не те, що я виміряла лінійкою по PNG. Колір — це дизайн-токен або hex, прив'язаний дизайнером, а не значення, яке я підбираю піпеткою і сподіваюсь, що співпало. Товщина шрифту, line-height, радіус кутів, реальна ієрархія компонентів — усе приходить як дані, а не як картинка, яку я реверс-інжинирю.

• Відступи, що збігаються з дизайн-системою, а не з найближчим круглим числом, яке я вгадала.
• Кольори і типографіка як токени, тож ребрендинг оновлює одну змінну, а не потребує grep по всіх компонентах.
• Межі компонентів, що збігаються з тим, як дизайнерка реально групувала елементи, — тож згенерований markup легше лишається семантичним.

2. Що я досі перевіряю вручну

Структуровані дані — це не судження. Фрейм у Figma показує один брейкпоінт за раз; він не каже Cursor, що відбувається між 768px і 1024px, чи як виглядає картка з двострічковим заголовком замість одностічкового. У ньому немає порожнього стану, стану помилки, скелетону завантаження — бо для них ніколи й не було фрейму. І згенерований markup може бути структурно точним до фрейму й водночас лишатися div-ом там, де мав бути button, nav чи тег заголовка — я досі перечитую кожен компонент на семантику й доступність з клавіатури перед мерджем.

3. Чому емулятора недостатньо

Панель пристроїв у Chrome DevTools — це Chromium, що рендерить viewport зі зміненим розміром. Це не WebKit, там немає динамічної поведінки viewport, яка є в iOS Safari, і там не покажуться баги, що існують лише на реальному рушії. Тож останній крок перед будь-яким релізом — підключити реальний iPhone до Mac кабелем. Налаштування → Safari → Розширені → Веб-інспектор, увімкнено один раз на телефоні. Далі кабель Lightning чи USB-C до Mac, меню Develop у Safari підхоплює пристрій — і я отримую живий Web Inspector: реальний DOM, реальну консоль, реальну панель мережі — приєднаний до сторінки, яка справді працює в iOS Safari, а не в її симуляції.

Саме тут я ловлю баги, які емулятор ховає: safe-area-inset падінг, що виглядає нормально в DevTools і обрізається під вирізом на реальному телефоні, стрибок 100vh, коли адресний рядок Safari згортається при скролі (dvh це виправляє, але довести це можна лише живим тестом), стрибок фокусу поля вводу, коли клавіатура відкривається при зафіксованому футері на екрані, rubber-band overscroll, що тягне весь layout, і те, як сторінка реально поводиться, доданою на головний екран як окремий PWA. Нічого з цього не показується в емуляторі. Усе це показується вперше, коли реальний клієнт відкриває посилання на своєму телефоні — тож я краще побачу це першою.

4. Чому саме Safari — браузер, для якого я насправді роблю реліз

Перед тим, як вирішити, що взагалі означає "коректно" для проєкту, я дивлюсь на аналітику. Для більшості малого бізнесу й сервісних сайтів, які я роблю, клієнт, що відкриває сайт, — на телефоні, приходить з Instagram, Telegram, Google Maps чи текстового повідомлення — і для значної частини цього трафіку цей телефон — iPhone. Десктопний Chrome — це те, в чому я розробляю. iOS Safari — це те, де реально перебуває людина з карткою. Оптимізувати піксель-перфект для браузера, на який я дивлюсь цілий день, і пропускати той, який реально тримає клієнт мого клієнта, — це оптимізувати не ту аудиторію.

Реальний цикл

Фрейм у Figma, обраний і переданий Cursor через MCP. Компонент, побудований з реальних токенів, а не вгаданих пікселів. Прохід на семантику, стани й брейкпоінти, яких фрейм ніколи не показував. Далі iPhone дістається з шухляди, підключається до Mac, і та сама сторінка живе працює в Web Inspector Safari на реальному рушії. Лише після цього щось мерджиться. Два різні інструменти, дві різні задачі: один швидко наближає мене до дизайну, інший каже правду про пристрій, яким справді користуватиметься клієнт мого клієнта.

Хочете, щоб це справді виглядало правильно на телефоні вашого клієнта?

Це той пайплайн, який я запускаю на кожному білді: реальні дизайн-токени на вході, реальний пристрій на виході. Напишіть через контактну форму й скажіть, якою платформою реально користуються ваші клієнти — я побудую і протестую саме під неї, а не під браузер, зручний для мене.