Lovable, aplikacja z promptu i jej granice

Lovable, czyli aplikacja opisana zdaniem

Narzędzia budujące aplikacje z opisu w języku naturalnym przeszły drogę od ciekawostki do rzeczy, którą da się użyć do prototypu pokazanego klientowi. Lovable jest jednym z tych, które tę drogę przeszły najdalej.

Opisujesz, co ma robić aplikacja, a narzędzie generuje front w Reakcie ze stylami, podłącza zaplecze z bazą i uwierzytelnianiem i wdraża wszystko pod adresem, który da się komuś wysłać. Pierwsza wersja powstaje w kilkanaście minut.

Ten tekst opisuje, co z tego wynika w praktyce: gdzie narzędzie daje najwięcej, gdzie zaczynają się granice i co zrobić, gdy się do nich dojdzie.

Jak to działa

Praca odbywa się w rozmowie. Piszesz, co ma się zmienić, a narzędzie modyfikuje kod i pokazuje wynik na żywo.

Front powstaje w Reakcie ze stylami opartymi o Tailwind CSS, więc wygenerowany kod jest zwykłym kodem, a nie zamkniętym formatem. To ma znaczenie przy pytaniu, co się stanie, gdy narzędzie przestanie wystarczać.

Zaplecze opiera się na bazie z uwierzytelnianiem i magazynem plików, zwykle w wariancie zintegrowanym. Płatności podłącza się przez zewnętrznego dostawcę, a wdrożenie odbywa się na hosting narzędzia albo do własnego repozytorium.

Nowsze wersje dołożyły tryb agentowy, w którym narzędzie samo przegląda kod, planuje wielokrokową zmianę i wykonuje ją, zamiast reagować na pojedyncze polecenia. Przy większych zmianach to różnica między dziesięcioma prośbami a jedną, choć wynik nadal wymaga przejrzenia przed przyjęciem.

Kredyty, czyli o czym trzeba wiedzieć

Rozliczenie opiera się na kredytach, a jedna wiadomość zużywa ich różną liczbę w zależności od złożoności zadania. To najważniejsza rzecz przy planowaniu budżetu i najczęstsze źródło zaskoczenia.

Skala jest przy tym mniejsza, niż większość osób zakłada. Dostawca podaje własne przykłady: zmiana koloru przycisku to pół kredyta, usunięcie stopki dziewięć dziesiątych, dodanie logowania z rejestracją jeden i dwie dziesiąte, a wygenerowanie strony docelowej z obrazami i pięcioma sekcjami niecałe dwa. Pojedyncza wiadomość kosztuje więc rzędu jednego kredyta, a nie kilkudziesięciu. Rachunek robi dopiero powtarzanie: przy pomyłce i poprawianiu w kółko zużycie rośnie szybciej, niż wynikałoby z liczby wiadomości.

Trzy nawyki obniżają to zużycie najbardziej. Pierwszy to opis konkretny zamiast ogólnego: prośba o „lepszy wygląd" daje losową zmianę i drugą próbę, a prośba o zmianę odstępów i kolorystyki nagłówków daje to, o co chodziło.

Drugi to zmiany po jednej. Prośba obejmująca pięć rzeczy naraz kończy się wynikiem, w którym trzy są dobre, a dwie trzeba cofnąć, co znaczy kolejne kredyty.

Trzeci to sprawdzenie po każdej zmianie. Błąd zauważony od razu poprawia się jedną prośbą, a błąd zauważony po pięciu kolejnych zmianach wymaga rozplątywania, bo trzeba najpierw ustalić, który krok go wprowadził.

Ceny

Cennik jest drabinką: w obu planach płatnych wybierasz pułap kredytów, a cena rośnie razem z nim, od stu kredytów aż po dziesięć tysięcy. Przy niższych pułapach Business kosztuje dokładnie dwa razy tyle co Pro za tę samą liczbę kredytów, bo dopłacasz wyłącznie za funkcje organizacyjne, nie za większą pulę. Sama zasada rozliczenia jest przy tym stała: płacisz za kredyty, a nie za czas ani za liczbę projektów.

Praktyczny sposób oszacowania: zbuduj jeden mały projekt na planie darmowym albo najniższym i sprawdź, ile kredytów zużyło dodanie jednej pełnej funkcji. Pomnożenie tej liczby przez planowany zakres daje szacunek bliższy prawdy niż jakikolwiek opis planu.

Jedna rzecz z regulaminu warto mieć w głowie przy planowaniu: kredyty wygasają. Dzienne z planu darmowego nie przechodzą na następny dzień, miesięczne tracą ważność dwa miesiące po przyznaniu, a te dokupione osobno po roku. Kupowanie zapasu na przyszłość nie ma więc sensu poza doładowaniami.

Gdzie leżą granice

Narzędzie tego typu ma przewagę na początku i traci ją w miarę rozrostu projektu. Warto wiedzieć, gdzie ta zmiana następuje.

Do prototypu, strony marketingowej, wewnętrznego narzędzia i pierwszej wersji produktu sprawdza się bardzo dobrze. Zakres jest wtedy niewielki, wymagania proste, a szybkość powstania ważniejsza od struktury kodu, bo część takich projektów i tak zostanie porzucona po tygodniu.

Granica pojawia się przy trzech rzeczach. Pierwsza to złożona logika biznesowa: reguły zależne od wielu warunków, obliczenia wymagające dokładności, procesy wieloetapowe. Opisanie tego zdaniem jest trudniejsze niż napisanie kodu.

Druga to rozmiar. Aplikacja z czterdziestoma ekranami przestaje mieścić się w kontekście, więc zmiana w jednym miejscu potrafi zepsuć inne, a narzędzie tego nie zauważy.

Trzecia to wymagania niefunkcjonalne: wydajność przy dużym ruchu, dostępność dla czytników ekranu, zgodność z regulacjami. To rzeczy, o które trzeba zapytać wprost, a i wtedy wynik wymaga sprawdzenia. Model nie wie, że Twoja aplikacja obsłuży tysiąc osób naraz, dopóki mu tego nie powiesz, a i wtedy nie zweryfikuje tego założenia.

Wyjście do własnego kodu

To najważniejsza właściwość przy ocenie ryzyka i warto o niej wiedzieć przed rozpoczęciem projektu.

Kod da się wyeksportować do własnego repozytorium i pracować nad nim normalnie. Nie jest to zamknięty format, tylko projekt w Reakcie, który uruchomisz lokalnie i wdrożysz gdziekolwiek.

To zmienia charakter decyzji o użyciu narzędzia. Ryzyko nie polega na tym, że utkniesz, tylko na tym, ile pracy będzie kosztowało przejęcie kodu, którego nikt z zespołu nie pisał.

Praktyczna rada: wyeksportuj kod i przejrzyj go, zanim projekt urośnie. Struktura, nazewnictwo i sposób obsługi stanu to rzeczy, które łatwiej poprawić przy dziesięciu ekranach niż przy czterdziestu.

Pierwszy przegląd zajmuje kilka minut i sprowadza się do trzech pytań: czy to się w ogóle buduje poza narzędziem, ile jest zależności i czy coś wrażliwego nie siedzi w kodzie.

git clone git@github.com:firma/projekt.git && cd projekt
npm ci && npm run build
npx depcheck
grep -rInE "(sk|pk)_(live|test)_[A-Za-z0-9]{10,}" src/

Ostatnie polecenie warto uruchomić nawet wtedy, gdy jesteś pewien, że kluczy w kodzie nie ma. To sprawdzenie kosztuje sekundę, a jego brak kosztował już wiele osób znacznie więcej.

Warto też od początku pracować z repozytorium podłączonym, a nie eksportować dopiero na końcu. Wtedy każda zmiana ma historię i da się do niej wrócić, a przegląd kodu odbywa się na bieżąco zamiast jednorazowo pod presją.

Jak pisać prośby, żeby działały

Jakość wyniku zależy tu od opisu bardziej niż od czegokolwiek innego, a różnica między dobrym a złym opisem to różnica w zużytych kredytach.

Pierwsza zasada dotyczy odniesienia. Prośba wskazująca istniejący element działa lepiej niż opis abstrakcyjny: „zrób listę zamówień taką jak lista klientów, tylko z kolumnami numer, data i kwota" daje wynik zgodny z resztą aplikacji, a „dodaj listę zamówień" daje coś nowego, co wygląda inaczej.

Druga dotyczy zakresu. Jedna prośba obejmuje jeden ekran albo jedną funkcję. Prośba o cały moduł kończy się wynikiem, w którym połowa wymaga poprawek, a poprawianie jest droższe niż zrobienie tego w trzech krokach.

Trzecia dotyczy stanów brzegowych. Model buduje ścieżkę, w której wszystko działa, więc pusta lista, błąd zapisu i tekst dłuższy niż przewidziany wymagają osobnej prośby. Warto je wymienić od razu, a nie odkrywać przy prezentacji.

Czwarta dotyczy danych. Opis struktury danych na początku, zanim powstanie interfejs, oszczędza przebudowy. Model, który wie, że zamówienie ma pozycje, klienta i status, zbuduje inne ekrany niż model, który dowiaduje się o tym w trzecim kroku.

Piąta dotyczy poprawek. Zamiast prosić o poprawienie czegoś ogólnie, warto wskazać, co dokładnie jest nie tak i czego oczekujesz.

Slabo:  napraw formularz zamowienia

Lepiej: na ekranie zamowienia przycisk zapisu nie blokuje sie po
        klknieciu, wiec szybkie dwuklikniecie tworzy dwa zamowienia.
        Zablokuj przycisk na czas wysylki i pokaz wskaznik ladowania.
        Reszty ekranu nie zmieniaj.

Zdanie o tym, czego nie ruszać, jest tu równie ważne jak opis samej poprawki. Bez niego model często przy okazji przebudowuje układ ekranu, a Ty płacisz kredytami za zmianę, o którą nie prosiłeś.

Bezpieczeństwo wygenerowanego kodu

To obszar, o którym mówi się najmniej, a przy produkcie przyjmującym dane użytkowników jest najważniejszy.

Wygenerowany kod działa, co nie znaczy, że jest bezpieczny. Trzy rzeczy warto sprawdzić przed wypuszczeniem czegokolwiek publicznie, niezależnie od tego, jak dobrze wygląda podgląd.

Pierwsza to reguły dostępu do danych. Baza z uwierzytelnianiem chroni dane tylko wtedy, gdy reguły są ustawione poprawnie. Domyślna konfiguracja bywa otwarta, więc zapytanie z przeglądarki potrafi odczytać wiersze innych użytkowników.

Przy zapleczu opartym o Supabase, które te narzędzia wybierają najczęściej, sprawdzenie sprowadza się do dwóch zapytań.

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

select tablename, policyname, cmd
from pg_policies
where schemaname = 'public';

Tabela z wyłączonym zabezpieczeniem na poziomie wiersza albo tabela włączona, lecz bez ani jednej reguły, to dwa różne problemy o tym samym skutku. W pierwszym przypadku widać wszystko, w drugim nie widać nic, a aplikacja przestaje działać w sposób, którego nikt nie umie wytłumaczyć.

Druga to sprawdzanie uprawnień po stronie serwera. Ukrycie przycisku w interfejsie nie jest zabezpieczeniem, a wygenerowany kod czasem poprzestaje na tym pierwszym.

Trzecia to klucze. Klucz do usługi zewnętrznej wstawiony w kod działający w przeglądarce jest widoczny dla każdego, kto otworzy narzędzia deweloperskie.

Sprawdzenie zajmuje chwilę i nie wymaga czytania kodu: wystarczy przejrzeć gotową paczkę wynikową, bo to dokładnie ona trafia do przeglądarki.

npm run build
grep -rInoE "(sk|rk)_(live|test)_[A-Za-z0-9]+" dist/ | head

Jeśli cokolwiek się znajdzie, sam klucz trzeba zrotować, a nie tylko usunąć z kodu. Paczka mogła już trafić do przeglądarek, a wartość raz wysłana na zewnątrz przestaje być tajna niezależnie od tego, co zrobisz później w repozytorium.

Praktyczna rada: przed wypuszczeniem produktu przyjmującego płatności albo dane osobowe poproś kogoś, kto umie programować, o przejrzenie tych trzech rzeczy. To godzina pracy, która chroni przed problemem, którego naprawianie trwa tygodniami.

Lovable kontra alternatywy

Warto zauważyć, że pierwsze trzy wiersze i czwarty odpowiadają na różne pytania. Narzędzia generujące odpowiadają na pytanie, jak szybko sprawdzić pomysł. Praca w edytorze z asystentem odpowiada na pytanie, jak rozwijać projekt, który ma żyć.

Częsty i sensowny układ polega na połączeniu obu. Pierwsza wersja powstaje w narzędziu generującym, a gdy pomysł się potwierdzi, kod trafia do repozytorium i dalszy rozwój odbywa się w edytorze. Ta ścieżka wykorzystuje przewagę obu podejść zamiast wybierać jedno na zawsze.

Moment przejścia warto rozpoznać wcześnie. Sygnałów jest kilka: kolejne prośby psują rzeczy, które wcześniej działały, poprawki zajmują więcej kredytów niż nowe funkcje, a Ty częściej opisujesz, czego nie chcesz, niż czego chcesz. Każdy z nich osobno bywa przypadkiem, wszystkie naraz oznaczają, że projekt przerósł narzędzie.

Przejście nie musi być zerojedynkowe. Część zespołów zostawia narzędzie do prototypowania nowych ekranów i przenosi je do repozytorium po zatwierdzeniu kształtu, traktując je jak szkicownik, a nie jak środowisko produkcyjne.

Typowe błędy

Pierwszy to prośby ogólne. Opis w rodzaju „zrób to ładniej" daje losową zmianę i zużywa kredyty na wynik, którego nie chciałeś.

Drugi to kilka zmian w jednej wiadomości. Wynik obejmuje wtedy rzeczy dobre i złe naraz, a cofnięcie części wymaga kolejnych prób.

Trzeci to brak podglądu po każdej zmianie. Błąd zauważony pięć kroków później kosztuje więcej niż zauważony od razu, bo trzeba ustalić, który krok go wprowadził.

Czwarty to budowanie na tym narzędziu produktu, który ma obsługiwać płatności i dane osobowe, bez przeglądu kodu przez kogoś, kto umie programować. Wygenerowany kod działa, a to nie znaczy, że jest bezpieczny.

Piąty to odkładanie eksportu do repozytorium. Kod bez historii zmian i bez przeglądu rośnie, a przejęcie go po trzech miesiącach jest trudniejsze niż po trzech tygodniach.

Szósty to zakładanie, że narzędzie zastąpi znajomość podstaw. Bez zrozumienia, czym jest baza danych, uwierzytelnianie i skąd biorą się błędy, praca zatrzymuje się przy pierwszym problemie, którego nie da się opisać zdaniem.

FAQ

Ile kosztuje Lovable?

Plan darmowy daje kilka kredytów dziennie do sprawdzenia narzędzia, a plany płatne zaczynają się rzędu dwudziestu dolarów miesięcznie i rosną wraz z pulą kredytów. Progi bywają zmieniane, więc przed decyzją warto sprawdzić aktualny cennik u źródła.

Czym są kredyty?

To jednostka rozliczeniowa zużywana przy każdej wiadomości, w liczbie zależnej od złożoności zadania. Prosta zmiana wyglądu kosztuje ułamek kredyta, dodanie logowania nieco ponad jeden, a wygenerowanie całej strony docelowej niecałe dwa. Koszt każdej wiadomości widać w interfejsie.

Czy da się wyeksportować kod?

Tak, projekt to zwykła aplikacja w Reakcie, którą uruchomisz lokalnie i wdrożysz gdziekolwiek. Warto podłączyć repozytorium od początku, żeby zmiany miały historię i żeby przegląd kodu odbywał się na bieżąco.

Kiedy narzędzie przestaje wystarczać?

Przy złożonej logice biznesowej, przy aplikacji z kilkudziesięcioma ekranami i przy wymaganiach dotyczących wydajności albo dostępności. Wtedy sensowną drogą jest przeniesienie kodu do repozytorium i dalsza praca w edytorze z asystentem.

Czy to zastępuje naukę programowania?

Nie. Narzędzie przyspiesza drogę od pomysłu do działającej wersji, a rozumienie tego, co powstało, nadal jest potrzebne, zwłaszcza przy błędach i przy pytaniach o bezpieczeństwo. Bez tej wiedzy praca zatrzymuje się przy pierwszym problemie wymagającym diagnozy.

Dokumentacja stoi na stronie projektu, a porównanie planów znajdziesz w zestawieniu cen.