Проверенные сборки Zugo: что значит «verified»
Проверенная сборка на Zugo — это сборка, которая уже загрузилась и отрендерилась в изолированной песочнице до того, как вы её увидели. Когда ИИ-билдер Zugo заканчивает игру, сайт или приложение, он не вручает вам сырой код в надежде, что повезёт. Он запускает проект, убеждается, что страница действительно рисуется, и только после этого ставит сборке отметку «проверено».
Одно это слово меняет то, как читать результат. «Готово» у большинства генераторов кода означает «модель перестала писать». «Проверено» на Zugo означает «это запустилось».
Что значит «проверено» на Zugo?
Каждый, кто генерировал код с ИИ, знает стандартный сценарий провала: результат выглядит правдоподобно, вы его открываете — и белый экран. Пропущенный импорт, опечатка в имени компонента, runtime-ошибка в первой же строке. Модель была уверена; браузер — нет.
Zugo закрывает этот разрыв проверкой в песочнице. Прежде чем сборка попадёт к вам на экран, она проходит два жёстких фильтра:
- Загрузка. Проект стартует в изолированной песочнице. Падает на запуске — не проходит.
- Рендер. Песочница убеждается, что страница действительно что-то рисует. Сервер, который поднялся, но ничего не отрисовал, — это не работающее приложение.
Метку «проверено» получает только сборка, прошедшая оба фильтра. Если проверка провалилась, вы не увидите зелёную галочку на сломанном приложении — агент продолжит работать, вместо того чтобы отгрузить вам поломку.
Для контекста — что такое Zugo в одном абзаце:
Zugo (zugo.dev) — ИИ-билдер: вы описываете идею обычным языком, а он собирает работающую 2D-игру, лендинг, приложение или многостраничную платформу с базой данных, авторизацией, платежами и ИИ-функциями. Простое собирается примерно за минуту, сложные платформы — за несколько минут. Каждая сборка проверяется — загружается и рендерится в песочнице — прежде чем попасть к вам.
Если такой способ работы для вас в новинку, статья что такое вайб-кодинг — про саму идею «строить, описывая, а не печатая код».
Что проверяется на каждом этапе?
| Этап | Что проверяет Zugo | Что видите вы |
|---|---|---|
| Генерация | Код собирается по вашему промпту (или по плану из режима Plan) | Живые записи лога процесса по мере создания файлов |
| Загрузка в песочнице | Проект стартует без фатальных ошибок | Статус сборки, пока идёт проверка |
| Проверка рендера | Страница действительно отрисовывается в песочнице | Метка «проверено» на готовой сборке |
| Глубокие сборки | Каждая крупная часть многостраничной платформы завершена | Чекпоинты, закрывающиеся один за другим |
Смысл таблицы — в порядке строк. Верификация — это не отчёт, который читают постфактум. Она стоит между генерацией и выдачей, поэтому непроверенный результат никогда не становится вашей проблемой.
Как работают чекпоинты в глубоких сборках?
Промпт вроде «лендинг для сервиса выгула собак в Остине с формой записи» — одна единица работы. Собралось, загрузилось, отрендерилось, готово — обычно примерно за минуту.
Промпт вроде «платформа записи для ногтевой студии с личными кабинетами, календарём администратора и депозитами через Stripe» — не одна единица работы. Это авторизация, схема базы данных, несколько страниц, платёжный поток и вся проводка между ними. Такие сборки Zugo разбивает на чекпоинты, и вы наблюдаете, как они закрываются один за другим: модель данных на месте, авторизация работает, страницы рендерятся, интеграции подключены.
Чекпоинты важны по двум причинам. Во-первых, прогресс виден: несколько минут сборки ощущаются совсем иначе, когда понятно, что уже готово, а не когда смотришь на крутящийся спиннер. Во-вторых, верификация идёт по этапам, а не один раз в конце, поэтому проблема в календаре администратора не отравит незаметно всё, что построено после неё.
Что показывает живой лог процесса?
Помимо чекпоинтов, глубокие сборки транслируют живой лог процесса: что агент делает прямо сейчас, какие файлы создаёт, что подключает, что заметил и поправил по ходу. Это как смотреть через плечо в терминал разработчика — только без необходимости понимать каждую строку.
Лог — ещё и механизм честности. ИИ-билдер, который прячет процесс, просит верить результату вслепую. Тот, который показывает работу, даёт увидеть, куда именно ушло время, когда сложная платформа собирается несколько минут, а не одну.
Где здесь режим Plan?
Верификация проверяет сборку. Режим Plan проверяет замысел до того, как сборка началась.
В режиме Plan Zugo раскладывает, что собирается построить — страницы, функции, данные, интеграции, — и вы правите план до того, как сгенерирована хоть одна строка кода. Для быстрого прототипа игры он редко нужен. Для многостраничной платформы договориться о плане заранее означает, что последующие чекпоинты — это чекпоинты на пути к нужной вам вещи.
Скиллы воркспейса расширяют это в другую сторону: это именованные инструкции, которые агент помнит между сборками. Если каждый проект в вашем воркспейсе должен использовать фирменные цвета или писать тексты в определённом тоне, вы говорите это один раз в виде скилла, а не повторяете в каждом промпте.
Полный путь от промпта до приложения, включая то, как формулировать запросы, которые хорошо собираются, — в статье как создать приложение нейросетью.
Чего верификация не ловит?
Точно описать гарантию важнее, чем раздуть её.
«Проверено» означает: сборка загрузилась и отрендерилась. Это не означает, что:
- Ваша бизнес-логика верна. Если вы попросили скидку 15%, а имели в виду 25%, приложение отрендерится идеально и применит не то число.
- Игра получилась интересной. Проверенный платформер — это запускающийся платформер. Правильно ли ощущается прыжок — вопрос геймдизайна, и его придётся проверять игрой.
- Каждый пользовательский сценарий пройден. Проверка рендера подтверждает, что приложение рисуется; она не прокликивает каждый путь, которым может пойти пользователь.
Поэтому итерации — часть замысла. Вы описываете правку обычным языком, сборка проходит проверку заново, вы смотрите ещё раз. Верификация убирает самый частый и самый обидный класс провалов — приложение, которое не запускается, — и время ревью уходит на вопросы, ответить на которые можете только вы.
Что происходит после проверки сборки?
Проверенную сборку можно публиковать сразу. Один клик — и она на URL вида <slug>.zugo.run; бесплатные публикации выходят с бейджем «Made with Zugo», платные тарифы поддерживают собственные домены.
Она же и переносима. Zugo экспортирует в GitHub настоящий репозиторий — src/, package.json, vite.config — а не проприетарный бандл. Подробности — в статье экспорт приложения в GitHub.
Приложениям, которым нужна настоящая инфраструктура, доступны коннекторы: Supabase (база данных и авторизация), Stripe (платежи), Google Analytics, Resend (почта) и Vercel (деплой в собственный аккаунт). Zugo Cloud даёт встроенную базу данных сгенерированным приложениям, которым внешние сервисы не нужны.
С ценами просто: бесплатные стартовые кредиты без карты, Pro за $25/мес (200 кредитов — примерно 16 платформ или 33 быстрых сборок — плюс собственные домены) и Business за $99/мес. Есть 25 шаблонов в 5 категориях, если удобнее стартовать с базы, а не с пустого промпта, а интерфейс работает на английском и русском.
Самый быстрый способ откалибровать, что «проверено» даёт на практике, — посмотреть на реальные результаты: в витрине собраны только сборки, прошедшие ту же проверку в песочнице, что описана здесь.