Dlaczego kreator aplikacji z AI najpierw pokazuje Ci fałszywe dane (i dlaczego to dobry ruch)
Jeśli Twój kreator aplikacji z AI zapełnia ekrany wymyślonymi użytkownikami i przykładowymi zamówieniami, zanim w ogóle dotknie bazy danych, to nie skrót — to właściwy sposób budowania. Oto dlaczego.
Opisujesz aplikację swojemu kreatorowi aplikacji z AI. Minutę później patrzysz na działający interfejs — strony, przyciski, tabelę użytkowników o nazwiskach w stylu „Alex Rivera” i „Priya Shah”, ceny, które nie mają sensu, „Plan Pro”, o który nie prosiłeś. Nic nie jest zapisywane. Jeśli odświeżysz, dane wciąż tam są. Jeśli dodasz nowego użytkownika, znika.
Wygląda to jak sztuczka magiczna, która zaraz się rozsypie. Wcale nie. To dobra część budowy. Atrapy danych na Twoim ekranie to celowy pierwszy krok i właśnie dlatego baza danych, która powstaje później, faktycznie będzie pasować do aplikacji, jakiej chciałeś.
Co naprawdę znaczy „najpierw fałszywe dane”
Kiedy kreator aplikacji z AI przyjmuje Twój brief, nie idzie prosto do bazy danych. Dobry kreator najpierw pisze ekrany, zapełnia je wiarygodnymi danymi zastępczymi, a dopiero potem — i tylko wtedy — projektuje bazę danych, żeby do nich pasowała.
Dane zastępcze to nie dekoracja. To umowa. Gdy Twoja aplikacja mówi „każde zamówienie ma nazwisko klienta, trzy pozycje, sumę i status”, baza danych, która powstaje w następnej kolejności, musi mieć dokładnie te rzeczy, w dokładnie tych kształtach. To ekrany decydują, jak wyglądają dane, a nie odwrotnie.
To odwrotnie niż zwykle zaczynałby człowiek-programista. Tradycyjny programista najpierw projektuje bazę danych, a potem buduje ekrany w oparciu o nią. Kreatory AI to odwróciły i większość ludzi tego nie zauważa — widzą tylko fałszywych użytkowników i zakładają, że kreator oszukuje.
Dlaczego ta kolejność działa lepiej z AI
Próbowaliśmy budować bazę danych i ekrany jednocześnie. Nie zadziałało. Oto krótka wersja, dlaczego.
Kiedy dwóch agentów AI pracuje nad różnymi częściami aplikacji, nie widząc nawzajem swoich wyników, robią niekompatybilne założenia. Agent od interfejsu decyduje, że użytkownicy mają pole „name”. Agent od bazy danych decyduje, że użytkownicy mają pole „fullName”. Oba wyglądają poprawnie. Razem nic nie działa. Sprowadza się trzeciego agenta, żeby załatał niezgodność. On też zgaduje. Teraz na wolności są trzy domysły, a aplikacja, którą podglądasz, to jakiś Frankenstein zlepiony ze wszystkich.
Rozwiązanie jest niemal zawstydzające: zrób najpierw jedno, potem drugie. Interfejs zostaje zbudowany. Zapisuje, jakich danych potrzebuje, w postaci jednego pliku fałszywych użytkowników, fałszywych zamówień, fałszywego czegokolwiek, o co chodzi w Twojej aplikacji. Agent od bazy danych czyta ten plik i dopasowuje się pole po polu. Bez domysłów. Bez negocjacji. Bez niezgodności.
Dlatego Twój kreator aplikacji z AI potrafi pokazać Ci wyglądającą na gotową aplikację w minutę. Nie sfałszował budowy. Wykonał jej jedną czwartą — tę część, która decyduje o całej reszcie — a baza danych to kolejne dziesięć sekund pracy, nie kolejne dziesięć godzin.
Na co zwracać uwagę, gdy fałszywe dane są na ekranie
To moment, który większość ludzi pomija. Widzą dane zastępcze i zaczynają prosić o zmiany kolorów. Ale dane zastępcze to pytanie zadawane Tobie. Przeczytaj je.
Kilka przykładów, na co uważać:
- Złe słownictwo. Aplikacja, jakiej chciałeś, śledzi „przesyłki”. Dane zastępcze nazywają je „zamówieniami”. Powiedz to kreatorowi. Jeśli teraz to przepuścisz, każdy ekran, każde pole bazy danych, każdy raport będzie używać złego słowa — a zmiana nazwy później to w żadnym narzędziu nie jest operacja na jedno kliknięcie, cokolwiek mówi marketing.
- Brakujące pola. Fałszywa faktura ma sumę i datę. Potrzebujesz też numeru zamówienia. Lepiej dodać go teraz, gdy na ekranie jest pięć atrap faktur, niż po tym, jak baza danych zostanie zbudowana i zasiana prawdziwymi danymi klientów.
- Złe kształty. Atrapy danych pokazują „1 klient, 1 adres”. Twoi rzeczywiści klienci mają wiele adresów. Kreator nie wywnioskuje tego z Twojego briefu. Powiedz mu teraz, kiedy zmiana kształtu nic nie kosztuje.
- Zaskakujące byty. Kreator wymyślił koncepcję „zespołu”, o którą nie prosiłeś, bo założył aplikację wieloosobową. Może tego chciałeś. Może nie. Tak czy inaczej zdecyduj, zanim baza danych zostanie wokół tego zbudowana.
Przydatna zasada: jeśli w Twojej aplikacji jest rzeczownik, którego nie ma w danych zastępczych na ekranie, kreator jeszcze o nim nie wie. Wspomnij o nim, zanim klikniesz „zapisz” przy pierwszym podglądzie.
Dlaczego kolejność ma znaczenie dla tego, co przychodzi później
Gdy dane zastępcze są już właściwe, budowa bazy danych jest mechaniczna. Kreator czyta Twoje fałszywe dane, generuje pasujący schemat, pisze zapytania, które ekrany już próbują wywoływać, i na koniec podmienia importy danych zastępczych na prawdziwe. Te same ekrany, które pokazywały fałszywych użytkowników, teraz pokazują to, co faktycznie wpiszesz.
Zwykle widzisz tę podmianę na żywo. Strona, która ładowała się natychmiast, bo czytała lokalny plik, ma teraz półsekundowy stan ładowania — to ekran rozmawiający z prawdziwą bazą danych po raz pierwszy. Większość ludzi tego nie zauważa i nie zdaje sobie sprawy, że aplikacja właśnie przekroczyła granicę między „demem” a „rzeczą, która potrafi przechowywać prawdziwe dane”.
Powód, dla którego to w ogóle działa, jest taki, że wszystko, co dalej — projekt bazy danych, zapytania, stany ładowania, stany pustki — zostało zdecydowane przez to, co zobaczyłeś na ekranie w fazie danych zastępczych. Jeśli zaakceptowałeś trzy kolumny, dostajesz trzy kolumny. Jeśli zaakceptowałeś pole „status” z wartościami „draft” i „sent”, to dokładnie to przyjmuje baza danych. Nie ma drugiego kroku tłumaczenia, w którym przekazanie pracy między projektantem a programistą coś psuje.
Mały test, który możesz zrobić
Następnym razem, gdy coś budujesz, spróbuj tego: gdy pojawią się dane zastępcze, zmień jedną rzecz, zanim poprosisz o cokolwiek innego. Zmień nazwę pola. Dodaj kolumnę. Zamień „users” na „members”. A potem obserwuj, co się dzieje, gdy budowana jest baza danych.
Zobaczysz, że zmiana pojawia się wszędzie — w projekcie bazy danych, w zapytaniach, w danych zasiewu, które kreator wprowadza po ukończeniu aplikacji. Jedno słowo na etapie danych zastępczych przeszło falą przez całą aplikację. To dźwignia, którą masz w tej fazie, i powód, dla którego „najpierw fałszywe dane” nie jest chodzeniem na skróty. To miejsce, w którym aplikacja faktycznie się decyduje.
Jeśli chcesz wejść głębiej, nasz poprzedni wpis o tym, co naprawdę kryje się w aplikacji zbudowanej z AI przeprowadza przez pozostałe ruchome części, których na pierwszy rzut oka nie widać. Wzorzec jest ten sam: większość dźwigni tkwi w tych częściach, które wyglądają, jakby nie miały znaczenia.