Prototyp w jeden wieczór: workflow z app builderem i przeglądem kodu

Prototyp w jeden wieczór jest realny, jeśli zrozumiesz, czym jest: sposobem na szybkie sprawdzenie pomysłu, a nie pierwszą wersją produktu. Buildery i agenci kodowania skracają budowę ekranów z dni do godzin, ale nie skracają potrzeby przeglądu ani decyzji, co dalej. Poniższy plan zakłada pracę w builderze w stylu v0, który z opisu tworzy aplikację i pozwala ją wdrożyć lub zgłosić zmiany jako pull request, ale zasady są takie same w każdym narzędziu. Porównanie narzędzi znajdziesz w artykule App buildery i agenci do kodu.

Godzina pierwsza: zakres i brief

Zacznij od wąskiego zakresu: jedna osoba, jedna ścieżka, jeden wynik, który da się pokazać. Na przykład „osoba, która ma 10 minut, wpisuje trzy dane i dostaje gotowy plan tygodnia”. Zapisz to w kilku zdaniach, razem z tym, czego prototyp ma nie robić: logowania, płatności, prawdziwych danych. Wąski zakres chroni przed najczęstszą pułapką, czyli rosnącym zestawem funkcji, z których żadna nie działa porządnie. Brief opisujesz tak jak w pierwszej lekcji planu Opisz projekt w pięciu zdaniach.

Godziny druga i trzecia: iteracje

Generuj układ, potem po jednej funkcji. Po każdym kroku sprawdzaj wynik w przeglądarce i poprawiaj konkretnym poleceniem. Zapisuj wersje, żeby móc wrócić do działającego stanu: większość narzędzi trzyma historię zmian, a gdy kod jest w repozytorium, wystarczy commit po każdym udanym kroku. Unikaj poleceń typu „zrób to lepiej”: opisz, co ma się zmienić i po czym poznasz, że zadziałało. Jeśli narzędzie zacznie psuć wcześniejsze elementy, zatrzymaj się i cofnij zmianę, zamiast dopisywać kolejne poprawki do uszkodzonego stanu.

1. 01
   ZakresJedna osoba, jedna ścieżka, jeden wynik.
2. 02
   SzkieletUkład i dane testowe.
3. 03
   FunkcjePo jednej, każda z commitem.
4. 04
   PrzeglądKod pod kątem sekretów i uprawnień.
5. 05
   PokazTrzy osoby, notatki z reakcji.
6. 06
   DecyzjaWyrzucić, rozwijać, napisać od nowa.

Godzina czwarta: przegląd kodu

Zanim pokażesz prototyp komukolwiek poza sobą, przeczytaj kod tak, jakbyś robił przegląd cudzego pull requestu. Szukaj kilku rzeczy. Kluczy i haseł w kodzie lub w plikach, które trafiają do przeglądarki. Miejsc, w których dane użytkownika wchodzą do zapytania bez walidacji. Braku sprawdzenia uprawnień przy operacjach na danych. Zależności o nieznanym pochodzeniu. W repozytorium na GitHubie możesz włączyć skanowanie kodu, które automatycznie szuka podatności i błędów. OWASP wśród zagrożeń dla aplikacji z LLM wymienia między innymi podatności łańcucha dostaw i niewłaściwą obsługę wyjścia modelu; jeśli prototyp pokazuje użytkownikom to, co zwraca model, traktuj to jak niezaufane dane.

Co zapisać na koniec wieczoru

Zanim zamkniesz laptop, zapisz pięć rzeczy: co prototyp potrafi, czego nie potrafi, które decyzje projektowe podjęto, jakie ryzyka znalazł przegląd i co pokazała rozmowa z użytkownikami. Ta notatka jest najcenniejszym wynikiem wieczoru, bo przy ewentualnym przepisaniu zastąpi pół dnia odtwarzania wiedzy. Zachowaj też link do wersji, którą pokazywałeś, i listę poleceń, które dały najlepszy rezultat, bo to zalążek przyszłego briefu dla agenta.

Pokaz i decyzja

Pokaż prototyp trzem osobom z grupy docelowej i patrz, jak go używają, zamiast opowiadać. Zapisuj, gdzie się zacinają i o co pytają. Po pokazie podejmij jedną z trzech decyzji. Wyrzucić: pomysł się nie sprawdził, a koszt nauki był niski. Rozwijać: kierunek jest dobry, kod jest czytelny, a przegląd nie wykazał poważnych problemów. Napisać od nowa: pomysł działa, ale prototyp nie nadaje się do utrzymania. Ta ostatnia decyzja też jest w porządku, bo prototyp zrobił swoją robotę. Warto wtedy zabrać do wersji docelowej wnioski i testy przypadków, a kod pisać już z agentem pracującym na repozytorium, o czym piszę w artykule o pierwszej sesji z Claude Code.

Stan wiedzy: 20 października 2026. Narzędzia się zmieniają; ten plan nie zależy od konkretnego produktu.