Засновницький дизайнер Lumos AI Яша Грозян у колонці для AIN описав, як почав самостійно створювати частину продуктового функціоналу за допомогою кодинг-агентів. За його словами, це дозволило невеликій команді швидше запускати інтерфейси для проєктів зі збору й оцінювання даних, але водночас перенесло на дизайнера більше відповідальності за якість коду, тестування та рішення, які раніше розподілялися між кількома ролями.
Lumos AI працює з даними, оцінюванням моделей і human-in-the-loop розміткою для проєктів у медицині та life sciences. На своєму сайті компанія також заявляє про виконання data- та evaluation-проєктів для OpenAI, Google і Meta. Водночас показники операційного зростання, які наводить Грозян, — зокрема кількість експертів, проєктів і зміна якості даних — є оцінкою автора щодо внутрішніх процесів стартапу й не розкриті в публічній звітності компанії.
Автор стверджує, що в перший рік роботи Lumos AI команда часто запускала інтерфейси поспіхом через обмежений бюджет і нестачу інженерних ресурсів. Для бізнесу, де якість даних залежить від роботи залучених експертів, проблеми в інтерфейсі мають прямі витрати: незрозумілі завдання, надлишок елементів на екрані або непродумані сценарії можуть уповільнювати виконання роботи й збільшувати частку результатів, які не проходять контроль якості.
Від макетів до розробки в коді
За словами Грозянa, потреба швидко запустити новий проєкт для великого клієнта підштовхнула його перейти від підготовки макетів у Figma до проєктування безпосередньо в коді. Кодинг-агент, підключений до репозиторію, може використовувати наявні компоненти, структуру даних і шаблони продукту, тому дизайнерові не потрібно щоразу описувати базовий технічний контекст.
Такий підхід, на думку автора, скорочує втрати під час передачі дизайну від однієї ролі до іншої. Проте він не скасовує потреби в інженерній перевірці. Грозян наводить приклад раннього сценарію збору даних, у якому технічні помилки виявили надто пізно: роботу кількох експертів довелося списати, а прямі втрати становили близько $1,5 тис.
Після цього команда, за його словами, додала візуальне тестування, перевірки відповідності дизайн-системі, автоматизоване рев’ю pull request’ів кількома агентами та окремий контроль критичних змін інженером. Сам автор наголошує, що генерація коду не дорівнює гарантії його якості: без тестів, рев’ю та зрозумілих меж відповідальності помилки можуть потрапити у робочий продукт так само, як і за традиційної розробки.
Грозян оцінює, що після зміни процесу частка даних, які не проходять перевірку якості, у поточних проєктах стала приблизно вдвічі нижчою, ніж у перший рік роботи компанії. Це твердження є внутрішньою оцінкою Lumos AI; компанія не публікувала методології такого порівняння.
Дешевше створювати — складніше втримати користувача
Головний висновок колонки полягає в тому, що інструменти для генерації коду можуть зменшити вартість і час створення нескладних продуктових змін, але не замінюють продуктове судження. Оцінка про те, що розробка продукту тепер може коштувати лише кілька тисяч доларів на місяць, також належить авторові: вона залежить від складності системи, вимог до безпеки, інфраструктури та участі досвідчених інженерів.
На думку дизайнера, доступність швидкої розробки підвищує цінність фахівців, які здатні провести функцію від нечітко сформульованої потреби користувача до релізу. Йдеться не лише про вміння писати або генерувати код, а й про здатність визначати сценарії використання, спрощувати рішення для користувача, працювати з неповними даними та вчасно передавати складні або критичні завдання інженерам.
Це не означає, що дизайнер чи продакт-менеджер автоматично замінює інженера. Стабільність платформи, безпека, масштабування, складна бекенд-логіка та надійність критичних сервісів залишаються інженерними завданнями. Натомість фронтенд-зміни, прототипи, окремі робочі сценарії та продуктові експерименти дедалі частіше можуть виконувати фахівці на перетині дизайну й розробки.
У колонці Грозян називає таку роль дизайн-інженером або білдером і зазначає, що Lumos AI вже шукає людину з подібним профілем. Його критерій — не просто здатність швидко зібрати інтерфейс, а вміння почати з питання, навіщо користувачеві потрібна конкретна функція і де саме він може зіткнутися з непотрібною складністю.
Швидке створення застосунків саме по собі не гарантує їхньої цінності для користувача. Правила App Store Review Guidelines від Apple, зокрема, вимагають від застосунків самостійної корисності або сталої розважальної цінності та дозволяють відхиляти низькоякісні, дубльовані або такі, що не додають цінності магазину, продукти. Ці вимоги не є забороною на застосунки, створені за допомогою ШІ: для Apple важливі насамперед якість, відмінність продукту та відповідність правилам.
Практичний висновок автора для дизайнерів — починати з невеликих завдань, розібратися в роботі з репозиторіями, гілками та pull request’ами, узгоджувати зміни з інженерною командою і не відмовлятися від перевірок. Швидкість створення функцій, за його оцінкою, стала доступнішою для значно більшої кількості команд; конкурентною перевагою лишається здатність визначити, що саме варто будувати і яким має бути користувацький досвід.
