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