Poradniki · 6 min czytania

Jak zrobić aplikację z AI: pierwsza działająca wersja

Zbudowałem serwis ogłoszeń o pracę fractio.pl i narzędzie do stron dla firm usługowych adee.pl bez wykształcenia programistycznego, rozmawiając z Claude Code. To, co robiłem, nazywa się potocznie vibe coding: budujesz aplikację przez rozmowę z modelem, zamiast pisać kod samodzielnie. Za każdym razem przebieg był ten sam: piszesz, co chcesz zobaczyć, model generuje kod, ty klikasz i sprawdzasz, czy to działa. Do startu wystarczą trzy rzeczy: jedno zdanie opisujące, co aplikacja ma robić, jedno narzędzie (nie pięć) i gotowość na to, że w połowie drogi coś przestanie działać. Ten tekst prowadzi Cię tą samą drogą: od pustego ekranu do pierwszej wersji, którą otworzysz w przeglądarce i klikniesz.

Zacznij od jednego zdania, nie od wyboru narzędzia

Przy fractio.pl najwięcej czasu zabrało mi nie narzędzie, tylko jedno zdanie: kto wchodzi na tę stronę i po co. Dopóki go nie miałem, każde polecenie do modelu było życzeniem, a nie opisem, i dostawałem coś, czego nie umiałem ocenić. Zacznij od tego zdania w formacie: kto wchodzi na moją aplikację, co tam robi, co dostaje w zamian.

Przykłady, które naprawdę da się dokończyć w jeden wieczór:

Trener personalny wpisuje imię klienta i trzy ćwiczenia, dostaje link do planu, który klient otwiera na telefonie.
Osoba prowadząca warsztaty wkleja listę uczestników, dostaje tabelę z obecnością i przyciskiem do eksportu.
Ktoś wpisuje adres URL, dostaje uporządkowaną listę linków ze strony.

Przykłady, które zablokują Cię na starcie: „platforma jak Airbnb, ale dla garaży”, „aplikacja z logowaniem, płatnościami, powiadomieniami push i panelem administratora”. Nie dlatego, że AI tego nie zrobi. Dlatego, że nie będziesz w stanie stwierdzić, czy to działa, a przy pierwszym błędzie nie odróżnisz problemu z płatnościami od problemu z logowaniem.

Reguła, która oszczędza najwięcej frustracji: pierwsza wersja ma jeden ekran i jedną akcję. Logowanie, baza danych, wysyłka maili, wszystko to dokładasz później, po kolei, sprawdzając po każdym kroku.

Dwie drogi: kreator w przeglądarce albo asystent na Twoim komputerze

Narzędzi do budowania aplikacji z pomocą AI jest dużo, ale dzielą się na dwie kategorie, które dają zupełnie inne doświadczenie.

Kreator w przeglądarce

Wchodzisz na stronę, wpisujesz opis w okienko, po chwili widzisz w podglądzie gotowy interfejs. Nic nie instalujesz. Najniższy próg wejścia, jaki istnieje, i dlatego to najlepszy sposób na sprawdzenie w ciągu godziny, czy takie budowanie w ogóle Cię wciąga. Do tej grupy należy między innymi Lovable.

Asystent, który pracuje na plikach na Twoim dysku

Instalujesz narzędzie, otwierasz je w folderze z projektem i rozmawiasz z nim o kodzie, który leży u Ciebie. Tak działa Claude Code, tak działa Cursor. Wymaga jednego wieczoru więcej na start, ale dostajesz kontrolę: widzisz każdy plik, możesz cofnąć zmianę, nie jesteś zależny od jednego dostawcy. Różnice między tymi dwoma asystentami opisałem osobno w porównaniu Claude Code i Cursora.

Ważne rozróżnienie, o którym w polskich poradnikach rzadko ktoś mówi wprost: stare kreatory typu „przeciągnij i upuść” to nie to samo co narzędzia AI. W pierwszych składasz aplikację z klocków, których ktoś dla Ciebie przygotował skończoną liczbę. W drugich powstaje prawdziwy kod, który możesz dowolnie zmieniać. To druga kategoria daje Ci własną aplikację bez programowania w sensie, o który Ci chodzi: nie jesteś ograniczony do tego, co przewidział twórca kreatora.

Kredyty i tokeny: dlaczego pierwszy wieczór warto zaplanować

Tu jest rzecz, która zmienia sposób pracy bardziej niż wybór narzędzia. Rozliczenie zwykle nie jest ryczałtem za miesiąc, tylko zużyciem, liczonym w kredytach albo tokenach. Kredyt to umowna jednostka, którą narzędzie odejmuje od Twojej puli za kolejne polecenia. Token to jednostka, na jaką model dzieli tekst, który do niego wysyłasz i który od niego dostajesz. Dla Ciebie obie sprowadzają się do tego samego: pula jest skończona i kiedyś się kończy, zwykle w najmniej wygodnym momencie.

Lovable pozwala zacząć bez opłaty, a darmowy plan ma limit kredytów. Jaki dokładnie i jak się odnawia, sprawdź bezpośrednio u producenta: cennik Lovable. Nie przepisuję tych warunków do poradnika, bo w tej kategorii zmieniają się na tyle często, że każda przepisana liczba dezaktualizuje się szybciej, niż zdążysz ją wykorzystać.

Praktyczna konsekwencja jest niezależna od tego, ile dokładnie dostajesz: jeśli pierwsze polecenie brzmi „zrób mi aplikację”, drugie „dodaj kolory”, trzecie „nie, inne kolory”, to skończysz dzień z brzydkim szkieletem i wyczerpanym limitem. Dlatego przed otwarciem narzędzia rozpisz sobie na kartce kolejność ruchów i w każdym opisz dokładnie jedną zmianę, zamiast wrzucać trzy życzenia w jedno zdanie.

Kwot planów płatnych świadomie tu nie podaję. W tej kategorii ceny zmieniały się wielokrotnie, a wszystkie zestawienia krążące po blogach są wtórne. Otwórz cennik producenta w dniu, w którym płacisz: Cursor, Bolt.new (mechanikę tokenów opisuje osobno dokumentacja Bolt), Replit.

Pierwsza godzina krok po kroku

Napisz opis, nie życzenie. Zamiast „zrób aplikację do treningów” napisz: „Aplikacja webowa z jednym ekranem. Formularz: imię klienta, lista trzech ćwiczeń z liczbą serii i powtórzeń. Po kliknięciu Zapisz pokazuje czytelne podsumowanie planu na osobnym ekranie. Bez logowania, bez bazy danych, dane trzymaj w pamięci przeglądarki.” Ten poziom szczegółu to różnica między jednym trafionym poleceniem a czterema poprawkami.
Uruchom i kliknij wszystko. Nie oceniaj po podglądzie. Wpisz w formularz bzdury, zostaw puste pole, wciśnij Zapisz dwa razy. To zajmuje trzy minuty i pokazuje więcej niż czytanie kodu, którego nie rozumiesz.
Dodaj jedną rzecz. „Dodaj przycisk kopiowania planu do schowka.” Sprawdź. Dopiero potem następna.
Rób commity w gicie. Git to system kontroli wersji, a commit to zapisana migawka całego projektu z opisem, do której możesz wrócić jedną komendą, gdy kolejna zmiana coś zepsuje. Jeśli pracujesz z asystentem na dysku, po każdym udanym kroku napisz wprost: „zrób commit z opisem, co się zmieniło”. Jeśli pracujesz z kreatorem w przeglądarce, użyj jego własnej historii wersji.
Zatrzymaj się na jednej funkcji. Wersja, która robi jedną rzecz do końca, uczy Cię więcej niż projekt z kilkoma zaczętymi i żadną skończoną.

Co się zepsuje i co wtedy zrobić

To fragment, którego brakuje w większości poradników, a bez niego pierwsza próba kończy się porzuceniem projektu. Kolejność jest dość powtarzalna.

Zmiana w jednym miejscu psuje inne. Poprosisz o zmianę wyglądu przycisku, a przestanie działać zapisywanie. Nie tłumacz modelowi całego projektu od nowa. Napisz dokładnie: co robiłeś, co się stało, co powinno się stać. Trzy zdania. Jeśli po dwóch próbach naprawy problem rośnie, wróć do ostatniego commita i podejdź inaczej, mniejszym krokiem.

Raport o naprawie to nie dowód naprawy. Przy adee.pl najwięcej czasu straciłem na sytuacjach, w których model pisał, że formularz już działa, a on dalej zapisywał pusty wpis. Dowiadywałem się o tym wyłącznie wtedy, gdy sam otworzyłem stronę i kliknąłem. Dlatego sprawdzasz po każdej zmianie i nie ma tu skrótu.

Logowanie i baza danych to moment, w którym rośnie liczba nieudanych prób. Dopóki aplikacja działa w przeglądarce jednej osoby, jest prosta. Gdy dochodzą konta użytkowników, pojawiają się rzeczy niewidoczne w podglądzie: uprawnienia, kto co może zobaczyć, co się stanie przy dwóch osobach naraz. Rób to jako osobny etap, na spokojnie, nie w ostatniej godzinie wieczoru.

Rozróżnienie, które oszczędzi Ci rozczarowania: obie moje aplikacje, fractio.pl i adee.pl, działają w przeglądarce, także na telefonie, i tego typu rzecz najprawdopodobniej zbudujesz w pierwszy wieczór. To nie to samo co program instalowany ze sklepu z aplikacjami. Jeśli Twoim celem od początku jest ikona w sklepie, sprawdź w dokumentacji wybranego narzędzia, co dokładnie potrafi wyeksportować, zanim zbudujesz cały projekt.

Dla kogo to nie jest

Uczciwie: ta metoda nie pasuje każdemu. Jeśli irytuje Cię, gdy coś działa, a nie wiesz dlaczego, ten sposób pracy będzie Cię męczyć od pierwszego wieczoru. Jeśli oczekujesz, że pierwsza wersja będzie wyglądać jak produkt dojrzałej firmy, też. I jeśli chcesz zbudować rzecz, w której cudze pieniądze albo dane medyczne przechodzą przez Twój kod, nie zaczynaj od tego jako pierwszego projektu.

Pasuje natomiast bardzo dobrze wtedy, gdy masz konkretny, mały problem w swojej pracy i nikogo, kto zrobi Ci na to narzędzie. Wtedy aplikacja z pomocą AI powstaje w kilka wieczorów i realnie coś zmienia. Zanim zainwestujesz tydzień, przejdź krótki test w tekście czy vibe coding jest dla mnie. Uprzedzam też o oczywistym konflikcie interesów: prowadzę kurs Claude Code i stronę kursclaudecode.pro, więc mam interes w tym, żebyś w to wszedł. Dlatego odsyłam Cię do cenników producentów zamiast przepisywać ich warunki, i nie obiecuję Ci ani gotowej apki w pół godziny, ani zarobków.

Następny krok: wybierz jedną rzecz, która Cię wkurza

Nie szukaj pomysłu na aplikację. Przypomnij sobie ostatnią rzecz, którą robiłeś ręcznie w Excelu albo przepisywałeś z maila do maila, i zrób z tego jeden ekran z jednym przyciskiem. Rozpisz kolejność kroków na kartce, zanim otworzysz narzędzie, bo limit kredytów skończy się szybciej niż Twój zapał. Pierwsza wersja fractio.pl, którą w ogóle komuś pokazałem, wyświetlała listę ogłoszeń i nic poza tym. Celem na kilka pierwszych wieczorów jest dokładnie to: wersja, którą sam klikniesz i ocenisz, czy robi tę jedną rzecz.