Яша Грозян, засновник та дизайнер у стартапі Lumos, у своїй колонці для AIN.UA розмірковує, як кодинг-агенти трансформують продуктовий дизайн, роблять розробку доступнішою та виводять смак на перший план як ключову перевагу стартапів.
Моїми інтерфейсами користуються справжні майстри своєї справи, еліта з топ-1% у своїх галузях: лікарі та науковці. Година уваги таких фахівців коштує сотні доларів. У наших розробках вони створюють завдання та оцінюють, наскільки успішно ШІ-моделі з ними справляються. Саме так ми отримуємо дані, на яких відомі ШІ-лабораторії навчають та тестують передові моделі для медицини та наук про життя. Ці моделі згодом допомагатимуть лікарям, пацієнтам та науковцям.
Це один із напрямків бізнесу нашого стартапу Lumos AI. Найсучасніші моделі вже досягають рівня сильних науковців, тому збирати дані для них стає дедалі складніше. Інтерфейси для таких проєктів є кастомними, мають десятки етапів та розгалужень, і за кожну помилку чи незрозумілість у них ми платимо. Буквально.
Lumos AI — це поки що молодий стартап на етапі seed-раунду. Весь наш перший рік, у дусі Кремнієвої Долини, все кипіло. Обмежений “ранвей” (час, поки вистачає коштів), необхідність демонструвати результати просто зараз, а на весь продукт — лише я один. Тому ці інтерфейси створювалися поспіхом. Швидкість у дизайні жертвоювала якістю: мої макети мали прогалини, не вистачало часу продумати кожен випадок. А те, що потрапляло у продакшн, ще й суттєво відрізнялося від макетів: деталі губилися, патерни замінювалися на ті, що легше сверстати, а про полірування взагалі не йшлося. Але в нашій справі, що гірше продуманий крок, то гірші дані ми отримуємо. Формально все працювало, дані надходили. Однак експерти стикалися з труднощами, команда постійно відповідала на одні й ті ж запитання, а дедалі більше даних не проходили перевірку якості.
У цій ситуації мене завжди дратував цикл, знайомий кожній продуктовій команді. Я передаю макети, інженери збирають інтерфейс, як вони його зрозуміли, ми маємо один раунд правок, якщо спринт дозволяє, і половина недоліків потрапляє в продакшн, а далі всі поспішають гасити наступну “пожежу”.
А поки всі гасять пожежі, безліч покращень, які безпосередньо впливають на якість даних, осідають у беклозі, до якого бракує часу дістатися. Але саме за якість даних нам і платять. Багато що тут залежить від інтерфейсу: наскільки чітко пояснене завдання, скільки інформації одразу вивалюється на людину, чи веде він її крок за кроком, чи залишає розбиратися самостійно. Чим більше потрібно розплутувати, тим повільніше експерт працює і тим гірший результат видає: частина уваги йде не на завдання, а на інтерфейс. Весь шлях, від початку роботи над проєктом до отримання якісних даних, потребував покращення з багатьох боків одночасно.
Один зі способів оптимізувати цей процес — найняти додаткових людей і покращити процеси. У нас не було ні часу, ні бюджету. Але якраз наприкінці першого року роботи компанії відбувся справжній бум кодингу за допомогою ШІ, тому я обрав інший шлях.
Будувати стало дешево. Дорогим стало інше
Раніше розробка коштувала дорого, що визначало, що саме ми робимо, і ставило певні обмеження. Тепер цих обмежень майже немає. ШІ знизив вартість створення продуктів до кількох тисяч доларів на місяць. Figma вже дозволяє дизайнерам вносити зміни безпосередньо в робочий продукт. Крихітні команди випускають повноцінні продукти в рази швидше, ніж це було ще рік-два тому. Щоденна робота PM, інженера та дизайнера зливається в одну професію — “білдера”.
Отже, питання “чи зможемо ми це зробити” вже нічого не вирішує. Дорогим стало інше: зробити так, щоб люди цим користувалися й поверталися. Дорогим, бо на цю частину ШІ ціну не знизив: це питання продукту та дизайну. Дизайн же здебільшого базується на судженнях. Єдина частина роботи, яку не можна делегувати, особливо ШІ: моделі чудово працюють з тим, що вже бачили, але сильний дизайн часто вимагає синтезу нових ідей, а саме синтез моделям досі дається найгірше.
Проєктування в коді прискорило процес
Наприкінці минулого року до нас звернувся великий клієнт, а рук інженерів для нового проєкту зі збору даних катастрофічно не вистачало. Тож я взявся будувати все сам, хоча до цього ніколи не працював з кодинг-агентами. І в мене вийшло. Спочатку я ще малював усе у Figma і збирав за макетами. Але досить швидко відмовився і від цього кроку, почавши проєктувати одразу в коді. Кодинг-агент підключений до нашої кодової бази: він знає, як влаштований продукт, що і як я робив, які компоненти чи патерни використовував, як структуровані наші дані. Тому мені не потрібно пояснювати базові речі перед кожним завданням. Я пишу план, продумую всі сценарії, будую, тестую, полірую. За затратами зусиль це майже як детально поставити задачу інженеру. Тільки нічого не губиться на етапі передачі, бо самої передачі не існує.
За кілька тижнів туди переїхала більша частина моєї роботи. Я відчув себе наділеним суперсилою. Це прискорення дозволило мені зібрати дизайн-систему, яка ще більше прискорила розробку, покращити базові частини платформи, до яких ніколи не доходили руки, і сам процес збору даних. Зараз усе, що не потребує складної інженерної роботи, я створюю та запускаю самостійно.
Був і провал. На одному з ранніх проєктів я створив великий сценарій збору даних, але в коді залишилося кілька технічних багів: тоді я ще зовсім не перевіряв якість того, що генерує агент. Помітили їх запізно, і роботу кількох експертів довелося викинути. Втрата склала $1,5 тис. (приблизно 60 000 ₴). Невелика сума, але урок був болючим. Перевірки не було, бо обсяг роботи та відповідальності зріс у рази, я не інженер, і частину речей освоював методом спроб і помилок. Якість згенерованого коду дуже легко виходить з-під контролю, якщо її не контролювати.
Після цього я перебудував свій процес навколо перевірки якості. Ще на етапі створення фічі запускаю візуальне тестування: агент сам проходить усі сценарії, збирає візуальні та логічні помилки у звіт і сам же їх виправляє. Окремо додав звірку з дизайн-системою: токени, компоненти, патерни, консистентність. На місцях, де я раніше припускався помилок, додав тести. Далі кожен PR (запит на злиття коду) на GitHub автоматично проходить код-рев’ю від кількох ШІ-агентів: за кілька ітерацій вони знаходять проблеми і самі ж їх виправляють. Критичні моменти перевіряє інженер. За останні три місяці в тому, що я випустив, не було жодної проблеми.
Ця швидкість змінила те, скільки ідей ми можемо протестувати, обсяг проєктів і те, як швидко вони проходять шлях від початку роботи до готового продукту. Ще й покращила якість: дані з поточних проєктів не проходять перевірку приблизно вдвічі рідше, ніж з тих, що ми запускали в перший рік. Сценарії краще продумані, експерти рідше стикаються з труднощами і працюють швидше, тому дані кращої якості обходяться нам дешевше.
Паралельно з усім цим зросла наша операційна діяльність: з двадцяти експертів та п’яти проєктів ми виросли до більш ніж тисячі трьохсот експертів і п’ятдесяти проєктів. Самі робочі процеси також ускладнилися. А продуктова частина досі залишається за однією людиною — мною. Рік тому я назвав би таке навантаження непідйомним для одного дизайнера. Зараз це мій звичайний робочий тиждень.
Смак — це новий moat (ключова перевага)
Про “смак” зараз пише кожне друге інвесторське есе, а CEO Figma Ділан Філда прямо називає його новим “moat” (ключовою перевагою бізнесу перед конкурентами) стартапів в епоху ШІ: “…софту стає дедалі більше, конкуренція зростає, і що тоді виграє? Бренд, точка зору, смак, майстерність, дизайн”. І я з цим погоджуюся. Але “смак” часто зводять до візуального шару: гарні шрифти, віжуали, анімації. Це найменша його частина. “Смак” — це про весь досвід: судження про те, де людина завагається чи зрозуміє неправильно, що продукт має просто вирішити за неї, і чи поважає він її час та увагу.
“Смак” тепер не лише про судження, а й про швидкість.
Коли можна будувати продукти за хвилини, вузьким місцем стає те, як швидко ти приймаєш правильні продуктові рішення. За день їх десятки або сотні, здебільшого дрібні. ШІ для мене став другим мозком, незамінним інструментом у проєктуванні та дослідженні. Але бачення того, як продукт має працювати і відчуватися, мусить бути твоїм. А воно береться зі спостережень за реальними користувачами, з емпатії до них. У моделі цього поки що немає.
Сьогодні будь-хто може умовно за вихідні зібрати робочий продукт. “Вайбкод” (код, що створює певну атмосферу або досвід) — всюди. В App Store тепер надходить близько тисячі нових додатків щогодини, цього літа Apple навіть окремо переписала правила перевірки проти додатків, “які не додають цінності”. Здебільшого це “слоп” (неякісний, сирий продукт): незрілий, згенерований без думки та смаку. Продукт, з яким люди залишаються, від продукту, який спробували раз і закрили, відрізняє саме досвід. Ось так “смак” і стає тим самим “moat”.
Інженери, PM і дизайнери бачать різне
Хороший інженер бачить крізь код так само, як я бачу крізь інтерфейс. Він відчує “слоп” у згенерованому коді, знає, де все може зламатися під навантаженням і коли варто обрати інший підхід, ніж рекомендує ШІ. Через це бачення я досі прагну мати поруч інженерів, і що більше я будую сам, то ціннішим воно стає.
Але продуктовий досвід ніколи не був їхнім завданням: їхнім завданням була платформа для розробки, стабільність, складні інженерні задачі. Коли інженери збирали за моїми макетами, деталі губилися дорогою, але під ними хоча б був дизайн. Тепер багато хто вважає, що дизайнера можна пропустити взагалі: віддати UI моделі і отримати те, що вийде. Результат ви бачили самі: технічно продукт працює, але користуватися ним боляче або неможливо.
Найкращі PM, з якими я працював, продумують досвід не гірше за дизайнера. Але багато хто женеться за метриками і випускає те, що їх підвищує, жертвуючи досвідом. Дуже часто це не працює в довгостроковій перспективі.
Дизайнери ж розвивають навички емпатії до користувача, продумування всього досвіду до найдрібніших деталей, побудови бачення на майбутнє, враховуючи при цьому й бізнес-інтереси. Сьогодні, коли створення продукту займає дні, а не місяці, ти приймаєш більше продуктових рішень, ніж будь-коли, і вони майже одразу потрапляють до реальних користувачів. І ця навичка раптом виявляється найдефіцитнішою.
А кого тепер наймати?
Якщо будувати стало дешево, змінився і процес найму. Скільки людей у вашій команді зараз можуть провести фічу від ідеї до релізу самостійно? Одна? Жоден? Раніше це вимагало двох спеціалістів: дизайнера, який створить досвід в інтерфейсі, та інженера, який реалізує його кодом. Тепер — одна людина: та, хто придумає, створить досвід і сама доведе ідею до релізу. “Білдер”. Якщо найскладніше у вас — продуктова частина, наймайте “білдера”, який не може перестати думати про людину по той бік екрана. Якщо найскладніше — під капотом, в інфраструктурі, яка не має права впасти, наймайте інженера.
Я щойно сам написав вакансію дизайн-інженера, бо ми вже не можемо обходитися без розширення. Це той, хто бере нечітку проблему користувача та бізнесу і доводить її до відшліфованого продукту. Самостійно, від початку і до кінця. Має сильний продуктовий “смак”, може залізти в бекенд, якщо потрібно, спокійно приймає рішення за неповної інформації. Це стартап, інакше ніяк. Складну інженерію досі довіряють інженерам. Фронтенд, досвід, продукт і легку інженерію — “білдеру”.
До речі, як зрозуміти, що перед вами саме така людина? Є простий тест на співбесіді. Дайте кандидату фічу, яка працює, але відчувається не так, і спитайте, що б він змінив. Той, хто вам потрібен, почне проходити її як користувач: спочатку спитає, чого людина взагалі сюди прийшла, а далі піде по кроках: “Ось тут я застрягаю”, “Ось це мали вирішити за мене…”
5 кроків, як дизайнеру почати будувати “вайбкодом”
- Зрозумійте, як працює розробка: що таке репозиторій, що таке бранчі та PR-и, як не створити хаосу, працюючи в одному просторі з розробниками. Кілька повідомлень від Claude або 15-хвилинна розмова з інженером дадуть відповіді на все.
- Виберіть кодинг-агента (Cursor, Claude Code, Codex) і підключіть його до вашої кодової бази.
- Спробуйте реалізувати невелику фічу: надайте агенту доступ до макетів у Figma через MCP, опишіть детальний план, зберіть, відшліфуйте, протестуйте. Доведіть до стану, коли можна передати інженеру для релізу. Спочатку взагалі проводьте все через інженера та налагоджуйте процес так, щоб нікому не заважати. А коли розберетеся в процесі, почнете довіряти агентським код-рев’ю, а команда почне довіряти вам, зможете доводити до релізу самостійно.
- Паралельно наведіть лад у фундаменті: створіть дизайн-систему і будуйте все на токенах, компонентах і патернах. Додайте агенту в контекст закони UX і правила копірайтингу. Так агент проєктуватиме чистіше.
- З часом, якщо дозволяють продукт та команда, перенесіть туди ж більшість проєктування і поступово беріть на себе створення end-to-end усього продуктового, що не потребує складної інженерії. Важкі та критичні завдання довіряйте інженеру. Більшість інженерів тільки зрадіють, що ви берете це на себе. Але це не повинно створювати проблем для команди, тому проводьте все синхронно з ними.
Швидкість перестала бути перевагою, бо зараз вона є в усіх. Перевагою стає людина, яка знає, що будувати, яким має бути досвід і як він має відчуватися. Коли зібрати продукт може будь-хто, все вирішує “смак”.
Порада від Шефа:
Щоб ШІ-агенти генерували якісніший код, навчайте їх не лише технічним аспектам, а й основам UX-дизайну та правилам вашої дизайн-системи. Це як дати художнику не лише пензлі, а й розуміння теорії кольору та композиції — результат буде значно кращим і гармонійнішим.
Подробиці можна знайти на сайті: ain.ua