План, который вы пропускаете, — это сбой, который вы будете отлаживать потом
Любой фреймворк в разработке ПО говорит вам двигаться быстро, выпускать рано, итерировать в продакшене. Для сайтов, генерируемых ИИ, это наоборот. Билдер здесь отказывается стримить код прямо из вашего запроса — он останавливается, пишет план и ждёт, пока вы на него посмотрите, — и этот отказ и есть то единственное решение, вокруг которого построено всё остальное в этом пайплайне. Медленнее в начале, дешевле во всём остальном. Я готов на такой обмен каждый раз, и думаю, что большинство спорящих за обратное просто не видели, во что реально обходится неверная догадка дальше по цепочке.
Вот сценарий сбоя, для предотвращения которого существует план. Вы пишете «сайт для бронирования для моей студии» и нажимаете «вперёд». Системе нужно угадать, что значит «бронирование» — виджет-календарь, встроенный сторонний сервис, настоящая система резервирования с проверкой конфликтов — и угадать это нужно до того, как что-либо написано, потому что другого порядка действий тут нет. Ошибиться внутри плана — и исправление это одно предложение, пять секунд, готово. Ошибиться внутри уже сгенерированного кода — и вы уже не редактируете предложение, вы разбираете десять файлов, которые уже зависят от неверного предположения. Я наблюдал оба варианта. Исправление на этапе плана — это один обмен репликами. Разворот после генерации по той же самой неоднозначности — это отказ от всего и пересборка с нуля.
План — это не просто список дел, и вот это люди чаще всего упускают. Это контракт, и система сама себя им связывает: верификатор соответствия, один из агентов, которые должны дать добро перед выпуском сборки, сверяет готовый сайт с планом, который вы утвердили. Все запланированные страницы построены? Список функций соответствует тому, что реально вышло? «Готово» здесь — не ощущение, это соответствие письменному обещанию, проверяемое построчно. Это более сильная гарантия, чем «код работает», и вы получаете её только потому, что есть документ, с которым можно сверяться. Уберите план — и вы уберёте мерило.
Где это реально окупается
Ваше влияние как человека, ведущего сборку, сосредоточено в начале — вне зависимости от того, пользуетесь вы им или нет. Если вам важна информационная архитектура, структура страниц, какие функции войдут в v1, а какие в v2 — эта дотошность стоит в десять раз больше при просмотре плана, чем после первого прохода генерации. Четыре лишние минуты на перечитывание плана лучше, чем цикл исправления уже пошедшей не так сборки.
Самый наглядный пример — тип продукта: простой статический сайт, устанавливаемое приложение, сборка на фреймворке, серверное приложение с реальным хранением данных. Выглядит как выпадающий список. Но это не так. Это самое структурное решение во всём процессе, потому что оно незаметно определяет десяток вещей, не имеющих ничего общего с тем, как выглядит сайт.
| Тип продукта | Предпросмотр | Опубликовать | Аккаунты / база данных |
|---|---|---|---|
| Простой статический сайт | Мгновенно, ведь это просто статические файлы | Статический вывод копируется без проблем | Невозможно — запрос на вход в аккаунт — это запрос того, что данный тип структурно не может выполнить |
| Сборка на фреймворке | Сначала компилируется; сломанная сборка проявляется как «нет превью», а не «сломанная страница» | Тот же чистый путь статического копирования, после компиляции | Невозможно |
| Серверное приложение | — | Нужно место, где реально может выполняться процесс, и сбои здесь выглядят иначе — упавший процесс, а не отсутствующий файл | Единственный тип, где аккаунты и базы данных вообще существуют |
И вы не можете просто взять и повысить тип позже. Переход от простого сайта к серверному приложению — это не переключатель в настройках, это почти вторая сборка, потому что половина предположений плана (как загружаются страницы, где хранятся данные, что значит «опубликовать») были сделаны для старого типа. Так что скажите об этом на этапе планирования, даже если наполовину не уверены: «есть вероятность, что мне понадобятся аккаунты». Спланировать серверное приложение и использовать только статическую часть — ничего не стоит. Обнаружить постфактум, что оно было нужно, — стоит пересборки.
Где критики правы
Всё это не бесплатно, и я не буду делать вид, что это не так. Изолированные рабочие среды для каждого запуска означают, что ваши файлы знаний копируются заново, и ничто не возвращается на ваш компьютер — хорошо для вас, если ваш ноутбук выйдет из строя посреди сборки, но плохо для скорости, потому что подготовка рабочей среды и, для сборок на фреймворках, выполнение реальной установки зависимостей внутри контейнерной изоляции требует реального времени. Эта контейнерная изоляция существует потому, что сборка на фреймворке запускает `npm install` и произвольные скрипты сборки — код, который вы не писали, выполняющийся с привилегиями времени сборки, — и делать это на общем хосте без изоляции — это одна атака через подмену зависимостей от того, чтобы затронуть данные другого арендатора. Быстрый-но-небезопасный вариант был доступен. Просто это была не та сделка, на которую стоило идти.
Та же история с верификацией. Готовая сборка покидает конвейер не тогда, когда останавливается генерация, а тогда, когда набор независимых верификаторов перестаёт находить что-то, что стоит блокировать:
- Код-ревью
- Безопасность
- Ссылки и SEO
- Доступность
- Соответствие
- Реальный запуск в браузере
Это не один проход, а цикл флаг-исправление-перепроверка, который повторяется, пока никому больше нечего сказать, потому что один проход линтера может пропустить регрессию, которую вносит его собственное исправление. Исправление битой ссылки и случайная поломка иерархии заголовков на той же странице — это как раз то, что упускает разовая проверка и ловит повторная. Честная цена этого цикла — иногда сборка занимает на минуту дольше прямо в конце без видимой причины. Люди замечают эту минуту. Они не замечают шесть агентов, которые только что закончили спорить о своём сайте. Это справедливая жалоба на впечатление от процесса — просто я не считаю это хорошим аргументом в пользу выпуска без того, чтобы этот спор вообще состоялся.
