Почему ИИ-конструктор приложений сначала показывает вам выдуманные данные (и почему это правильно)
Если ваш ИИ-конструктор приложений заполняет экраны выдуманными пользователями и тестовыми заказами ещё до того, как притронется к базе данных, — это не уловка, а правильный способ собирать приложения. Вот почему.
Вы описываете приложение своему ИИ-конструктору приложений. Через минуту перед вами рабочий интерфейс — страницы, кнопки, таблица пользователей с именами вроде «Alex Rivera» и «Priya Shah», цены, которые ни о чём не говорят, какой-то «Pro Plan», который вы не просили. Ничего не сохраняется. Если обновить страницу, данные всё ещё на месте. Если добавить нового пользователя, он пропадает.
Похоже на фокус, который вот-вот развалится. Это не так. Это хорошая часть сборки. Тестовые данные на экране — продуманный первый шаг, и именно благодаря им база данных, которая появится дальше, действительно совпадёт с тем приложением, которое вы хотели.
Что на самом деле значит «сначала выдуманные данные»
Когда ИИ-конструктор приложений берёт ваше описание, он не идёт сразу к базе данных. Хороший конструктор сначала пишет экраны, заполняет их правдоподобными данными-заглушками и только потом — и только тогда — проектирует базу данных под них.
Данные-заглушки — это не украшение. Это контракт. Как только приложение заявляет: «у каждого заказа есть имя клиента, три позиции, итоговая сумма и статус», — база данных, которая создаётся следующей, обязана содержать ровно эти поля, ровно в такой форме. Экраны решают, как выглядят данные, а не наоборот.
Это противоположно тому, с чего обычно начал бы человек-разработчик. Традиционный разработчик сначала проектирует базу данных, а потом строит под неё экраны. ИИ-конструкторы перевернули этот порядок, и большинство людей этого не замечают — они просто видят выдуманных пользователей и решают, что конструктор всё подделывает.
Почему этот порядок лучше работает с ИИ
Мы пробовали собирать базу данных и экраны одновременно. Не сработало. Вот краткая версия почему.
Когда два ИИ-агента работают над разными частями приложения и не видят результат друг друга, они делают несовместимые предположения. Агент интерфейса решает, что у пользователей есть поле «name». Агент базы данных решает, что у пользователей есть поле «fullName». Оба выглядят правильно. Вместе — не работает ничего. Подключают третьего агента, чтобы залатать несостыковку. Он тоже угадывает. И вот уже три догадки на свободе, и приложение, которое вы видите в превью, — это какой-то Франкенштейн из всех трёх.
Решение почти неловкое: сделай сначала одно, потом другое. Сначала собирается интерфейс. Он записывает, какие данные ему нужны, в один файл выдуманных пользователей, выдуманных заказов, выдуманного чего-угодно-про-что-ваше-приложение. Агент базы данных читает этот файл и подгоняет всё поле в поле. Никаких догадок. Никаких переговоров. Никаких несостыковок.
Вот почему ваш ИИ-конструктор приложений может показать вам приложение, выглядящее готовым, уже через минуту. Он не подделал сборку. Он сделал четверть сборки — ту часть, которая определяет всё остальное, — а база данных — это следующие десять секунд работы, а не следующие десять часов.
На что смотреть, когда выдуманные данные на экране
Этот момент большинство людей проскакивают. Они видят данные-заглушки и начинают просить поменять цвета. Но данные-заглушки — это вопрос, который вам задают. Прочитайте его.
Несколько примеров того, на что обращать внимание:
- Неправильная лексика. Приложение, которое вы хотели, отслеживает «отгрузки». А данные-заглушки называют их «заказами». Скажите об этом конструктору. Если сейчас спустить это на тормозах, то каждый экран, каждое поле базы данных, каждый отчёт будут использовать неправильное слово — а переименовать потом не получится в один клик ни в одном инструменте, что бы ни обещал маркетинг.
- Недостающие поля. В выдуманном счёте есть сумма и дата. Вам ещё нужен номер заказа (PO). Лучше добавить его сейчас, когда на экране пять тестовых счетов, чем после того, как база данных будет создана и наполнена реальными клиентскими данными.
- Неправильная форма данных. Тестовые данные показывают «1 клиент, 1 адрес». А у ваших реальных клиентов несколько адресов. Конструктор не может вывести это из вашего описания. Скажите ему сейчас, пока изменение формы ничего не стоит.
- Неожиданные сущности. Конструктор придумал понятие «команда», о котором вы не просили, потому что предположил, что приложение многопользовательское. Может, вам это и нужно. А может, нет. В любом случае решите это до того, как база данных будет построена вокруг этого.
Полезное правило: если в вашем приложении есть существительное, которого нет в данных-заглушках на экране, значит, конструктор о нём ещё не знает. Упомяните его до того, как нажмёте «сохранить» на первом превью.
Почему порядок важен для того, что будет дальше
Как только данные-заглушки верны, сборка базы данных становится механической. Конструктор читает ваши выдуманные данные, генерирует подходящую под них схему, пишет запросы, которые экраны уже пытаются вызывать, и в конце подменяет импорты заглушек на настоящие. Те же экраны, что показывали выдуманных пользователей, теперь показывают всё, что вы реально внесёте.
Обычно эту подмену видно в реальном времени. Страница, которая загружалась мгновенно, потому что читала локальный файл, теперь получает полусекундное состояние загрузки — это экран впервые обращается к настоящей базе данных. Большинство людей это пропускают и не осознают, что приложение только что пересекло черту от «демо» к «штуке, которая может хранить реальные данные».
Всё это вообще работает потому, что всё, что идёт дальше — проектирование базы данных, запросы, состояния загрузки, пустые состояния, — было определено тем, что вы видели на экране на этапе заглушек. Если вы утвердили три столбца, вы получите три столбца. Если вы утвердили поле «status» со значениями «draft» и «sent», именно это база данных и примет. Нет второго этапа перевода, на котором передача от дизайнера к разработчику всё бы исказила.
Маленький тест, который вы можете провести
В следующий раз, когда будете что-то собирать, попробуйте вот что: когда появятся данные-заглушки, измените в них одну вещь, прежде чем просить о чём-либо ещё. Переименуйте поле. Добавьте столбец. Замените «users» на «members». А потом посмотрите, что произойдёт, когда соберётся база данных.
Вы увидите, как это изменение проявится везде — в проектировании базы данных, в запросах, в начальных данных (seed), которые конструктор закладывает, когда приложение готово. Одно слово на этапе заглушек прокатилось волной по всему приложению. Вот тот рычаг, что у вас есть на этом этапе, и именно поэтому «сначала выдуманные данные» — не способ срезать угол. Это место, где приложение на самом деле и решается.
Если хотите копнуть глубже, наш прошлый пост о том, что на самом деле внутри приложения, созданного с ИИ, разбирает другие движущиеся части, которые с первого взгляда не видны. Закономерность та же: бо́льшая часть рычага — в тех частях, которые выглядят так, будто они не имеют значения.