Przykłady vibe coding: 10 typów prawdziwych aplikacji, prompty i co poszło źle
Najczęstsze przykłady vibe coding to małe, użyteczne aplikacje webowe: trackery, strony rezerwacji, wewnętrzne narzędzia, portale dla klientów, strony lądowania, quizy, dashboardy i proste narzędzia AI. Poniżej znajdziesz dziesięć z nich. Przy każdym zobaczysz, kto ją buduje, pierwszy prompt, co zwykle idzie źle i prompt poprawkowy, który to naprawia.
Są to kompozyty projektów, z którymi ludzie najczęściej przychodzą do kreatorów aplikacji AI, a nie studia przypadków jednej osoby. Prompty nadają się do skopiowania. Błędy to te, które wracają raz po raz, dlatego są najbardziej przydatną częścią. Jeśli sam vibe coding jest dla ciebie nowy, zacznij od czym jest vibe coding.
1. Osobisty tracker budżetu
Kto to buduje: osoby, które próbowały arkuszy i się poddały.
Pierwszy prompt:
Zbuduj miesięczny tracker budżetu. Dodaję wydatki z kwotą, kategorią (jedzenie, czynsz, transport, rozrywka, inne), datą i notatką. Pokaż sumę tego miesiąca dla każdej kategorii jako wykres słupkowy oraz listę ostatnich wydatków. Mogę ustawić budżet dla kategorii i zobaczyć, ile zostało.
Co poszło źle: wykres liczył każdy kiedykolwiek wprowadzony wydatek, a nie tylko z tego miesiąca, więc po drugim miesiącu każda kategoria wyglądała na przekroczoną. Poza tym kwoty wpisane z przecinkiem („1,200”) zapisywały się jako 1.
Prompt poprawkowy:
Wykres i sumy mają uwzględniać tylko wydatki z wybranego miesiąca. Dodaj na górze wybór miesiąca, domyślnie bieżącego. Akceptuj też kwoty wpisane z przecinkami lub spacjami i zapisuj je jako liczby.
Wniosek: „ten miesiąc” to reguła. Mów reguły na głos.
2. Strona rezerwacji dla małego salonu
Kto to buduje: właściciele małych firm zmęczeni rezerwowaniem przez telefon i wiadomości.
Pierwszy prompt:
Zbuduj stronę rezerwacji dla mojego salonu. Klienci wybierają usługę, datę i wolny termin, a potem podają imię i telefon. Mam prywatną stronę administratora za logowaniem, która pokazuje rezerwacje według dnia.
Co poszło źle: dwóch klientów zarezerwowało ten sam termin 10:00 w odstępie minuty, bo strona sprawdzała dostępność dopiero przy pierwszym załadowaniu. Rezerwacja koloryzacji na 90 minut też nie blokowała kolejnych terminów.
Prompt poprawkowy:
Gdy klient wyśle rezerwację, sprawdź po stronie serwera, czy każdy termin, który ona obejmuje, jest nadal wolny, i odrzuć ją komunikatem „Ten termin właśnie został zajęty”, jeśli nie jest. Usługa blokuje cały swój czas, więc rezerwacja na 90 minut o 10:00 blokuje 10:00, 10:30 i 11:00.
Wniosek: wszystko, co dwie osoby mogą zrobić jednocześnie, wymaga sprawdzenia po stronie serwera. Pełna wersja: jak zbudować aplikację do rezerwacji.
3. Menu restauracji z kodem QR
Kto to buduje: właściciele kawiarni i restauracji, którzy za często drukują menu.
Pierwszy prompt:
Zbuduj mobilną stronę menu dla mojej kawiarni. Sekcje: śniadania, obiady, napoje i desery; każda pozycja ma nazwę, cenę, krótki opis i oznaczenia dietetyczne (wegańskie, bezglutenowe). Potrzebuję strony administratora do edycji pozycji i oznaczania ich jako wyprzedanych. Pokaż kod QR do wydrukowania, który prowadzi do menu.
Co poszło źle: nic się nie zepsuło, ale menu działało wolno w Wi-Fi kawiarni, bo dla każdej pozycji ładowano pełnorozmiarowe zdjęcia z telefonu.
Prompt poprawkowy:
Zdjęcia w menu są za ciężkie. Zmniejsz przesłane obrazy do maksymalnie 800 px szerokości, skompresuj je i ładuj leniwie, w miarę przewijania przez odwiedzającego.
Wniosek: testuj przy wolnym połączeniu, a nie tylko we własnym biurze.
4. Tracker sprzętu lub zapasów dla zespołu
Kto to buduje: osoby z działu operacji, które zastępują wspólny arkusz.
Pierwszy prompt:
Zbuduj narzędzie do zapasów dla naszego zespołu magazynowego. Pozycje mają nazwę, SKU, ilość, lokalizację i minimalny poziom. Pracownicy logują się, mogą dodać zapas, usunąć zapas z podaniem powodu i zobaczyć listę pozycji poniżej minimum wyróżnionych na czerwono. Zachowaj historię każdej zmiany i tego, kto ją wykonał.
Co poszło źle: w historii pokazywało się „użytkownik 3” zamiast imion, a usunięcie większej ilości, niż było w magazynie, dawało ujemną ilość.
Prompt poprawkowy:
Pokazuj w historii imię osoby, a nie jej ID. Nie pozwalaj na usunięcie, które obniżyłoby ilość poniżej zera; zamiast tego pokaż komunikat „Na stanie jest tylko 4”.
Wniosek: opisz, co ma być niemożliwe, a nie tylko, co ma być możliwe. Resztę omawia nasz przewodnik jak zbudować aplikację do zarządzania zapasami.
5. Portal dla klientów freelancera lub studia
Kto to buduje: projektanci, księgowi, konsultanci i agencje.
Pierwszy prompt:
Zbuduj portal dla klientów. Zapraszam klientów e-mailem. Każdy klient loguje się i widzi tylko swoje projekty, pliki i faktury oraz może zostawiać komentarze. Jako administrator loguję się i widzę wszystko.
Co poszło źle: to najpoważniejszy błąd z tej listy. Strony pokazywały każdemu klientowi tylko jego projekty, ale serwer zwracał dowolny projekt, jeśli zmieniło się numer w pasku adresu. Klikanie jako jeden klient tego nie ujawniało.
Prompt poprawkowy:
Sprawdź każdą trasę serwera, która zwraca projekty, pliki, komentarze lub faktury. Każda ma potwierdzać, że zalogowany klient jest właścicielem rekordu, a w przeciwnym razie zwracać „nie znaleziono”. Potem przetestuj: zaloguj się jako klient A i spróbuj otworzyć projekt klienta B po jego ID.
Wniosek: ukrycie czegoś na ekranie to nie to samo co ochrona. Więcej w czy vibe coding jest bezpieczne?.
6. Strona startowa z listą oczekujących
Kto to buduje: założyciele, którzy testują pomysł, zanim go zbudują.
Pierwszy prompt:
Zbuduj stronę lądowania dla aplikacji, która pomaga korepetytorom planować lekcje i pobierać płatności. Nagłówek, podtytuł, zapis e-mailem, trzy korzyści, sekcja „jak to działa” i FAQ. Zapisuj zapisy do bazy z datą i pozwól mi pobrać je jako CSV z prywatnej strony.
Co poszło źle: w ciągu kilku dni lista zapełniła się śmieciowymi zapisami od botów, a strona nie miała tytułu ani opisu, więc udostępniane linki pokazywały pusty podgląd.
Prompt poprawkowy:
Dodaj podstawową ochronę przed botami do formularza zapisu (ukryte pole-pułapka i limit 5 zapisów z jednego IP na godzinę). Dodaj tytuł strony, meta-opis i obraz do udostępniania w mediach społecznościowych.
Wniosek: publiczny formularz zostanie znaleziony. Zobacz jak zbudować stronę z listą oczekujących.
7. Aplikacja quizowa dla nauczyciela
Kto to buduje: nauczyciele i trenerzy, którzy chcą czegoś lżejszego niż LMS.
Pierwszy prompt:
Zbuduj aplikację quizową dla mojej klasy. Tworzę quizy z pytaniami wielokrotnego wyboru, każde z jedną poprawną odpowiedzią. Uczniowie dołączają kodem i swoim imieniem, odpowiadają na pytania i na końcu widzą wynik. Mam tabelę wyników dla każdego quizu.
Co poszło źle: poprawne odpowiedzi były wysyłane do przeglądarki razem z pytaniami, więc ciekawski uczeń mógł je odczytać w kodzie strony. Uczniowie mogli też wysyłać quiz wielokrotnie, aż dostali 100%.
Prompt poprawkowy:
Nie wysyłaj poprawnych odpowiedzi do przeglądarki. Sprawdzaj odpowiedzi na serwerze po wysłaniu. Zezwól na jedno zgłoszenie na imię ucznia w każdym quizie i pokaż nauczycielowi, jeśli ktoś spróbuje ponownie.
Wniosek: przeglądarka należy do użytkownika. Wszystko, co tam jest, da się odczytać.
8. Mała aplikacja AI
Kto to buduje: marketerzy, autorzy i założyciele, którzy chcą wyspecjalizowanego pomocnika AI.
Pierwszy prompt:
Zbuduj narzędzie, które zamienia opis produktu w pięć postów w mediach społecznościowych w różnych tonach (przyjazny, ekspercki, zabawny, krótki, długi). Użyj API AI. Wklejam opis, wybieram platformę i dostaję posty z przyciskami kopiowania.
Co poszło źle: pierwsza wersja wywoływała usługę AI bezpośrednio z przeglądarki, a klucz API był w kodzie strony, skąd każdy mógł go skopiować i wygenerować wysoki rachunek.
Prompt poprawkowy:
Przenieś wywołanie AI na serwer. Zapisz klucz API jako sekret, nigdy w kodzie frontendu. Ogranicz każdego odwiedzającego do 20 generacji dziennie.
Wniosek: klucze należą do sekretów na serwerze. Zobacz jak chronić klucze API i jak dodać funkcje AI do aplikacji.
9. Dwujęzyczna strona firmy: arabski i angielski
Kto to buduje: firmy z Zatoki Perskiej i szerszego świata arabskiego, obsługujące dwa języki.
Pierwszy prompt:
Zbuduj stronę dla mojej firmy projektowania wnętrz w języku arabskim i angielskim, z przełącznikiem języka. Strony: start, usługi, portfolio, o nas i kontakt. Arabski ma być w pełni od prawej do lewej.
Co poszło źle: tekst arabski był wyrównany do prawej, ale układ nie był odbity lustrzanie: strzałki wskazywały w złą stronę, a menu było po niewłaściwej stronie. Numery telefonów też w niektórych miejscach wyświetlały się od tyłu.
Prompt poprawkowy:
W wersji arabskiej odbij cały układ: ustaw kierunek strony od prawej do lewej, przenieś menu na prawą stronę, odwróć ikony wskazujące kierunek i trzymaj numery telefonów oraz e-maile od lewej do prawej wewnątrz tekstu arabskiego.
Wniosek: układ od prawej do lewej to coś więcej niż wyrównanie. Mythex obsługuje arabski i inne układy od prawej do lewej, a prompty możesz pisać bezpośrednio po arabsku.
10. Tracker, który staje się aplikacją na telefon
Kto to buduje: trenerzy, siłownie i grupy społecznościowe, których użytkownicy są cały czas w telefonach.
Pierwszy prompt:
Zbuduj dziennik treningów dla moich klientów z treningu personalnego. Każdy klient się loguje, widzi plan przypisany na tydzień, odhacza ćwiczenia i zapisuje ciężary. Ja widzę postępy każdego klienta na wykresie.
Co poszło źle: aplikacja webowa działała, ale na telefonach przyciski były za małe, by trafić w trakcie treningu, a wykres był nieczytelny.
Prompt poprawkowy:
Zaprojektuj to do obsługi jedną ręką na telefonie: duże obszary dotyku u dołu ekranu, jedno ćwiczenie na ekran z dużymi przyciskami Dalej i Gotowe oraz prosty tygodniowy wykres postępów.
Wniosek: jeśli ludzie będą używać tego w telefonie, projektuj najpierw pod telefon. W planie Mythex Pro opublikowaną aplikację można zamienić w aplikację na Androida do Google Play i aplikację na iPhone'a wysyłaną do TestFlight; aplikacja na telefon otwiera twoją opublikowaną aplikację, więc każda publikacja ją aktualizuje. Zobacz stronę kreatora aplikacji mobilnych.
Wzorce za tymi przykładami
We wszystkich dziesięciu przypadkach błędy układają się w kilka grup:
| Błąd | Gdzie się pojawił | Jak go wychwycić |
|---|---|---|
| Reguła nigdy nie została powiedziana | Miesiąc budżetu, zapasy poniżej zera | Wpisz reguły do promptu |
| Dwie osoby naraz | Podwójna rezerwacja w salonie | Testuj w dwóch oknach przeglądarki |
| Ukryte nie znaczy chronione | Portal klienta, odpowiedzi quizu | Spróbuj użyć ID innego użytkownika; zobacz kod źródłowy strony |
| Sekrety w przeglądarce | Klucz narzędzia AI | Zapytaj AI, gdzie leży każdy klucz |
| Nadużycia publicznego formularza | Boty na liście oczekujących | Dodaj limity zapytań przed udostępnieniem |
| Telefon jako dodatek | Zdjęcia w menu, przyciski treningu | Testuj na prawdziwym telefonie na danych mobilnych |
Żadne z nich nie wymaga czytania kodu. Wymagają testowania jak ciekawski, lekko wrogi użytkownik i precyzyjnego opisywania tego, co widzisz.
Wypróbuj sam
Wybierz przykład najbliższy twojemu pomysłowi, skopiuj jego pierwszy prompt i zmień szczegóły. Potem użyj promptu poprawkowego jako listy kontrolnej, zanim cokolwiek udostępnisz. Nasza ściąga promptów do vibe coding ma 30 kolejnych, a jak zbudować aplikację metodą vibe coding prowadzi jeden projekt od pomysłu do opublikowanej aplikacji. Gdy będziesz gotowy, zacznij w kreatorze aplikacji AI albo przejrzyj szablony, żeby mieć gotowy punkt startowy.
Pytania
Co można zbudować metodą vibe coding?
Najlepiej działają aplikacje webowe i strony z kilkoma ekranami i jasnymi regułami: trackery, strony rezerwacji, wewnętrzne narzędzia, portale dla klientów, strony lądowania, quizy, dashboardy i małe narzędzia AI. Duże aplikacje ze złożonymi uprawnieniami, funkcjami czasu rzeczywistego lub surowymi wymogami zgodności są możliwe, ale wymagają więcej przeglądu.
Czy to są prawdziwe przykłady vibe coding?
To kompozyty typów aplikacji, które ludzie najczęściej budują w kreatorach aplikacji AI, z promptem, od którego się zaczynają, i problemami, które zwykle się pojawiają. Prompty są prawdziwe i gotowe do skopiowania; szczegóły zostały uogólnione, a nie wzięte z projektu jednej osoby.
Co najczęściej psuje się w aplikacjach stworzonych metodą vibe coding?
Dane, które nie zapisują się po odświeżeniu, użytkownicy widzący nawzajem swoje rekordy, układy łamiące się na telefonach, podwójne rezerwacje lub podwójne wysyłki formularza oraz klucze tajne wstawione w kod działający w przeglądarce. Każdy z tych problemów jest łatwy do przetestowania, gdy wiesz, czego szukać.
Czy można zbudować aplikację mobilną metodą vibe coding?
Przyjazną dla telefonów aplikację webową możesz zbudować metodą vibe coding w dowolnym kreatorze. W planie Mythex Pro opublikowana aplikacja może też stać się aplikacją na Androida, którą wgrasz do Google Play, oraz aplikacją na iPhone'a wysyłaną do TestFlight, a każda publikacja aktualizuje także aplikację na telefon.
Czy aplikacja zbudowana metodą vibe coding może zarabiać?
Tak, jeśli rozwiązuje prawdziwy problem ludzi, którzy zapłacą. Typowe przykłady to narzędzia do rezerwacji, kalkulatory wycen i portale dla klientów małych firm. Zanim od kogokolwiek weźmiesz pieniądze, dodaj porządne logowanie, ostrożnie przetestuj płatności i sprawdź podstawy bezpieczeństwa.