# Может ли v0 by Vercel создать готовый к выпуску фронтенд?

> Разбираем, где v0 by Vercel ускоряет фронтенд, где ломается сгенерированный UI и как оценить интеграцию дизайн-системы, тесты и доработку.

v0 может за несколько минут создать убедительный интерфейс. Но он не решит, подходит ли этот интерфейс вашему продукту, соблюдает ли контракты компонентов, справляется ли с неудобными данными и заслуживает ли одобрения инженера, который отвечает за систему. Красивый предпросмотр доказывает лишь то, что удачный сценарий отображается. Для выпуска нужны куда более веские доказательства.

Я использую сгенерированный UI как ускоренную первую реализацию, а не как замену фронтенд-разработке. Именно это различие сохраняет преимущество в скорости. Проблемы начинаются, когда команда за час генерирует страницу, объявляет ее готовой на 90 процентов, а при проверке выясняет, что оставшаяся работа затрагивает токены, доступность, управление состоянием, аналитику, тесты и полдюжины существующих компонентов. Последние 10 процентов никогда не были десятью процентами. Это была интеграционная работа, которую скрыл предпросмотр.

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

## Результат v0 - это ветка, а не готовый фронтенд

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

В актуальной документации v0 сказано, что импортированный репозиторий GitHub становится источником истины. Чат получает отдельную ветку, изменения кода создают коммиты, а v0 не отправляет код прямо в `main`. Это правильная граница. Сгенерированная работа попадает в тот же процесс проверки, что и работа человека, вместо обходного пути мимо него. Но ветка и предпросмотр лишь доставляют код, а не проверяют его качество.

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

При планировании разделяйте три состояния:

- Сгенерировано: v0 выдал запускаемый код.
- Интегрировано: код использует компоненты, границы данных и правила репозитория.
- Готово к выпуску: команда проверила нужное поведение и принимает эксплуатационный риск.

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

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

## Качество компонента начинается с письменного контракта

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

v0 заполняет недостающий контекст правдоподобными решениями. При исследовании это помогает, а при интеграции создает риск. Если в промпте сказано «сделай карточку тарифа», генератор должен сам решить, где хранятся подписи, какой компонент управляет выбором, как форматируется валюта, что означает недоступный тариф и чем должен быть элемент нажатия, ссылкой или кнопкой. Эти решения могут казаться разумными и при этом противоречить приложению.

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

```ts
export type PlanCardProps = {
  plan: {
    id: string
    name: string
    priceCents: number
    description: string
    features: string[]
  }
  selected: boolean
  disabled?: boolean
  onSelect: (planId: string) => void
}

// Constraints:
// - Use the existing Button and Price components.
// - The parent owns selection and currency.
// - Do not fetch data or write analytics inside PlanCard.
// - Keep DOM order meaningful without CSS.
```

Этот фрагмент предотвращает несколько дорогих ошибок. Карточка не изобретет второй форматтер денег, не спрячет загрузку данных в презентационном компоненте и не заведет внутреннее состояние выбора, которое расходится с состоянием оплаты. У проверяющих появится объективная цель. Они смогут сравнить результат с контрактом вместо спора о вкусах.

Смотрите на границы ответственности, а не на длину файла. Один сгенерированный файл на 250 строк не обязательно плох, а пять маленьких файлов не обязательно хороши. Разделяйте код, когда части имеют независимое поведение или устойчивый сценарий повторного использования. Оставляйте разметку вместе, если выделение компонента лишь заменит понятный HTML расплывчатой оберткой с длинным списком свойств. Генераторы часто слишком охотно выделяют повторяющиеся визуальные фрагменты и пропускают настоящие понятия предметной области. Исправляйте это по ответственности.

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

Проверяйте HTML до оформления. `div` с обработчиками клавиатуры все равно остается плохой заменой кнопке. Заголовок, выбранный ради размера шрифта, ломает структуру документа. Список преимуществ из несвязанных контейнеров передает вспомогательным технологиям меньше информации. Правильные элементы сокращают код, потому что браузер уже дает им семантику и поведение.

## Дизайн-система должна стать исполняемым контекстом

Интеграция дизайн-системы работает, когда v0 получает настоящие токены и компоненты, а не абзац о бренде. Фраза вроде «используй наш чистый визуальный стиль» оставляет место для приблизительного результата. Исходный код, примеры компонентов и разрешенные имена токенов ограничивают возможные решения.

Документация Vercel по дизайн-системам в v0 описывает это конкретно. По умолчанию v0 использует shadcn/ui, а пользовательский реестр может открыть команде собственные примитивы, блоки, переменные CSS, стили и зависимости. В новой документации Design Systems системный навык описан как адаптер: он сообщает v0, где лежит исходный код, какие компоненты и свойства разрешены и как подключать систему к новому приложению. Это полезнее, чем копировать сайт с документацией в промпт.

Спецификация реестра shadcn также разделяет зависимости пакетов и `registryDependencies`. Вторые указывают на другие элементы реестра, поэтому продуктовый блок может объявить именно ту кнопку, поле или таблицу данных, которые ему нужны. CLI разрешает эти элементы и проверяет ресурсы реестра по схеме. Так у сгенерированной работы появляется воспроизводимый путь установки вместо набора скопированных фрагментов.

Небольшая запись реестра для продуктового блока может описать связи так:

```json
{
  "name": "billing-plan-grid",
  "type": "registry:block",
  "registryDependencies": [
    "@company/button",
    "@company/price",
    "@company/feature-list"
  ],
  "files": [
    {
      "path": "blocks/billing-plan-grid.tsx",
      "type": "registry:component"
    }
  ]
}
```

Смысл не в самом JSON. Важно, что у `billing-plan-grid` теперь есть именованные зависимости. Если генератор заменит `@company/button` элементом с самодельными стилями, отклонение будет заметно при проверке.

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

Опишите правила выхода за границы системы. Иногда в дизайн-системе нет нужного компонента. Сообщите v0, разрешено ли собрать его из примитивов, добавить локальный компонент или нужно остановиться и отметить пробел. Иначе генератор может сделать почти точную копию существующего элемента. Со временем этот дубль разойдется с оригиналом в стилях фокуса, поведении отключенного состояния и темах. Заметный `TODO(design-system-gap)` дешевле случайной второй системы.

## Проверяйте генерацию как незнакомый пул-реквест

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

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

1. Проследите путь данных от маршрута или серверной границы до отображаемого компонента. Найдите временные массивы, дублирующиеся типы, скрытые загрузки и клиентское состояние, которое копирует серверное.
2. Проследите каждое действие пользователя. Убедитесь, что его обрабатывает правильный элемент, есть состояния ожидания и недоступности, после ошибки можно продолжить работу, а аналитика срабатывает на принятом в проекте слое.
3. Сравните импорты и токены с разрешенными путями репозитория. Ищите цвета в явном виде, произвольные отступы, скопированные примитивы и новые пакеты.
4. Прочитайте структуру DOM и доступные имена, не глядя на визуальный предпросмотр. Затем проверьте порядок клавиатурной навигации и фокус после диалогов, ошибок и переходов.
5. Запустите форматтер, проверку типов, тесты и производственную сборку репозитория. Каждое подавление ошибки или изменение конфигурации рассматривайте как отдельное решение.

Размер сгенерированных изменений нужно ограничивать. Если один промпт добавил страницу, переписал общие примитивы, изменил версии зависимостей и отредактировал глобальный CSS, он объединил несколько решений в одном коммите. Разделите их. Сначала добавьте намеренное изменение дизайн-системы, затем функцию, которая его использует. Так проверяющие увидят, действительно ли общее изменение необходимо и какие снимки или визуальные состояния оно затронуло.

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

Следите за комментариями, которые обещают поведение, но не реализуют его. `// Handle error` над выводом в консоль не создает состояния ошибки. `// Accessible label` рядом с иконкой не дает элементу доступного имени. `// Responsive table` не объясняет, что произойдет с шестью столбцами на узком экране. Сгенерированные комментарии могут звучать как выполненные требования, поэтому проверяйте DOM и путь исполнения.

Не просите v0 проверить огромную генерацию и не принимайте его вердикт без доказательств. Он может помочь найти явные цвета, повторяющуюся разметку или пропущенные состояния, но тот же недостаток контекста, который вызвал ошибку, может скрыть ее при самопроверке. Дайте ему конкретный список приемки и попросите указать доказательства по файлам и строкам. Если ответ не ссылается на реализованное поведение, это новая задача, а не подтверждение.

## Состояния за пределами скриншота съедают бюджет доработки

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

Для каждой области с данными потребуйте хотя бы те состояния, до которых продукт действительно может дойти. Запрос на панели может иметь загрузку, пустой результат, частичные данные, ошибку и успешный ответ. Форме могут понадобиться исходное состояние, неверные данные, отправка, отказ сервера и успех. Не стройте формальную матрицу состояний для статического текста, но и не делайте вид, что у сетевого компонента бывает только одно состояние.

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

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

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

```ts
import { test, expect } from "@playwright/test"

test("a customer can choose the Team plan", async ({ page }) => {
  await page.goto("/pricing")

  const plan = page.getByRole("article", { name: "Team plan" })
  await expect(plan.getByText("For growing teams")).toBeVisible()
  await plan.getByRole("button", { name: "Choose Team" }).click()

  await expect(page).toHaveURL(/\/checkout\?plan=team$/)
})
```

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

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

## Оценивайте доработку по поверхностям интеграции

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

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

Рассмотрим условную оценку одного сценария выбора тарифа. Цифры ниже нужны для планирования, это не отраслевая статистика:

| Работа | Доказательство завершения | Бюджет |
| --- | --- | ---: |
| Создать и выбрать направление | Приняты макеты для широкого и узкого экранов | 4 часа |
| Заменить локальные примитивы и токены | Одобренные импорты без сырых визуальных значений | 5 часов |
| Подключить данные тарифов и выбор | Типы и поведение маршрута соответствуют приложению | 4 часа |
| Добавить достижимые состояния и доступность | Проверка клавиатурой и проверки состояний проходят | 4 часа |
| Добавить тесты и завершить пул-реквест | Обязательные проверки проходят, изменения легко читать | 5 часов |

Итого получается 22 часа. Генерация занимает четыре из них. Если после первых четырех часов назвать страницу готовой на 80 процентов, оценка перевернется с ног на голову. Картинка почти готова, но большая часть инженерных доказательств еще отсутствует.

После нескольких пул-реквестов команда должна заменить эти цифры собственной статистикой. Учитывайте время по постоянным категориям: промпты, визуальные итерации, согласование с системой, поведение, тесты и исправления после проверки. Не объединяйте всю работу после генерации словом «доработка». Такой ярлык выставляет обязательную продуктовую работу потерями и скрывает, какие входные данные нужно улучшить. Если согласование с системой постоянно дороже ожиданий, вложитесь в реестр и примеры. Если больше всего времени уходит на поведение, уточняйте контракт функции до промпта. Если преобладают исправления после проверки, уменьшайте изменения и усиливайте критерии приемки.

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

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

## Просите ограничения и доказательства, а не украшения

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

Передавайте v0 по одной цельной части. Сначала попросите сетку тарифов на существующих компонентах, а уже потом подключайте оплату, меняйте глобальную навигацию и переделывайте мобильное меню. После приемки контракта сетки добавьте действие и состояния. Такая последовательность сокращает побочные изменения и дает каждому промпту проверяемый результат.

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

Потребуйте заметку о реализации вместе с генерацией. Попросите перечислить измененные файлы, использованные компоненты дизайн-системы, новые зависимости, владельца состояния и требования, которые выполнить не удалось. Такая заметка не заменяет проверку. Она показывает предположения, пока в чате еще достаточно контекста для исправления.

Практический промпт может иметь такую форму и не превращаться в огромный шаблон:

```text
Build the pricing selection region on the existing /pricing route.
Use PlanCard, Button, Price, and Stack from the approved import paths.
Read plans from the route loader; do not add sample plan data.
The route owns selectedPlanId. PlanCard receives data and emits onSelect.
Support loading, unavailable-plan, selection-pending, and server-error states.
Preserve the current analytics event and checkout URL construction.
Do not edit shared primitives, global CSS, dependencies, or configuration.
Add the selection Playwright test and report any unmet requirement.
```

Этот промпт предотвращает больше переделок, чем набор прилагательных о современном и дорогом интерфейсе. Он также разрешает v0 признать пробел. Это существенно. Генератор, от которого требуют законченного вида при любых условиях, часто скрывает неопределенность за временным поведением. Явная заметка о невыполненных требованиях оставляет пропущенную работу заметной.

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

## Git-процесс сохраняет ответственность за генерацию

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

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

Защищайте общие файлы процессом, даже если инструмент умеет их редактировать. Изменения токенов, примитивов, манифестов пакетов, помощников авторизации и глобальных стилей должны вызывать проверку владельцев или автоматические проверки, уже принятые в команде. Сгенерированный код не должен обходить владение кодом только потому, что ветку создал инструмент.

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

Не сливайте код по одному предпросмотру. Развертывание предпросмотра отлично подходит для обратной связи от продукта и дизайна, потому что дает проверяющим настоящий адрес и реалистичное отображение. Техническое одобрение все равно относится к изменениям и проверкам. Макет может казаться законченным, пока общий компонент скопирован, условие авторизации перенесено в браузер или новая зависимость незаметно увеличила клиентский пакет.

После слияния оставьте обычное владение. Кладите сгенерированные файлы в те же каталоги, тесты и график сопровождения, что и человеческие. Не добавляйте предупреждения о запрете редактировать результат ИИ. Код, которому нужно особое обращение, уже создает проблему сопровождения. Если команда не может объяснить и безопасно изменить компонент, он не был готов к слиянию.

## v0 полезен, пока команда сохраняет право решения

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

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

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

Team & AI Audit может за пять рабочих дней сопоставить этот процесс с вашим репозиторием, ролями команды и историей поставки, включая места, где ИИ сокращает инженерные расходы и где человеческую проверку нужно сохранить. Полезный результат такой работы не сводится к требованию генерировать больше кода. Это меньшая команда с явными контрактами, лучшим контекстом и измеримым путем от промпта до рабочей среды.

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