# Передача design→dev з AI: Figma + підготовка ревʼю коду

> Розробник не повинен писати перший варіант компонент-спеки з Figma — це робить AI. Патерн передачі: AI пише чорнетку з Figma, девелопер ревʼює, а не авторить.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-06-11
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/ai-handoff-design-to-development-figma-plus-code

Якщо ти власник і дивишся, як senior front-end витрачає півдня, переводячи Figma-фрейм у компонент-спеку — ти платиш senior-ставку за стенографію. Правильний AI-передачник перевертає модель: AI пише першу версію спеки з Figma, девелопер ревʼює. Дешевше, швидше, і девелопер робить те, що тільки він може.

## TL;DR

- Девелопер, що перекладає Figma у спеку вручну, — це найдорожча стенографія в команді. AI робить дослівний переклад краще.
- Патерн передачі: AI витягує компонент, пропси, стани, токени і accessibility-нотатки з Figma; девелопер ревʼює і коригує за 10-15 хвилин.
- Підводний камінь: працює лише, якщо в дизайн-системі є названі токени, а в бібліотеці компонентів — стабільні контракти. Без них AI галюцинує.

## Чому design→dev досі ламається з AI у кімнаті?

Бо більшість команд додала AI не з того кінця. Поставили AI в IDE девелопера, щоб генерувати код з прози, а переклад Figma→спека лишили людською роботою. Це навпаки. Figma-фрейм — це структуровані дані; затягнути структуровані дані у структуровану спеку — це те, що AI робить найкраще. Писати продакшн-код з недо-специфікованої прози — найгірше.

> **Definition:** Передача design→development — операційний момент, коли візуальний дизайн-артефакт (Figma-фрейм, flow) стає імплементаційним контрактом (компонент-спека, props-таблиця, список станів).

Виправ напрямок передачі — і робота девелопера стискається до того, що дійсно вимагає його судження: ревʼю контракту, валідації edge-cases, інтеграції з існуючим кодбейсом.

## Що AI витягує з Figma?

Пʼять речей. Усі вже є у файлі; AI лише робить їх явними і у формі для інженерії.

> **Definition:** First-pass компонент-спека — структурована чорнетка інтерфейсу компонента, згенерована з дизайн-артефакту, для інженерного ревʼю, не для прямої імплементації.

1. **Ідентичність компонента** — канонічна назва в системі, найближчий існуючий компонент, delta, якщо це варіант.
2. **Props-таблиця** — кожна візуальна варіація як проп з типом і дефолтом.
3. **Покриття станів** — default, hover, focus, active, disabled, loading, error, empty.
4. **Привʼязка токенів** — кожен колір, відступ, типографіка мапиться на токен дизайн-системи (не на hex).
5. **Accessibility-нотатки** — семантична роль, клавіатурна навігація, screen-reader label, перевірка контрасту.

Ревʼю девелопера тоді стає бінарним на кожен блок: accept, correct, escalate. Не "писати з нуля".

## Шаблон спеки design→dev (copy/paste)

Це форма аутпуту AI-агента. Девелопер відкриває це у code review з Figma-фреймом збоку, заповнює колонку "Dev verdict" — і спека йде в імплементацію.

```
DESIGN-TO-DEV SPEC — v1
Figma-фрейм: [LINK]
Згенеровано: [DATE/TIME] by [AGENT]

1. ІДЕНТИЧНІСТЬ КОМПОНЕНТА
   - Запропонована назва: [Name]
   - Найближчий існуючий: [LibraryName/Component]
   - Варіант існуючого? [Y/N]  Delta: [TEXT]
   Dev verdict: [accept | rename | reuse | escalate]

2. PROPS-ТАБЛИЦЯ
   | Проп | Тип | Дефолт | Нотатки |
   |------|-----|--------|---------|
   | ...  | ... | ...    | ...     |
   Dev verdict per row: [accept | correct: ___ | escalate]

3. СТАНИ В FIGMA
   - [x] default  [x] hover  [ ] focus  [x] disabled  [ ] loading
   - Відсутні стани: [list]
   Dev verdict: [request states | proceed | escalate]

4. ПРИВʼЯЗКА ТОКЕНІВ
   | Властивість | Figma value | Токен |
   |-------------|-------------|-------|
   | bg          | #1A1A1A     | color.surface.primary |
   | padding     | 16px        | space.4               |
   Непривʼязані значення: [list]
   Dev verdict: [accept | request tokens]

5. ACCESSIBILITY
   - Семантична роль: [TEXT]
   - Клавіатура: [TEXT]
   - aria-label suggestion: [TEXT]
   - Контраст vs token bg: [pass/fail + ratio]
   Dev verdict: [accept | correct | escalate]

ЗАГАЛЬНО: [GREEN ready for impl | YELLOW design clarification | RED blocked]
AI-asist: чорнетка [TIME]. Ревʼю: [NAME].
```

Рядок "Непривʼязані значення" — найцінніший одиничний аутпут. Ловить момент, коли дизайнер використав one-off hex замість токена — це місце, де починається drift дизайн-системи.

> **Tool tip (Course for Business):** Чому цей патерн працює в одних і провалюється в інших — питання зрілості дизайн-системи, на яку AI може заземлитися. Augment, don't replace ріже в обидва боки: якщо токени не названі, AI не звʼяже. Тиждень 2 нашої 6-week program проводить команди через token-readiness audit перед автоматизацією передачі, а ратио AI Champions (1:15-20) ставить champion-а ~на 17 співробітників, який володіє тижневим drift-ревʼю. https://course.aiadvisoryboard.me/business.

## Що девелопер робить під час ревʼю?

Три речі, усі швидше за writing-from-scratch. Перша: підтвердити ідентичність компонента — це новий, варіант, чи неправильно ідентифікований існуючий? Друга: пробігти props-таблицю і покриття станів на інженерні питання, яких AI не бачить — бекенд-обмеження, перформанс, припущення інтеграції. Третя: ловити token drift — AI підсвічує непривʼязані значення, девелопер вирішує, повертати в дизайн чи додати токен.

Verdict "escalate" — не опціональний. Якщо будь-який блок тригерить escalate, спека не їде в імплементацію; вона повертається до парної design-dev розмови. Сенс AI-чорнетки — не пропустити людську розмову, а зробити так, щоб розмова відбувалася лише на тих вимірах, які цього потребують.

## Team scan (що AI-champions репортують після тижня 1)

- Adoption: 5 з 6 девелоперів ревʼюють AI-спеки замість writing-from-scratch до дня 7
- Use case: privʼязка токенів ловить ~3-5 непривʼязаних hex-кодів на тиждень
- Заощаджений час: 60-90 хв на компонент-спеку
- Один named AI-champion у front-end команді, ратио ~1:15
- Дизайнерів попросили закрити 2 token-readiness прогалини у тижні 1
- Accessibility-секція впіймала 2 contrast-fail стани до merge
- "Closest existing component" приймається ~70% часу
- 2 спеки ескалейтнуто для design-dev розмови, які б побудувалися неправильно
- Pushback девелопера champion відрефреймив: "ревʼю, не авторство" як senior-роботу
- Maintainer дизайн-системи став неофіційним другим ревʼюером блоків token-binding

## Micro-case (що змінюється за 7-14 днів)

Продукт-компанія на 200 людей з 5 дизайнерами і 14 front-end девами розгорнула AI design→dev. До: senior-деви витрачали ~4-6 годин на тиждень кожен на Figma→спеку. До тижня два — впало до ~1-2 годин ревʼю на дева, а звільнені години пішли в інтеграційну роботу і accessibility, які відкладалися місяцями. Глибший виграш виплив у тижні три: AI впіймав патерн непривʼязаних hex від одного дизайнера, що виявився прогалиною workflow (прототипував у копії старої бібліотеки). Одна коротка розмова виправила джерело, і drift різко впав. Нічого з цього не вимагало "розумного" AI — лише дослівного, і сфокусованого людського ревʼю.

> **Note on this case:** Це ілюстрація — на основі типових патернів у компаніях 30-500 людей, не один клієнт. Числа — заокруглені діапазони, не гарантії.

> **Tool tip (Course for Business):** Рефрейм "ревʼю, не авторство" — це частина, яку треба, щоб champion приземлив. Без нього senior-деви за замовчуванням переписують спеку з нуля — бо ревʼю AI-аутпуту відчувається як babysitting. Shoulder-to-Shoulder hot seat у тижні 4 нашої 6-week program створений саме для цього — senior-дев сидить з champion-ом і конвертує перші три переписування в ревʼю, у 20-хвилинних сесіях. https://course.aiadvisoryboard.me/business.

## FAQ

**А якщо дизайн-система напівзроблена?**
Передача все одно працює — лише прапорить більше непривʼязаних значень, що стає forcing-функцією для закриття дизайн-системи. Багато команд кажуть, що саме ця передача нарешті змусила закрити token-бібліотеку.

**Чи може AI генерувати React-код прямо з спеки?**
Так для тривіальних компонентів; з judgement-ревʼю для будь-чого stateful. Патерн статті тримає девелопера в loop на контрактних рішеннях; генерація коду — окремий шар поверх затвердженої спеки.

**Чи не відчуватимуть дизайнери стеження через "непривʼязані значення"?**
Фрейми навпаки — AI ловить drift, який дизайнер інакше помітив би у QA через два спринти. Превентивний фідбек швидший за ретроспективний. Більшість дизайнерів вітають це після першого впіймання.

**Чи працює це для мобільних/нативних компонентів?**
Так, з тими ж вимірами. Платформо-специфічні токени (system fonts, safe-area insets) мають бути у вашому namespace, перш ніж AI коректно звʼяже — той самий критерій готовності, як для веба.

**Figma→спека AI — це той самий AI, що спека→код?**
Зазвичай ні — у них різні system-промпти і різні поверхні ревʼю. Зливаючи їх в одного агента, ви схлопуєте поверхню ревʼю і робите AI чорним ящиком. Тримайте окремо.

## Висновок

Design→dev — це місце, де AI найочевидніше перевертає роботу: AI робить дослівне витягання, девелопер — judgement-ревʼю. Виграш не малий: 4-6 senior-годин на дева на тиждень, плюс drift дизайн-системи, спійманий рано.

Візьми один компонент у наступному спринті. Прокатай AI-витягання. Хай дев ревʼює замість писати. Виміряй час. Зроби патерн дефолтом.

Якщо хочеш, щоб кожен співробітник зашипив свою першу AI-автоматизацію за пʼять днів — забронюй 30-хв дзвінок, і ми мапнемо перший тиждень твоєї команди: https://course.aiadvisoryboard.me/business.

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/ai-handoff-design-to-development-figma-plus-code. Більше статей: https://aiadvisoryboard.me/uk/blog