Co naprawdę kryje się w aplikacji zbudowanej z AI: przewodnik dla nieprogramistów
Jeśli wypuściłeś coś za pomocą kreatora aplikacji z AI i chcesz zrozumieć, na co właściwie patrzysz, oto przyjazny przewodnik po poszczególnych częściach — bez żargonu.
Wpisałeś opis, kliknąłeś „start”, a dwadzieścia minut później miałeś działającą aplikację. Świetnie. Tyle że teraz kliknąłeś „pokaż pliki” i wpatrujesz się w drzewo folderów, które wygląda, jakby ktoś napisał je w innym języku. Co to jest package.json? Dlaczego w node_modules jest czterdzieści różnych rzeczy? Co znaczy „schema” i dlaczego ją masz?
Ten wpis to przewodnik. Nie tutorial — przewodnik. Po jego przeczytaniu nadal nie będziesz umiał samodzielnie napisać żadnego z tych plików, ale następnym razem, gdy coś wyda Ci się dziwne, będziesz wiedział, na który zakątek aplikacji wskazać.
Posłużę się trzema przykładami, które przewiną się przez cały tekst, żeby abstrakcyjne części miały do czego się przyczepić:
- Maya, liderka marketingu, która zbudowała ranking poleceń dla swojego zespołu.
- Jordan, nauczyciel jogi, który zbudował stronę do rezerwacji zajęć.
- Sam, właściciel piekarni, który zbudował stronę „zamów jutrzejsze rogaliki z wyprzedzeniem”.
Cała trójka skorzystała z kreatora aplikacji z AI. Dla klienta wszystkie trzy aplikacje wyglądają zupełnie inaczej. Pod maską mają zaskakująco podobną budowę.
Frontend: to, co faktycznie widzi Twój klient
Frontend to wszystko, co ładuje się w czyjejś przeglądarce. Przyciski, układy, czcionki, animacje, sposób, w jaki formularz sam się czyści po wysłaniu. Jeśli to widzisz, to jest to frontend.
Dla Mayi frontend to ranking z miejscem, nazwiskiem i liczbą poleceń. Dla Jordana to kalendarz zajęć z przyciskiem „zarezerwuj”. Dla Sama to lista wypieków z małymi przyciskami plus i minus obok każdej pozycji.
Wewnątrz projektu frontend zwykle mieszka w folderze nazwanym mniej więcej app/, pages/ albo src/. Zobaczysz tam pliki kończące się na .tsx lub .jsx. Każdy z nich to z grubsza „jeden ekran” albo „jeden fragment ekranu”. Wiersz rankingu to jeden plik. Nagłówek to kolejny plik. Strona, która spina to wszystko w całość, to trzeci.
Kiedy prosisz kreator AI, żeby „zaokrąglił przyciski” albo „przeniósł ranking na prawo”, to właśnie ta część się zmienia.
Backend: część, która myśli
Backend to część, której nikt nie widzi, ale od której wszyscy zależą. To kod, który działa gdzieś indziej — na serwerze, a nie w przeglądarce klienta — wtedy, gdy musi się wydarzyć coś, czego nie można powierzyć samej przeglądarce klienta.
Dlaczego przeglądarka nie może zrobić wszystkiego? Bo przeglądarka to maszyna klienta, a jej nie można ufać. Gdyby ranking Mayi aktualizował liczbę poleceń wyłącznie w przeglądarce, każdy mógłby kliknąć prawym przyciskiem i dopisać sobie 9000 poleceń. Dlatego backend to miejsce, gdzie mieszkają zasady: „ta osoba może to, ale tamtego nie”, „zapisz to faktycznie do bazy danych”, „wyślij ten e-mail”.
Backend zwykle mieszka w folderze nazwanym api/, server/ albo app/api/. Pliki tam są zazwyczaj krótkie. Każdy obsługuje konkretne żądanie: „utwórz rezerwację”, „wypisz dzisiejsze rogaliki”, „dodaj polecenie”.
Kiedy coś w Twojej aplikacji działa, ale wynik się nie zapisuje — klikasz wyślij, widzisz potwierdzenie, ale następnego dnia dane zniknęły — błąd prawie zawsze siedzi w backendzie.
Baza danych: pamięć Twojej aplikacji
Wyobraź sobie pamięć aplikacji jako rząd szafek na dokumenty. Każda szafka ma z przodu etykietę. Jedna mówi „users”. Inna mówi „bookings”. Jeszcze inna „croissant_orders”. W każdej szafce każda szuflada to jeden wiersz. Każda szuflada ma ten sam zestaw przegródek: nazwę, e-mail, created_at, status.
Ta struktura — „jakie szafki istnieją, jakie przegródki ma każdy wiersz” — nazywa się schemą. To najważniejszy plik w projekcie, mimo że wygląda też pewnie na najnudniejszy. Znajdź plik o nazwie schema.ts, schema.prisma albo coś wewnątrz folderu db/ lub migrations/. Otwórz go. Zobaczysz listę, która odzwierciedla to, co Twoja aplikacja faktycznie zapamiętuje o świecie.
Schema Jordana ma tabelę classes, tabelę bookings i tabelę users. Sam ma products, orders i order_items. Maya ma members i referrals. Kształt schemy to kształt produktu — i dlatego zmiana jej później jest trudniejsza niż zmiana wyglądu przycisków.
Przydatna sztuczka: jeśli umiesz opisać prostymi słowami, co Twoja aplikacja zapamiętuje, zwykle umiesz też opisać schemę. „Pamiętam imię i e-mail każdego klienta. Dla każdego klienta pamiętam złożone przez niego zamówienia. Dla każdego zamówienia pamiętam, które wypieki i po ile sztuk”. To zdanie to, niemal słowo w słowo, schema.
Auth: bramkarz przy drzwiach
„Auth” to dwa zlepione słowa: authentication (uwierzytelnianie — kim jesteś?) oraz authorization (autoryzacja — co wolno Ci robić?). Oba zwykle obsługuje niewielki zestaw plików w folderze auth/ albo usługa, której nazwę możesz znać: Clerk, Auth0, Supabase Auth, NextAuth.
Te dwa pytania są różne. Uwierzytelnianie odpowiada: „czy to naprawdę Maya?” — zwykle za pomocą hasła, logowania przez Google albo magicznego linka wysłanego jej mailem. Autoryzacja odpowiada: „czy Maya może usuwać cudze polecenia?” — a szczera odpowiedź w przypadku większości aplikacji zbudowanych z AI w pierwszym tygodniu brzmi: „zapomnieliśmy to sprawdzić”.
To część, która najczęściej jest po cichu zepsuta. Ekran logowania działa, więc wszystko wydaje się bezpieczne. Ale backend nie zawsze sprawdza, czy zalogowana osoba jest tą samą osobą, której dane próbuje odczytać. Jeśli Twoja aplikacja ma jakiekolwiek pojęcie „moje dane kontra Twoje dane”, poproś kreator AI wprost: „Upewnij się, że użytkownicy widzą i mogą edytować tylko własne dane”. Zdziwisz się, jak często to jedno zdanie odsłania brakującą kontrolę.
Integracje: rzeczy, których nie zbudowałeś, a i tak ich używasz
Tutaj większość nieprogramistów nie docenia tego, co naprawdę się dzieje. To, co wysyła Samowi e-mail „Twoje rogaliki są gotowe”, to nie kod — to konto w SendGridzie albo Resend. To, co przetwarza płatność za zajęcia Jordana, to nie kod — to Stripe. To, co hostuje zdjęcia w rankingu Mayi, to nie kod — to usługa przechowywania plików, jak S3 czy Cloudinary.
Każda integracja pojawia się w dwóch miejscach. W backendzie jest niewielki kawałek kodu, który mówi „hej Stripe, obciąż tę kartę”. I jest klucz — długi, tajny ciąg znaków — przechowywany gdzieś w bezpiecznym miejscu (zwykle w pliku .env, którego nikt nigdy nie powinien commitować), który dowodzi Stripe’owi, że żądanie pochodzi z piekarni Sama, a nie od obcej osoby.
Jeśli kiedykolwiek zastanawiasz się, dlaczego Twoja aplikacja nagle przestaje wysyłać e-maile albo przyjmować płatności, przyczyną jest niemal zawsze jedna z trzech rzeczy: wygasły klucz, osiągnięty limit użycia albo zmiana zasad integracji. Kod się nie zepsuł. Zepsuł się uścisk dłoni.
Deploy: jak to trafia do internetu
Ostatni element to część, która zamienia folder na Twoim dysku w coś, co Twój klient może odwiedzić pod adresem URL. Zwykle oznacza to współdziałanie trzech drobnych rzeczy:
- Host: usługa taka jak Vercel, Netlify, Fly czy Render, która uruchamia Twój backend i serwuje Twój frontend.
- Domena: nazwa w rodzaju
mayas-leaderboard.com, która wskazuje na Twój host. - Build: przepis, który bierze Twoje rozgardiaszowe pliki źródłowe i zamienia je w szczuplejszą, szybszą wersję, która faktycznie działa.
Kiedy coś działa lokalnie, ale psuje się na produkcji, kłopot zwykle siedzi tutaj. Klucz, który jest ustawiony na Twoim laptopie, ale nie na hoście. Biblioteka zainstalowana w środowisku deweloperskim, ale nie na produkcji. Baza danych, która istnieje w Twojej przeglądarce, ale nie na działającej stronie.
Pięciominutowy nawyk, który sam się zwraca
Nie musisz czytać każdego pliku w swoim projekcie. Nie musisz wiedzieć, co robi większość z nich. Ale raz w tygodniu powinieneś zrobić pięciominutowy obchód, podczas którego otwierasz każdy z powyższych folderów i pytasz kreator AI, prostymi słowami, co się zmieniło.
Maya robi to w każdy piątek po południu. Wpisuje: „Co zmieniło się w schemie w tym tygodniu i dlaczego?”. Oraz: „Czy w tej aplikacji są jakieś nowe integracje, o które nie prosiłam?”. Odpowiedzi prawie zawsze są uspokajające. Te nieliczne razy, gdy nie są, pozwalają jej wyłapać problemy, póki są jeszcze małe.
O to właśnie chodzi w zrozumieniu poszczególnych części. Nie po to, żeby zostać programistą. Po prostu po to, żeby umieć zadawać lepsze pytania.
Co dalej
Jeśli ten przewodnik pomógł, dwie kontynuacje warte są Twojego czasu. Błąd „wygląda dobrze” opisuje, co robić, gdy któraś z tych części jest po cichu zepsuta, a gotowe na demo kontra gotowe na produkcję opisuje, jak rozpoznać, że Twoja aplikacja przeszła z pierwszego etapu do drugiego. Ta sama mapa, tylko inne zastosowania.