Replit, agent budujący aplikacje

Replit, czyli aplikacja z opisu, razem z hostingiem

Replit zaczynał jako środowisko programistyczne działające w przeglądarce, a stał się przede wszystkim narzędziem, w którym opisujesz aplikację słowami, a agent ją buduje, uruchamia i wdraża.

Różnica wobec asystentów działających w edytorze polega na tym, że tutaj dostajesz cały łańcuch. Nie ma osobnego kroku konfigurowania środowiska, wybierania hostingu ani podłączania bazy danych. Piszesz, co ma powstać, i po kilkunastu minutach masz działający adres.

Najnowsza wersja agenta idzie dalej: sama sprawdza zbudowaną aplikację w przeglądarce, klika w elementy interfejsu, wykrywa błędy i poprawia je bez pytania. To zmienia charakter pracy i, jak zobaczysz niżej, zmienia też rachunek.

Rozliczenie za wysiłek

Model rozliczeń jest tu najważniejszą rzeczą do zrozumienia przed rozpoczęciem, bo różni się od wszystkiego, do czego przyzwyczaiły inne narzędzia.

Jednostką rozliczeniową jest punkt kontrolny, czyli zapis stanu projektu tworzony przez agenta po wykonaniu fragmentu pracy. Punkty kontrolne pełnią podwójną rolę: pozwalają cofnąć się do wcześniejszej wersji aplikacji i pokazują, za co zapłaciłeś.

Warto od razu wyprostować częste nieporozumienie, bo prowadzi do złych wniosków o rachunku. Opłata nie jest przywiązana wyłącznie do punktów kontrolnych: rozliczane jest każde wywołanie agenta, w tym rozmowa w trybie planowania, po której nie powstaje żadna zmiana w kodzie i żaden punkt kontrolny. Punkty widać wtedy, gdy agent faktycznie zmienił kod, a nie wtedy, gdy naliczono opłatę.

Wcześniej każdy punkt kontrolny kosztował tyle samo, niezależnie od tego, czy dotyczył poprawki jednej linii czy przebudowy modułu. Obecnie cena zależy od rzeczywistego nakładu: czasu i mocy obliczeniowej zużytej na dane zadanie. Drobna zmiana kosztuje mniej niż dawna stawka stała, duże zadanie mieści się w jednym punkcie kontrolnym i kosztuje odpowiednio więcej.

Zmiana jest sensowna i ma skutek uboczny wart nazwania wprost. Nie wiesz z góry, ile zapłacisz za dane polecenie, bo zależy to od tego, ile pracy agent uzna za potrzebną. Polecenie brzmiące niewinnie potrafi uruchomić długi ciąg zmian z odpowiednim rachunkiem.

Do tego dochodzi charakter nowej wersji agenta. Skoro sam testuje aplikację, klika przez interfejs i poprawia znalezione błędy, wykonuje wielokrotnie więcej pracy na jedno polecenie niż wersje wcześniejsze. Użytkownicy opisują z tego powodu wyraźne wzrosty rachunków po przejściu na nią, i to nie jest wada narzędzia, tylko konsekwencja tego, że robi więcej.

Sam agent jest przy tym tylko częścią rachunku, bo najpierw wybierasz plan, a plan daje pulę kredytów, z której opłaty schodzą. Stawki są dwie, bo rozliczenie roczne jest tańsze od miesięcznego.

Dwie rzeczy z tej tabeli zwykle umykają. Kredyty na planie Core zerują się z początkiem każdego okresu rozliczeniowego i nie przechodzą dalej, a na planie Pro niewykorzystana pula przechodzi na kolejne dwa miesiące, zanim wygaśnie. Doładowania kupowane osobno wygasają po sześciu miesiącach od zakupu i również nie przechodzą dalej.

Warto też wiedzieć, co dzieje się po wyczerpaniu puli i po dojściu do limitu, bo to nie jest samo powiadomienie. Limit wydatków wstrzymuje usługi rozliczane zużyciem aż do początku kolejnego okresu albo do podniesienia progu, a osobny limit wyłączający zawiesza działające usługi w tym samym trybie.

Jak nad tym zapanować

Skoro koszt jest zmienny, warto od początku pracować w sposób, który go ogranicza.

Pierwsza zasada dotyczy wielkości poleceń. Jedno duże polecenie obejmujące cztery funkcje naraz daje agentowi swobodę, której koszt jest trudny do przewidzenia. Cztery mniejsze polecenia, każde sprawdzone przed kolejnym, kosztują zwykle mniej i dają lepszy wynik, bo błąd wychodzi wcześnie.

Druga dotyczy limitu wydatków. Ustaw go przed rozpoczęciem pracy, na wartość, którą jesteś gotów zapłacić. To jedyny mechanizm działający bez Twojej uwagi, a przy narzędziu, które pracuje samodzielnie przez kilkanaście minut, uwaga bywa zawodna.

Trzecia dotyczy tego, kiedy przestać. Narzędzie doskonale sprawdza się przy budowie od zera i przy pierwszych kilkudziesięciu zmianach. Przy aplikacji, która już działa i wymaga precyzyjnej poprawki w jednym miejscu, opisanie tej poprawki słowami bywa droższe i wolniejsze niż otwarcie kodu i zmiana dwóch linii.

Czwarta dotyczy przeglądania wyniku. Agent testujący sam siebie wykrywa błędy techniczne, a nie rozbieżność między tym, co zbudował, a tym, czego chciałeś. Sprawdzenie po każdym większym kroku kosztuje minutę i zapobiega sytuacji, w której trzy kolejne polecenia rozbudowują rozwiązanie idące w złą stronę.

Piąta dotyczy trybu pracy agenta, bo to jest dźwignia pomijana najczęściej. Do drobnych, zawężonych zmian służy tryb najlżejszy, do codziennej pracy tryb oszczędny, a najmocniejsze modele warto zostawić na zadania, które faktycznie tego wymagają. Sam wybór trybu potrafi zmienić rachunek bardziej niż skracanie poleceń.

Co dostajesz poza agentem

Warto wymienić resztę, bo to ona odróżnia to narzędzie od asystentów pracujących wyłącznie z kodem.

Środowisko działa w przeglądarce, więc nie ma instalacji ani konfiguracji lokalnej. To ma znaczenie przy pracy z niedużego komputera, przy szkoleniach i przy dołączaniu nowej osoby do projektu, bo start zajmuje minutę zamiast popołudnia.

Wdrożenie jest częścią narzędzia. Aplikacja dostaje adres, obsługę certyfikatu i możliwość podpięcia własnej domeny, bez wybierania dostawcy hostingu i konfigurowania czegokolwiek.

Baza danych i przechowywanie kluczy są wbudowane, więc typowy projekt nie wymaga zewnętrznych usług na starcie.

Praca zespołowa działa w jednym pliku jednocześnie, jak w edytorze dokumentów. To przydaje się przy nauce i przy szybkim pokazaniu czegoś drugiej osobie, a rzadziej przy codziennej pracy zespołu programistów.

Zastrzeżenie: kod, który powstaje, jest zwykłym kodem i da się go pobrać. To ważne, bo oznacza, że projekt zbudowany tutaj można przenieść gdzie indziej, na przykład na Railway albo Vercel, gdy przestanie mieścić się w tym modelu pracy.

Jak pisać polecenia dla agenta

Skoro to główny sposób pracy, warto poświęcić chwilę na to, co odróżnia polecenie działające od polecenia, po którym trzeba wszystko cofać.

Zacznij od opisu tego, co aplikacja ma robić z punktu widzenia użytkownika, a nie od tego, jak ma być zbudowana. Wyliczenie tabel i pól niesie mniej użytecznej informacji niż opis zachowania, bo odbiera agentowi możliwość dobrania rozwiązania.

Aplikacja do zadan zespolowych.

Uzytkownik loguje sie adresem e-mail, tworzy liste, dodaje do niej zadania,
przypisuje je do osoby z zespolu i oznacza jako zrobione. Kazdy widzi tylko
listy zespolu, do ktorego nalezy.

Ograniczenia, na ktorych mi zalezy:
- dane w bazie relacyjnej
- logowanie bez hasla, przez link wyslany na adres

Blok ograniczeń trzymaj krótki i wpisuj do niego wyłącznie to, co naprawdę ma znaczenie. Dziesięć preferencji przy pierwszym poleceniu sprawia, że agent poświęca połowę pracy na ich spełnienie zamiast na działającą aplikację.

Podaj ograniczenia, na których Ci zależy, i tylko te. Wskazanie technologii, formatu danych albo sposobu logowania ma sens wtedy, gdy faktycznie ma znaczenie. Wyliczenie dziesięciu preferencji przy pierwszym poleceniu sprawia, że agent poświęca połowę pracy na ich spełnienie zamiast na działającą aplikację.

Opisuj kolejne kroki w kolejności, w jakiej sam byś je wykonał. Najpierw model danych i podstawowe operacje, potem interfejs, na końcu wygląd i szczegóły. Odwrotna kolejność prowadzi do sytuacji, w której dopracowany wizualnie ekran trzeba przebudować, bo zmienił się sposób przechowywania danych.

Przy poprawkach wskazuj miejsce, a nie objaw. Różnica w koszcie między dwoma zapisami tego samego zgłoszenia bywa kilkukrotna.

Drogo:  przycisk zapisu nie dziala

Taniej: na ekranie edycji zadania przycisk zapisu nie wysyla formularza,
        dane sa poprawne, w konsoli nie ma bledu, po kliknieciu nic sie
        nie dzieje i adres sie nie zmienia

Drugi zapis nie jest dłuższy dla ozdoby. Zdejmuje z agenta etap odtwarzania błędu i zawęża obszar poszukiwań do jednego ekranu, a to jest ta część pracy, która przy większej aplikacji kosztuje najwięcej.

Ostatnia rzecz: zapisuj, co już działa. Punkt kontrolny po każdej działającej funkcji daje punkt, do którego można wrócić, i to jest jedyne zabezpieczenie przed poleceniem, które psuje coś, co wcześniej działało bez zarzutu.

Skoro powstający kod jest zwykłym kodem, warto od pierwszego dnia trzymać go też we własnym repozytorium, niezależnie od punktów kontrolnych narzędzia.

git init
git add -A
git commit -m "Dziala logowanie i lista zadan"
git remote add origin git@github.com:firma/zadania.git
git push -u origin main

Ten nawyk kosztuje minutę i rozwiązuje dwie sprawy naraz: masz historię czytelną poza narzędziem oraz gotową drogę wyjścia, gdy projekt przestanie mieścić się w tym modelu pracy.

Replit kontra alternatywy

Podział przebiega wzdłuż jednego pytania: czy chcesz mieć kod pod kontrolą, czy chcesz mieć wynik. Przy prototypie, aplikacji wewnętrznej i nauce liczy się wynik, więc pierwszy wiersz wygrywa. Przy systemie utrzymywanym latami przez zespół liczy się kod, a wtedy narzędzie pracujące w Twoim edytorze i repozytorium pasuje lepiej.

Warto też zauważyć, że to nie jest wybór na zawsze. Zaczęcie tutaj i przeniesienie projektu po wyjściu z fazy prototypu jest normalną drogą, a nie porażką.

Granice tego podejścia

Trzeba je nazwać wprost, bo obietnica narzędzia jest szeroka, a ograniczenia realne.

Pierwsze dotyczy złożoności. Aplikacja z kilkoma tabelami, logowaniem i panelem powstaje tu sprawnie. System z dwudziestoma modułami, zależnościami między nimi i regułami biznesowymi wymagającymi precyzji przekracza to, co da się sensownie opisać słowami.

Drugie dotyczy utrzymania. Kod wygenerowany przez agenta bywa poprawny i zarazem niespójny w stylu, bo powstawał w kilkudziesięciu krokach bez całościowego planu. Przy projekcie, który ktoś ma rozwijać przez dwa lata, to jest realny koszt.

Trzecie dotyczy przewidywalności kosztu. Przy projekcie z ustalonym budżetem rozliczenie zależne od nakładu pracy agenta jest ryzykiem, które trzeba świadomie przyjąć albo ograniczyć limitem.

Czwarte dotyczy zależności od jednej platformy. Kod da się pobrać, natomiast wbudowana baza, przechowywanie kluczy i wdrożenie są częścią tego środowiska, więc przeniesienie projektu oznacza odtworzenie tych elementów gdzie indziej.

Bezpieczeństwo aplikacji zbudowanej z opisu

Ta część zasługuje na osobne omówienie, bo aplikacja może działać bez zarzutu i mieć poważny problem, którego nic nie sygnalizuje.

Najczęstszy dotyczy dostępu do danych. Agent buduje warstwę zapisu i odczytu tak, żeby działała, a reguła „użytkownik widzi wyłącznie swoje wpisy" pojawia się wtedy, gdy ją wskażesz. Bez tego aplikacja działa poprawnie dla jednego użytkownika i wystawia cudze dane, gdy pojawi się drugi.

Drugi dotyczy kluczy i haseł. Środowisko ma wbudowany magazyn sekretów i warto go używać od początku, bo klucz wpisany w kod trafia do historii projektu, a przy udostępnieniu go publicznie zostaje tam na stałe.

Trzeci dotyczy walidacji po stronie serwera. Sprawdzenie danych wyłącznie w przeglądarce wygląda na kompletne i nie jest, bo żądanie da się wysłać z pominięciem interfejsu. To pomyłka spotykana również w kodzie pisanym ręcznie, natomiast tutaj trudniej ją zauważyć, bo nie przeglądasz każdej linii.

Czwarty dotyczy tego, co aplikacja wystawia publicznie. Adres wdrożenia jest dostępny dla każdego, kto go zna, więc panel administracyjny bez logowania jest otwarty dla świata, mimo że nikt do niego nie linkuje.

Sprawdzenie pierwszej z tych rzeczy sprowadza się do dwóch żądań: jednego z tokenem jednego użytkownika, drugiego z tokenem drugiego, po ten sam zasób.

curl -s -H "Authorization: Bearer $TOKEN_ANNA" \
  https://moja-apka.replit.app/api/zadania/42

curl -s -H "Authorization: Bearer $TOKEN_MAREK" \
  https://moja-apka.replit.app/api/zadania/42

Jeśli oba wywołania zwracają to samo zadanie, reguła dostępu nie istnieje, niezależnie od tego, że interfejs pokazuje każdemu tylko jego listę. Drugą rzecz sprawdzisz jednym wywołaniem bez żadnego nagłówka.

curl -s -o /dev/null -w "%{http_code}\n" https://moja-apka.replit.app/admin

Kod inny niż 401 albo 302 oznacza, że panel jest otwarty dla każdego, kto zna adres.

Praktyczna rada: przed udostępnieniem czegokolwiek poza własnym zespołem poproś agenta wprost o przegląd pod kątem dostępu do danych, a potem sprawdź sam te dwie rzeczy. To dziesięć minut, które oszczędza znacznie więcej.

Typowe błędy

Pierwszy to brak limitu wydatków. Rozliczenie zależy od nakładu pracy agenta, więc bez górnego progu rachunek potrafi zaskoczyć po jednym wieczorze.

Drugi to polecenia obejmujące zbyt wiele naraz. Cztery mniejsze kroki, każdy sprawdzony, kosztują mniej i dają lepszy wynik niż jedno duże.

Trzeci to używanie agenta do drobnych poprawek w działającej aplikacji. Otwarcie kodu i zmiana dwóch linii bywa szybsze i tańsze niż opisanie tej zmiany słowami.

Czwarty to poleganie na samotestowaniu agenta jako na przeglądzie. Wykrywa błędy techniczne, a nie rozbieżność między wynikiem a Twoim zamiarem.

Piąty to budowanie tu systemu przeznaczonego do wieloletniego utrzymania bez żadnego planu przeniesienia. Kod da się pobrać, natomiast im później to zrobisz, tym więcej elementów środowiska trzeba odtworzyć u innego dostawcy.

Szósty to pomijanie przeglądu kodu przy danych wrażliwych. Aplikacja zbudowana z opisu może działać bez zarzutu i mieć otwarty dostęp do cudzych danych, bo nikt tego nie sprawdził.

FAQ

Jak działa rozliczenie?

Cena zależy od rzeczywistego nakładu, więc drobna zmiana kosztuje mniej, a duże zadanie mieści się w jednym punkcie kontrolnym i kosztuje odpowiednio więcej. Opłaty schodzą z miesięcznej puli kredytów przypisanej do planu: 25 USD na planie Core i 100 USD na planie Pro. Rozliczane jest każde wywołanie agenta, także rozmowa w trybie planowania, po której nie powstaje żaden punkt kontrolny.

Dlaczego rachunki wzrosły po nowej wersji agenta?

Bo agent robi więcej na jedno polecenie: sam testuje aplikację w przeglądarce, klika przez interfejs, wykrywa błędy i poprawia je. Więcej wykonanej pracy oznacza wyższy koszt przy rozliczeniu zależnym od nakładu, więc limit wydatków warto ustawić przed rozpoczęciem.

Czy mogę pobrać wygenerowany kod?

Tak, powstaje zwykły kod i da się go przenieść gdzie indziej. Wbudowana baza, przechowywanie kluczy i wdrożenie są natomiast częścią tego środowiska, więc przeniesienie projektu wymaga odtworzenia tych elementów u innego dostawcy.

Czy to nadaje się do projektu produkcyjnego?

Do aplikacji wewnętrznej, narzędzia dla zespołu i prototypu pokazywanego klientowi tak. Do systemu utrzymywanego latami warto rozważyć przeniesienie po wyjściu z fazy prototypu, bo kod powstający w kilkudziesięciu krokach bywa niespójny stylistycznie.

Czym różni się od asystenta w edytorze?

Zakresem. Cursor i podobne narzędzia pracują na Twoim kodzie w Twoim środowisku, a wdrożenie i infrastruktura pozostają po Twojej stronie. Tutaj dostajesz cały łańcuch od opisu do działającego adresu, kosztem mniejszej kontroli nad tym, co powstaje po drodze.

Dokumentacja stoi na stronie projektu, a zmiany w rozliczeniu opisuje wpis producenta.