Bolt.new, budowanie aplikacji z promptu

Bolt.new, budowanie działającej aplikacji z jednego opisu

Bolt.new zamienia opis w kompletną aplikację i od razu ją uruchamia, bez instalowania czegokolwiek lokalnie. Kod wykonuje się w przeglądarce dzięki WebContainers, technologii StackBlitz, która uruchamia środowisko Node w karcie przeglądarki. Za generowanie kodu odpowiada model Claude, a rozliczenie opiera się na tokenach, nie na liczbie projektów.

Co odróżnia Bolt od pozostałych generatorów

Większość narzędzi tego typu generuje interfejs i zostawia Cię z kodem do uruchomienia gdzie indziej. Bolt uruchamia całość na miejscu: instaluje zależności, startuje serwer deweloperski, pokazuje podgląd i konsolę. Gdy coś się wysypie, model widzi komunikat błędu i poprawia kod bez kopiowania logu.

Druga różnica dotyczy zakresu. Generator komponentów odda Ci przycisk albo formularz. Bolt buduje strukturę projektu, trasy, wywołania API i warstwę danych, więc zaczynasz od czegoś, co działa, a nie od fragmentu do złożenia.

Za tą wygodą stoi konkretne ograniczenie, o którym warto wiedzieć zawczasu. WebContainers uruchamiają środowisko Node w przeglądarce, więc wszystko, co wymaga prawdziwego systemu operacyjnego, odpada. Biblioteki z komponentami natywnymi, bazy działające jako osobny proces czy narzędzia wywołujące polecenia systemowe nie zadziałają. Dla typowej aplikacji webowej opartej o React i wywołania HTTP nie ma to znaczenia, natomiast projekt z przetwarzaniem obrazów po stronie serwera albo z lokalną bazą trzeba prowadzić inaczej.

Trzecia to pełen dostęp do plików. Widzisz drzewo projektu, edytujesz dowolny plik ręcznie, a zmiany łapie ten sam podgląd. To odróżnia Bolta od narzędzi, w których jedynym wejściem jest okno czatu.

Warto od razu ustawić oczekiwania. Bolt jest dobry w postawieniu działającego szkieletu w kwadrans. Nie jest dobry w prowadzeniu dojrzałej aplikacji przez kolejne miesiące, bo im więcej kodu, tym więcej tokenów zużywa każda poprawka i tym częściej model gubi kontekst całości.

Tokeny, czyli na czym polega rozliczenie

Nie płacisz za projekty ani za czas, tylko za tokeny zużywane przez model przy każdej zmianie. To rozliczenie jest sprawiedliwe, ale mało intuicyjne, bo koszt rośnie z wielkością projektu, a nie z trudnością zadania.

Rozliczenie roczne obniża wszystkie stawki płatne, u dostawcy podawane jako oszczędność do dwudziestu ośmiu procent, więc przy narzędziu używanym na stałe warto je policzyć od razu.

Mechanizm, który zaskakuje najczęściej: przy każdej poprawce model dostaje kontekst projektu. Zmiana koloru przycisku w aplikacji z pięcioma plikami kosztuje ułamek tego, co ta sama zmiana w aplikacji z pięćdziesięcioma. Dlatego pierwsza godzina pracy idzie szybko, a po tygodniu ten sam limit starcza na wyraźnie mniej.

Trzy nawyki realnie zmniejszają zużycie. Formułuj polecenia konkretnie, wskazując plik i oczekiwany efekt. Drobne poprawki, na przykład zmianę tekstu albo odstępu, rób ręcznie w edytorze zamiast przez czat. Zaczynaj nowy projekt, gdy zmieniasz kierunek, zamiast przebudowywać stary kolejnymi poleceniami.

Jak wygląda praca krok po kroku

Zaczynasz od opisu. Im więcej konkretów, tym mniej rund poprawek.

Zbuduj aplikacje do zapisow na warsztaty.
Stack: React, TypeScript, Tailwind, dane w localStorage.
Ekrany: lista warsztatow z filtrem po dacie, formularz zapisu z walidacja
adresu e-mail, panel z lista zapisanych osob i eksportem do CSV.
Interfejs po polsku, jasny motyw, zaokraglone karty.

Bolt tworzy strukturę, instaluje zależności i pokazuje podgląd. Dalej pracujesz iteracyjnie, ale kolejność ma znaczenie: najpierw domknij strukturę danych i przepływ ekranów, dopiero potem zajmij się wyglądem. Odwrotna kolejność kończy się dopracowanym interfejsem, który trzeba przebudować po zmianie modelu danych.

Gdy aplikacja ma sens, wyeksportuj ją do repozytorium i przenieś dalszą pracę do własnego edytora. Bolt integruje się z GitHubem i wdraża na Netlify albo Vercela jednym kliknięciem.

Bolt Cloud i warstwa danych

Druga wersja produktu dołożyła Bolt Cloud, czyli wbudowaną bazę danych, logowanie, przechowywanie plików, funkcje brzegowe, analitykę i hosting. Dzięki temu aplikacja z kontami użytkowników nie wymaga podpinania osobnych usług.

To wygodne na etapie prototypu i warte przemyślenia przy produkcji. Wbudowana warstwa wiąże projekt z jednym dostawcą, a przeniesienie danych później bywa kosztowniejsze niż początkowa oszczędność czasu. Jeśli już wiesz, że produkt pójdzie dalej, rozważ podpięcie Supabase od początku, bo zostaje z Tobą po wyjściu z Bolta.

Praktyczny sprawdzian przed decyzją jest prosty: wypisz dane, które aplikacja będzie trzymać za rok, i zastanów się, czy dałoby się je wyeksportować w rozsądnym czasie. Jeśli odpowiedź brzmi tak, wbudowana warstwa jest bezpiecznym wyborem na start. Jeśli nie, lepiej ponieść koszt konfiguracji od razu, zanim w bazie znajdą się dane klientów.

Niezależnie od wyboru zadbaj o klucze. Sekrety wpisane w kod frontendu trafiają do przeglądarki, a wygenerowany projekt nie ma z natury poprawnej separacji warstw. To jeden z najczęstszych problemów w aplikacjach powstałych tą drogą.

Bolt kontra Lovable, v0 i Replit

Różnice widać najlepiej na tym samym zadaniu. Prosty panel z listą i formularzem powstanie w każdym z tych narzędzi w podobnym czasie, natomiast aplikacja z logowaniem i kilkoma powiązanymi ekranami rozjeżdża je wyraźnie: Bolt zbuduje strukturę i zostawi Cię z kodem, Lovable dowiezie ładniejszy efekt przy mniejszej kontroli, a v0 poprosi o złożenie całości samodzielnie.

Ceny planów podstawowych są zbliżone, więc wybór rzadko sprowadza się do rachunku. Rozstrzyga to, czy chcesz dostać kod do dalszej pracy, czy gotowy produkt do klikania.

Warto też wiedzieć, że wszystkie te narzędzia generują kod tego samego rodzaju: poprawny, konwencjonalny, bez optymalizacji. Świetnie nadaje się na start i wymaga przeglądu przed wdrożeniem czegoś, co dotyka pieniędzy albo danych osobowych.

Jak pisać polecenia, żeby nie palić tokenów

Skuteczne polecenie w Bolcie wygląda inaczej niż rozmowa z asystentem w edytorze. Model nie zna Twoich intencji ani historii projektu poza tym, co widzi w plikach, więc opis musi być samowystarczalny.

Trzy elementy podnoszą trafność wyraźnie. Wskaż plik albo ekran, którego dotyczy zmiana, zamiast opisywać ją ogólnie. Podaj oczekiwany efekt w kategoriach zachowania, nie wyglądu kodu. Wymień to, czego zmieniać nie wolno, bo model chętnie przebudowuje sąsiednie fragmenty przy okazji.

W pliku src/components/FormularzZapisu.tsx dodaj walidacje numeru telefonu:
dziewiec cyfr, dozwolone spacje, komunikat pod polem.
Nie zmieniaj ukladu formularza ani logiki wysylki.

Polecenie w tej postaci kosztuje kilka razy mniej niż prośba w stylu „popraw walidację w formularzu", bo model nie musi przeszukiwać projektu ani zgadywać zakresu.

Osobna sprawa to poprawianie błędów. Gdy podgląd pokazuje wyjątek, wklejenie komunikatu bywa skuteczniejsze niż opisanie objawu własnymi słowami. Model dostaje wtedy dokładne miejsce w kodzie zamiast rekonstruować je z opisu.

Gdy dwie kolejne próby nie naprawiają tego samego błędu, przerwij pętlę. Trzecia próba zwykle też się nie uda, a każda kosztuje tyle co poprzednia. Szybciej otworzyć plik, przeczytać kod i poprawić go samodzielnie albo cofnąć się do wcześniejszej wersji projektu i podejść inaczej.

Do czego Bolt nadaje się naprawdę

Sprawdza się w czterech sytuacjach. Prototyp na spotkanie, gdy makieta nie wystarcza, a aplikacja do klikania robi robotę. Wewnętrzne narzędzie dla kilku osób, którego nikt nie chciał budować ręcznie. Punkt wyjścia dla projektu, w którym szkielet powstaje w kwadrans zamiast w dwa dni. Nauka, ponieważ czytanie działającego kodu z komentarzem modelu bywa skuteczniejsze niż tutorial.

Nie sprawdza się przy pracy na istniejącym dużym repozytorium, przy wymaganiach dotyczących wydajności i przy funkcjach, których poprawność trzeba udowodnić testami. Tam sensowniej sięgnąć po asystenta wpiętego w edytor, na przykład Cursora, bo pracuje na Twoim kodzie zamiast generować nowy.

Wyjście z Bolta do własnego projektu

Moment przeniesienia pracy do lokalnego środowiska wypada zwykle wcześniej, niż się wydaje. Sygnały są trzy: projekt przekracza kilkadziesiąt plików, poprawki zaczynają psuć rzeczy, które wcześniej działały, albo pojawia się potrzeba testów.

Sam eksport jest prosty, bo powstaje zwykły projekt Node z plikiem package.json. Po sklonowaniu repozytorium instalujesz zależności i uruchamiasz serwer deweloperski.

git clone git@github.com:uzytkownik/moj-projekt.git
cd moj-projekt
npm install
npm run dev

Pierwsze kroki po przeniesieniu warto wykonać w ustalonej kolejności. Dodaj konfigurację lintera i formatowania, bo wygenerowany kod bywa niespójny stylistycznie między plikami. Przejrzyj zależności, ponieważ model potrafi dołożyć bibliotekę do jednej funkcji, którą napisałbyś w dziesięciu linijkach. Sprawdź, gdzie trafiają klucze i czy wywołania do zewnętrznych API idą z serwera.

Ostatni punkt sprawdzisz jednym poleceniem, zanim cokolwiek wdrożysz.

grep -rn "API_KEY\|SECRET\|sk-" src/ --include="*.ts*" --include="*.js*"

Jeśli cokolwiek wyjdzie poza plikami po stronie serwera, klucz trafia do przeglądarki i jest publiczny niezależnie od tego, jak nazwana jest zmienna. Generatory chętnie umieszczają wywołania zewnętrznych usług tam, gdzie widać efekt najszybciej, czyli w komponencie, a to jest dokładnie to miejsce, w którym nie powinny stać.

Dopiero potem dopisz testy, i to nie wszędzie, tylko wokół logiki, która liczy pieniądze, terminy albo uprawnienia. Reszta wygenerowanego kodu to zwykle warstwa prezentacji, której testowanie na tym etapie niewiele daje.

Od tej chwili sensowniej pracować asystentem wpiętym w edytor. Bolt zrobił swoje, czyli skrócił drogę od pomysłu do działającego szkieletu, a dalsza praca na rosnącym repozytorium to inne zadanie i inne narzędzie.

Typowe błędy

Pierwszy to jeden długi prompt opisujący całą aplikację ze wszystkimi szczegółami. Model gubi część wymagań, a poprawianie tego kosztuje więcej tokenów niż zbudowanie aplikacji etapami.

Drugi to poprawianie przez czat rzeczy, które szybciej zmienić ręcznie. Zmiana napisu przez polecenie to pełny obieg kontekstu, a w edytorze zajmuje sekundę.

Trzeci to pozostanie w Bolcie zbyt długo. Gdy projekt przekracza kilkadziesiąt plików, praca zwalnia i drożeje. Eksport do repozytorium jest wtedy naturalnym krokiem, a nie porażką narzędzia.

Czwarty to wdrażanie bez przeglądu kodu. Wygenerowana aplikacja zwykle nie ma walidacji po stronie serwera, ograniczeń liczby zapytań ani kontroli uprawnień, bo nikt o nie nie poprosił.

Piąty to mylenie prototypu z produktem przy rozmowie z klientem. Aplikacja z Bolta wygląda jak gotowa, więc łatwo obiecać termin wdrożenia oparty na tym, co widać na ekranie. Praca, która zostaje, czyli uprawnienia, obsługa błędów, testy i wydajność, bywa dłuższa niż całe generowanie.

Szósty to brak kopii. Projekt żyje w przeglądarce, więc podepnij repozytorium od razu, zanim stracisz kilka godzin pracy przez zamkniętą kartę.

FAQ

Czy Bolt.new jest darmowy?

Plan darmowy daje milion tokenów miesięcznie z limitem trzystu tysięcy dziennie i nie wymaga karty. Wystarcza na kilka prototypów w miesiącu. Plan Pro kosztuje 25 USD i zaczyna się od dziesięciu milionów tokenów, przy czym niewykorzystane tokeny przechodzą na kolejny miesiąc.

Przeniesienie niewykorzystanych tokenów ma przy tym granicę, o której łatwo zapomnieć przy planowaniu większego zrywu. Pula przechodzi na jeden kolejny miesiąc, czyli zachowuje ważność najwyżej przez dwa miesiące łącznie. Odkładanie tokenów na projekt za kwartał nie zadziała, bo najstarsza część puli po prostu przepadnie.

Czy kod z Bolta nadaje się na produkcję?

Jako punkt wyjścia tak, jako gotowy produkt rzadko. Struktura i konwencje są poprawne, natomiast brakuje zwykle walidacji po stronie serwera, obsługi błędów i kontroli uprawnień. Przed wdrożeniem czegoś, co przyjmuje dane użytkowników, potrzebny jest przegląd.

Czym Bolt różni się od Lovable?

Bolt daje więcej kontroli nad kodem i pełne środowisko w przeglądarce, Lovable stawia na dopracowany interfejs i prostotę dla osób nietechnicznych. Plany podstawowe kosztują podobnie, różnicę widać dopiero w cenniku zespołowym i w tym, ile pracy zostaje po Twojej stronie.

Czy mogę wyeksportować projekt?

Tak, projekt eksportuje się do repozytorium na GitHubie albo pobiera jako pliki. To normalny projekt z package.json, więc uruchomisz go lokalnie każdym menedżerem pakietów i rozwijasz dalej bez Bolta.

Dlaczego tokeny kończą się szybciej niż na początku?

Bo przy każdej poprawce model dostaje kontekst rosnącego projektu. Ta sama zmiana kosztuje więcej w aplikacji z pięćdziesięcioma plikami niż z pięcioma. Stąd zalecenie, żeby drobiazgi poprawiać ręcznie, a nowy kierunek zaczynać od nowego projektu.

Aktualne plany opisuje bolt.new, a technologię uruchamiającą kod w przeglądarce dokumentacja WebContainers.