От макета к приложению за несколько дней: как дизайнеры работают в Cursor и Claude Code

Что поменялось в процессе дизайна

Классическая схема выглядела так: исследование, вайрфреймы, макеты, передача разработчикам, ожидание, правки. Дизайнер отдавал картинки и неделями ждал, пока их превратят в код. Как всё работает на самом деле, он видел в самом конце, и половина вопросов всплывала именно тогда.

В сильных продуктовых командах цикл стал короче: идея, быстрый эскиз, промпт, код, проверка в живой среде, правка, запуск. Автор курса показывает, как так работают дизайнеры Perplexity, Intercom, Shopify, Ramp и Notion. В Perplexity дизайнеры почти не рисуют детальных макетов: набрасывают вайрфрейм в Figma и сразу собирают рабочую версию в Cursor. В Shopify у дизайнеров есть своя копия рабочей среды, где они пробуют раскладки прямо в коде настоящего продукта.

Условный пример небольшого сервиса: сколько времени проходит до первой версии, которую можно открыть на телефоне.

Figma при этом никуда не делась. Автор отдельно говорит, что быстрее всего набросать экран всё равно в ней, руки к ней привыкли. Меняется то, что происходит после наброска: следующим шагом дизайнер открывает редактор кода и собирает рабочую версию сам.

Для заказчика это заметно сразу. Вы обсуждаете с командой кнопки, которые нажимаются, формы, которые отправляются, экраны на своём телефоне. Вопросов «а как это будет работать» меньше, решения принимаются быстрее.

Кто такой дизайн-инженер

Дизайн-инженер находится на пересечении вкуса дизайнера и базовой инженерной грамотности. Он может довести идею до работающего вида. Пусть неидеально и без архитектуры на годы вперёд, зато достаточно, чтобы показать, проверить и улучшить.

Лучшим программистом в комнате ему быть незачем. Его ценность в том, что между «придумали» и «потрогали» исчезают недели ожидания.

Кого берут на работу, пока инструменты меняются каждый месяц

В последнем модуле автор выделяет три типа людей, которых нанимают при любых инструментах. Он ссылается на интервью руководителя дизайна Anthropic, где звучат те же три портрета.

Общее у всех троих: у каждого есть готовый проект, который можно открыть и потрогать. Если вы нанимаете дизайнера в штат, просите показать сделанное руками. Одних макетов в 2026 году уже мало.

Вкус важнее промптов

С этой мыслью курса я согласна полностью. Через год промптить будут уметь все, доступ к моделям и конструкторам у всех одинаковый. Выигрывает тот, кто понимает, где ИИ встраивается в его работу, и у кого есть вкус. Принцип «мусор на входе, мусор на выходе» здесь работает буквально: что человек насмотрел, то и получится в результате.

Вывод для заказчика практичный. Подрядчика выбирайте по портфолио и по тому, как он думает о вашем продукте. Список модных инструментов в презентации сам по себе ничего не гарантирует.

Фронтенд, бэкенд и API на пальцах

Прежде чем открывать Cursor, нужна простая модель того, как устроено любое приложение. Автор объясняет её на скриншотах одного и того же приложения из трёх индийских городов: интерфейс меняется в зависимости от того, где человек находится. Я перенесла пример на города, где у нас офисы.

Фронтенд это всё, что вы видите и нажимаете. Бэкенд решает, что именно показать конкретному человеку. API соединяет их: фронтенд отправляет запрос, бэкенд возвращает ответ.

{
  "city": "moscow",
  "delivery": "30-40 мин",
  "banner": "lunch_15",
  "top": ["bowl", "syrniki", "flat_white"]
}

Зачем это знать заказчику. Когда подрядчик говорит «это правка на фронте», речь о внешнем виде и поведении экрана, обычно это быстро. «Нужно менять бэкенд» значит, что меняется логика и данные: дольше и дороже. «Нет API» означает, что две системы пока не умеют разговаривать друг с другом, например сайт и ваша 1С.

Два типа ИИ-инструментов

Новые ИИ-инструменты выходят каждую неделю, и учить все подряд бесполезно. Даже автор курса признаётся, что не успевает за этим потоком. Поэтому он делит всё на две группы, и это деление снимает половину путаницы.

Инструменты автор называет стрелами в колчане. Все стрелы сразу не нужны, важно понимать, какую взять под конкретную задачу. Выберите пару инструментов, которые кажутся понятными и легко встают в вашу работу. Самый быстрый способ застрять это пытаться освоить всё одновременно.

Шесть ограничений браузерных конструкторов

Плохими эти инструменты назвать нельзя. Показать идею команде за вечер и собрать мнения они позволяют отлично. Для настоящего продукта нужен инструмент, где код открыт и стек под вашим контролем.

Magic Patterns и Magic Path

Эти два инструмента автор разбирает подробнее. В одном из них он собирает таблицу распределения активов для финансовых консультантов, ни разу не открыв Figma. Используют их тремя способами: обсудить и спланировать экран, собрать варианты по нескольким референсам или отполировать готовый дизайн.

Любой элемент можно выделить и поправить прямо на экране. Повторяющиеся компоненты сохраняются в библиотеку и вызываются в следующих промптах. Figma подключается через MCP, так что инструмент читает ваши кадры напрямую. В Ramp, по словам автора, прототипируют в основном в Magic Patterns, а сам он ходит по кругу: Figma, Magic Patterns и обратно в Figma.

Как выбрать ИИ-модель

Выбор модели автор сравнивает с вопросом «кого спросить в компании». Архитектуру обсуждают с ведущим разработчиком, метрики с аналитиком, фирменные файлы с дизайнером. У каждого свои сильные стороны, своя ставка и своя скорость ответа.

Версии моделей меняются каждые пару месяцев. Полезнее запомнить шесть параметров, по которым сравнивается любая модель, включая те, что выйдут после этой статьи.

Рейтинги вроде LLM Stats годятся как ориентир. Автор советует собирать свою интуицию: прогонять одну задачу через разные модели и сравнивать результат. Что сработало у соседа, в вашем проекте может дать слабый итог.

Токены, кэш и контекстное окно

Любой разговор с моделью измеряется в токенах. Токен это кусочек слова, в английском тексте в среднем около четырёх символов. Русский текст обычно дробится мельче, поэтому тот же смысл по-русски стоит больше токенов.

Счёт складывается из четырёх частей. Вход: ваш запрос вместе со всей предыдущей перепиской и приложенными файлами. Запись в кэш: модель сохраняет часть контекста, чтобы не разбирать его заново. Чтение из кэша: на следующем шаге она берёт сохранённое, это самая дешёвая часть. Выход: ответ модели, самая дорогая часть. Два запроса одинаковой длины могут стоить по-разному, всё решает объём ответа.

Главный подвох в длине разговора. Каждое новое сообщение отправляет модели всю историю заново, и расход растёт быстрее, чем кажется. Когда окно заполняется, самые ранние сообщения вытесняются. Отсюда ощущение, что ИИ «забыл», о чём договаривались в начале. Попробуйте сами: в начале чата лежат правила бренда, добавляйте сообщения и файлы.

Всерьёз оптимизировать расход автор предлагает позже, когда продукт уже работает и нагрузка растёт. На старте важнее разобраться в самом процессе.

Скорость ответа: задержка и пропускная способность

У скорости модели две цифры, и их часто путают. Задержка это время от нажатия Enter до первого символа ответа. В этот момент модель разбирает запрос, собирает контекст и планирует ответ. Пропускная способность это скорость, с которой текст идёт после старта.

Как скорость ощущается именно задержка. Модель может выдавать 70-80 символов в секунду, мы всё равно читаем медленнее. В курсе приводятся замеры с сайта сравнения моделей: у одной из топовых моделей задержка около 3 секунд, у модели подешевле бывает больше 30. Разница между 2, 10 и 20 секундами ожидания за рабочий день складывается в часы. Нажмите кнопку: у всех трёх моделей одинаковая скорость текста, разная только задержка.

Время в демо ускорено в 4 раза, цифры справа показывают реальные секунды.

Общее правило: модели с низкой задержкой обычно дороже, медленные дешевле. Быстрый ответ требует больше вычислительных мощностей. Выбирая модель, вы балансируете между скоростью, ценой и качеством. Мелкие правки интерфейса удобно отдавать быстрому напарнику, сложную логику медленной и умной модели.

MCP, CLI и skills.md

Три понятия, без которых сборка с ИИ буксует. Звучат страшно, на деле всё просто.

skills.md решает проблему «ИИ забыл» из демо выше. Правила лежат в проекте и подтягиваются в каждый новый чат. Вот как такой файл мог бы выглядеть для проекта в нашем фирменном стиле. Скопируйте и замените значения на свои.

Цикл сборки: как это выглядит в работе

Главный навык курса описывается одной строкой: промпт, запуск, скриншот того, что сломалось, скриншот обратно в чат, правка, снова запуск. Весь практический блок состоит из десятков таких кругов.

Несколько вещей меня удивили. Первый промпт автор пишет нарочно неряшливо, почти потоком мыслей: что за приложение, какие функции, тёмная тема, ссылка на кадр в Figma. Модели разбирают и корявый английский, и сумбурный русский. Ясность задачи здесь важнее красивых формулировок.

Вторая: с первого раза правильно не получается никогда. Автор прямо говорит, что если всё идёт слишком легко, вы задаёте слишком простые вопросы. Чем сложнее запрос, тем больше ошибок, и именно на них продукт уходит от шаблона к чему-то своему.

Третья: когда Cursor застрял, автор меняет инструмент. Упрямую ошибку разбирает с Claude напрямую, за свежим взглядом идёт в Kiro, у ChatGPT просит переписать промпт получше и несёт его обратно в Cursor. Разрешения на команды в терминале он просто подтверждает и идёт дальше: кто закапывается в каждую деталь, тот не доходит до конца.

Два приложения с нуля

Практическая часть курса это два проекта от пустой папки до файла, который можно отправить друзьям. Я разложила их по шагам, чтобы было видно, из чего складывается работа.

Автор честно показывает и неудобную сторону. В Figma элемент можно померить и поставить до пикселя. Здесь размеры подбираются перебором: запустил, сделал скриншот, объяснил, что не так, запустил снова. Анимацию в приложении для Mac он подгонял три раза. Такой перебор нормален, без него сборка просто не складывается.

Дальше идеи масштабируются теми же кругами. Приложение с напоминаниями можно связать с данными о здоровье и шагах, хранилище документов дополнить общими папками. Фундамент уже есть, остальное это новые итерации.

Что меняется в России

Курс сделан для международного рынка, и половина его стека у нас работает с оговорками. Вот что придётся учесть, если повторять путь автора здесь.

Хорошая новость: сам подход от этого не меняется. Цикл «промпт, запуск, скриншот, правка» одинаково работает с любым стеком. Меняется только то, где живут данные и через кого идут деньги.

Прототип, MVP или полноценная разработка

Для бизнеса вся эта история сводится к одному вопросу: что заказывать под вашу задачу. Выберите цель, и я подскажу формат.

У прототипа, собранного ИИ, есть коварная черта: он выглядит как готовый продукт. Под капотом при этом может не оказаться проверки прав, резервных копий и защиты от нагрузки. Показывать его людям можно смело. Реальные платежи и данные клиентов пускаем только после того, как код посмотрел разработчик.

Как дизайнер вносит правки в код компании

Последний модуль курса посвящён работе в настоящем коде компании. Инструмент значения не имеет: Cursor, Kiro, Claude Code или Antigravity. Важен процесс, и он укладывается в пять шагов.

Технически это выглядит так. Дизайнеру дают доступ к репозиторию, он клонирует проект в свой редактор, работает в отдельной ветке и присылает запрос на слияние. В основную ветку без проверки ничего не попадает. Для компании это значит, что мелкие правки интерфейса перестают месяцами стоять в очереди у разработчиков: дизайнер делает их сам, разработчик только проверяет.

Как мы работаем и сколько это стоит

В Hated.Ru мы используем этот подход там, где он даёт выигрыш: на старте проекта и в правках интерфейса. Прототип собираем в коде, показываем вам на телефоне и компьютере, обсуждаем уже работающие экраны. Дальше подключаются разработчики: переносят проверенное решение в нормальную архитектуру, поднимают сервер в России, настраивают безопасность и аналитику.

1. Бриф и эскизы. Цели, аудитория, ключевые сценарии, референсы, что уже есть у вас.
2. Прототип в коде. Главные экраны, которые можно нажимать, за несколько дней.
3. Проверка. Показываем прототип вашим клиентам или команде, правим по итогам.
4. Разработка и запуск. Фронтенд, бэкенд, база в российском облаке, публикация, поддержка.

Цены стартовые, точную смету считаем после брифа. Если у вас уже есть сайт и хочется понять, что в интерфейсе мешает клиентам, начните с UX/UI-аудита.

Коротко о главном