Що я реально роблю, коли клієнт каже «додай AI в продукт»

«Додай AI в продукт» - бриф, який я чую найчастіше зараз, і майже ніколи це не одна фіча. Під ним зазвичай ховається одна з чотирьох різних задач: чат чи пошук, який стрімить відповідь замість спінера, крок «дизайн у код», що робить чернетку компонента з Figma замість написання з нуля, внутрішній інструмент, що читає щось неохайне (скріншот, PDF, таблицю) замість того, щоб хтось передруковував це вручну, або справжня мультимодальна фіча, де вхід узагалі не текст. Назвати, яка це насправді задача, вирішує всю розробку.

Я краще проведу перший дзвінок, розкладаючи бриф на ці чотири, ніж почну з таблиці порівняння моделей. Модель рідко буває складною частиною. Обвʼязка навколо неї - стан, поки токени стрімляться, файл Figma, який агент реально може розпарсити, черга для скріншотів, які має обробити внутрішній бот - саме туди йдуть тижні.

1. Потокове UI з Vercel AI SDK

Чат-бокс, що відповідає весь одразу, після пʼятисекундного очікування, відчувається зламаним, навіть якщо модель швидка - люди читають перше речення, поки воно ще друкується, а не після. Хуки useChat і useCompletion з Vercel AI SDK обробляють потік токенів, але клієнти реально оцінюють те, що навколо: кнопку stop, яка справді скасовує запит, regenerate, який не дублює останнє повідомлення, і UI, який не смикається, коли блок коду чи таблиця стрімляться посеред речення.

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

2. Figma-to-Code через MCP, і де людині все ще треба дивитись

MCP-сервер, що надає доступ до файлу Figma, дозволяє Cursor чи Claude прочитати реальний макет - назви фреймів, токени відступів, варіанти компонентів - замість здогадок зі скріншота. Це швидко доводить чернетку компонента до прийнятного стану: правильна структура, приблизно правильні відступи, реальні назви класів замість заглушок.

Вона не дає правильних адаптивних брейкпоінтів, доступності чи станів, яких дизайнер не намалював - hover, disabled, порожній, завантаження - без перевірки людиною. Я сприймаю вивід MCP як швидку чернетку, а не PR, готовий до мерджу: час, який це економить, - у наборі шаблонного коду, а не в рев’ю.

3. Внутрішні інструменти на AI, і де мультимодальність реально окупається

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

Саме тут мультимодальний AI - модель, що читає зображення чи PDF замість лише тексту - окуповує свою вартість. Додавати вхід із зображенням у фічу для клієнтів «бо це можливо» зазвичай не варте додаткової площі відмов. Додати це у форму, яку співробітник заповнює сорок разів на день, замінивши документ, який інакше передруковували б, окуповується за перший місяць.

Висновок: назвіть фічу, перш ніж назвати модель

«Додай AI в продукт» перетворюється на план лише тоді, коли стає одним із цього: чатом, що правильно стрімить, кроком дизайну, що чернетить замість заміни розробника, внутрішнім інструментом, що автоматизує конкретну роботу з передруковування, чи реальним мультимодальним входом. Я роблю всі чотири, підключаючи Vercel AI SDK, MCP і ту модель, яка підходить під задачу, а не ту, про яку найбільше говорять цього місяця. Напишіть через форму, що саме AI має читати чи говорити, і я скажу, яке з цих чотирьох це.