Чому ваш конструктор застосунків на ШІ спершу показує фейкові дані (і чому це правильний хід)
Якщо ваш конструктор застосунків на ШІ заповнює екрани вигаданими користувачами й зразковими замовленнями, перш ніж торкнутися бази даних, це не скорочення — це правильний спосіб будувати. Ось чому.
Ви описуєте застосунок своєму конструктору на ШІ. За хвилину ви дивитеся на робочий інтерфейс — сторінки, кнопки, таблиця користувачів із іменами на кшталт «Алекс Рівера» й «Прія Шах», ціни, що не мають сенсу, «Pro Plan», якого ви не просили. Нічого не збережено. Якщо ви оновите, дані все ще там. Якщо ви додасте нового користувача, він зникає.
Це виглядає як фокус, що от-от розсиплеться. Це не так. Це хороша частина побудови. Мок-дані на вашому екрані — це навмисний перший крок, і це причина, чому база даних, що йде далі, справді відповідатиме застосунку, який ви хотіли.
Що насправді означає «спершу фейкові дані»
Коли конструктор застосунків на ШІ бере ваш бриф, він не йде прямо до бази даних. Хороший спершу пише екрани, заповнює їх правдоподібними даними-заповнювачами, а потім — і лише потім — проєктує базу даних, щоб відповідати.
Дані-заповнювачі — не декорація. Це контракт. Щойно ваш застосунок каже «кожне замовлення має ім’я клієнта, три позиції, суму й статус», база даних, що будується далі, має мати точно ці речі, точно в цих формах. Екрани вирішують, як виглядають дані, а не навпаки.
Це навспак від того, як зазвичай починав би людина-розробник. Традиційний розробник проєктує спершу базу даних, потім будує екрани під неї. Конструктори на ШІ перевернули це, і більшість людей не помічає — вони просто бачать фейкових користувачів і припускають, що конструктор фейкує.
Чому цей порядок працює краще зі ШІ
Ми пробували будувати базу даних та екрани одночасно. Це не спрацювало. Ось коротка версія чому.
Коли два ШІ-агенти працюють над різними частинами застосунку, не бачачи виводу одне одного, вони роблять несумісні здогадки. Агент інтерфейсу вирішує, що в користувачів є поле «name». Агент бази даних вирішує, що в користувачів є поле «fullName». Обидва виглядають правильно. Разом нічого не працює. Третій агент залучається залатати невідповідність. Він теж здогадується. Тепер на волі три здогадки, а застосунок, який ви переглядаєте, — якийсь Франкенштейн з усіх них.
Виправлення майже ніякове: зробіть спершу одне, потім інше. Інтерфейс будується. Він записує, які дані йому потрібні, як єдиний файл фейкових користувачів, фейкових замовлень, фейкового чого-там-ваш-застосунок-про. Агент бази даних читає цей файл і відповідає йому поле за полем. Жодних здогадок. Жодних переговорів. Жодної невідповідності.
Ось чому ваш конструктор застосунків на ШІ може показати вам застосунок, що виглядає готовим, за хвилину. Він не сфейкував побудову. Він зробив чверть побудови — частину, що вирішує все інше, — а база даних — це наступні десять секунд роботи, а не наступні десять годин.
На що дивитися, коли фейкові дані на екрані
Це момент, який більшість людей проскакує. Вони бачать дані-заповнювачі й починають просити зміни кольорів. Але дані-заповнювачі — це запитання, поставлене вам. Прочитайте його.
Кілька прикладів того, на що звертати увагу:
- Неправильна термінологія. Застосунок, який ви хотіли, відстежує «відвантаження». Дані-заповнювачі називають їх «замовлення». Скажіть конструктору. Якщо ви це зараз пропустите, кожен екран, кожне поле бази даних, кожен звіт використовуватимуть неправильне слово — а перейменування потім — не однокліковa операція в жодному інструменті, хай би що казав маркетинг.
- Відсутні поля. Фейковий рахунок має суму й дату. Вам також потрібен номер замовлення (PO). Краще додати це зараз, коли на екрані п’ять мок-рахунків, ніж після того, як базу даних збудовано й засіяно справжніми даними клієнтів.
- Неправильні форми. Мок-дані показують «1 клієнт, 1 адреса». Ваші справжні клієнти мають кілька адрес. Конструктор не може це вивести з вашого брифа. Скажіть йому зараз, поки зміна форми коштує нуль.
- Несподівані сутності. Конструктор винайшов поняття «команда», якого ви не просили, бо припустив багатокористувацький застосунок. Можливо, ви цього хотіли. Можливо, ні. У будь-якому разі вирішіть, перш ніж база даних збудується навколо цього.
Корисне правило: якщо у вашому застосунку є іменник, що не представлений у даних-заповнювачах на екрані, конструктор про нього ще не знає. Згадайте його, перш ніж клікнути «зберегти» на першому попередньому перегляді.
Чому порядок важить для того, що йде далі
Щойно дані-заповнювачі правильні, побудова бази даних механічна. Конструктор читає ваші фейкові дані, генерує схему, що відповідає, пише запити, які екрани вже намагаються викликати, і нарешті замінює імпорти-заповнювачі справжніми. Ті самі екрани, що показували фейкових користувачів, тепер показують те, що ви насправді туди поклали.
Ви зазвичай можете побачити заміну в реальному часі. Сторінка, що завантажувалася миттєво, бо читала локальний файл, тепер має півсекундний стан завантаження — це екран уперше говорить зі справжньою базою даних. Більшість людей це проґавлює й не усвідомлює, що застосунок щойно перетнув лінію від «демо» до «речі, що може зберігати справжні дані».
Причина, чому це взагалі працює, у тому, що все нижче по ланцюжку — проєктування бази даних, запити, стани завантаження, порожні стани — вирішено тим, що ви побачили на екрані під час фази заповнювачів. Якщо ви схвалили три колонки, ви отримуєте три колонки. Якщо ви схвалили поле «статус» зі значеннями «чернетка» й «надіслано», саме це база даних приймає. Немає другого кроку перекладу, де передача від дизайнера-розробника щось спотворює.
Маленький тест, який ви можете запустити
Наступного разу, коли ви щось будуєте, спробуйте таке: коли з’являться дані-заповнювачі, змініть одну річ у них, перш ніж просити будь-що інше. Перейменуйте поле. Додайте колонку. Замініть «users» на «members». Потім подивіться, що станеться, коли база даних збудується.
Ви побачите, як зміна з’явиться скрізь — у проєктуванні бази даних, у запитах, у даних-сидах, які конструктор покладе, коли застосунок готовий. Одне слово на стадії заповнювачів прокотилося крізь увесь застосунок. Це важіль, який у вас є під час цієї фази, і це причина, чому «спершу фейкові дані» — не трюк зрізання кутів. Це місце, де застосунок насправді вирішується.
Якщо хочете заглибитися, наш минулий допис про те, що насправді всередині застосунку на ШІ проводить рухомими частинами, яких ви не бачите з першого погляду. Патерн той самий: більшість важеля — у частинах, що виглядають так, ніби не мають значення.