План, який ви пропускаєте, — це збій, який ви потім налагоджуватимете
Кожен фреймворк у розробці програмного забезпечення каже вам рухатися швидко, випускати рано, ітерувати вже в продакшені. Для сайтів, згенерованих ШІ, це діє навпаки. Білдер тут відмовляється стрімити код прямо з вашого запиту — він зупиняється, пише план і чекає, поки ви на нього подивитеся — і саме ця відмова є тим єдиним рішенням, на якому побудовано все інше в цьому конвеєрі. Повільніше на старті, дешевше на кожному наступному етапі. Я обираю цей компроміс щоразу, і думаю, що більшість тих, хто аргументує протилежне, насправді не бачили, у що обходиться неправильне припущення далі за конвеєром.
Ось сценарій збою, який план покликаний запобігти. Ви пишете «сайт для запису клієнтів моєї студії» і натискаєте «Створити». Системі потрібно вгадати, що означає «запис» — віджет календаря, вбудований сторонній сервіс чи справжня система бронювання з перевіркою конфліктів — і вгадати це ще до того, як щось написано, бо іншого порядку дій просто немає. Помилитися в плані — і виправлення займе одне речення, п'ять секунд, готово. Помилитися у вже згенерованому коді — і ви вже не редагуєте речення, а розплутуєте десять файлів, які вже залежать від хибного припущення. Я бачив обидва варіанти. Виправлення на етапі плану — це один обмін репліками. Розворот після генерації на тій самій неоднозначності — це відкинути все й перебудувати заново.
План — це не просто список справ, і саме цей момент часто упускають з виду. Це договір, і система сама його дотримується: верифікатор відповідності, один із агентів, які мають дати схвалення перед випуском збірки, звіряє готовий сайт із затвердженим планом. Чи створено всі заплановані сторінки? Чи відповідає список функцій тому, що реально випущено? «Готово» тут — не відчуття, а стан відносно письмової обіцянки, який можна перевірити рядок за рядком. Це сильніша гарантія, ніж «код працює», і ви отримуєте її лише тому, що є документ, з яким можна звіритися. Приберіть план — і приберете мірило.
Де це справді окупається
Ваш вплив як людини, що керує збіркою, зосереджений на початку — незалежно від того, користуєтеся ви ним чи ні. Якщо вам важлива інформаційна архітектура, структура сторінок, які функції потраплять у v1, а які у v2 — ця прискіпливість коштує вдесятеро більше під час перегляду плану, ніж після першого проходу генерації. Чотири зайві хвилини на повторне прочитання плану кращі за цілий цикл виправлення збірки, яка вже пішла не так.
Найяскравіший приклад — тип продукту: звичайний статичний сайт, встановлюваний застосунок, збірка на фреймворку, застосунок із серверним бекендом та реальним збереженням даних. Виглядає як випадаючий список. Але це не так. Це найструктурніший вибір у всьому процесі, бо він непомітно визначає десяток речей, які не мають нічого спільного з тим, як виглядає сайт.
| Тип продукту | Попередній перегляд | Опублікувати | Облікові записи / база даних |
|---|---|---|---|
| Звичайний статичний сайт | Миттєво, бо це просто статичні файли | Статичний результат копіюється без проблем | Неможливо — запит на вхід у систему — це запит на те, чого цей тип структурно не може виконати |
| Збірка на фреймворку | Спочатку компілюється; зламана збірка виглядає як «немає попереднього перегляду», а не «зламана сторінка» | Такий самий чистий шлях статичного копіювання, але вже після компіляції | Неможливо |
| Застосунок із серверним бекендом | — | Потребує місця для фактичного запуску процесу, тому й ламається інакше — це збій процесу, а не відсутній файл | Єдиний тип, у якому взагалі існують облікові записи й бази даних |
І ви не можете просто так перейти на інший тип пізніше. Перехід від звичайного сайту до застосунку з серверним бекендом — це не перемикач у налаштуваннях, а майже друга збірка, бо половина припущень плану (як завантажуються сторінки, де зберігаються дані, що означає «опублікувати») були зроблені під старий тип. Тож скажіть про це вже на етапі планування, навіть якщо не впевнені до кінця: «є ймовірність, що мені знадобляться облікові записи». Спланувати застосунок із серверним бекендом і використати лише статичну частину не коштує нічого. Виявити потребу в ньому вже потім — коштує повної перебудови.
У чому критики мають рацію
Ніщо з цього не безкоштовне, і я не вдаватиму, що це так. Ізольовані робочі простори для кожного запуску означають, що ваші файли зі знаннями копіюються заново, нічого не повертається назад на ваш комп'ютер — добре для вас, якщо ваш ноутбук вимкнеться посеред збірки, погано для швидкості, бо розгортання робочого простору й, для збірок на фреймворках, реальне встановлення залежностей усередині контейнерної ізоляції займає реальний час. Ця контейнерна межа існує тому, що збірка на фреймворку виконує `npm install` та довільні скрипти збірки — код, який ви не писали, виконуючи з привілеями часу збірки — і робити це на спільному хості без ізоляції означає бути за одну атаку типу dependency confusion від того, щоб торкнутися даних іншого клієнта. Швидкий-але-небезпечний варіант був доступний. Просто це не той компроміс, на який варто йти.
Та сама історія з верифікацією. Готова збірка виходить із конвеєра не тоді, коли зупиняється генерація, а тоді, коли набір незалежних верифікаторів перестає знаходити щось варте блокування:
- Огляд коду
- Безпека
- Посилання та SEO
- Доступність
- Відповідність
- Реальний запуск у браузері
Це не один прохід, а цикл «позначити-виправити-перевірити знову», що триває, доки нікому вже нема чого сказати, бо один прохід лінтера може пропустити регресію, спричинену його ж власним виправленням. Виправити зламане посилання й випадково зламати ієрархію заголовків на тій самій сторінці — це якраз те, що пропускає одноразова перевірка, але вловлює повторна. Чесна ціна цього циклу — збірка, яка інколи займає зайву хвилину саме наприкінці без видимої причини. Люди помічають цю хвилину. Вони не помічають шість агентів, які щойно закінчили сперечатися про їхній сайт. Це справедлива скарга щодо досвіду користування — просто я не вважаю це вагомим аргументом на користь випуску без того, щоб ця суперечка взагалі відбулася.
