Vibe coding z Claude Code - od pomysłu do aplikacji bez ręcznego pisania kodu

Dzień 1 - Od problemu do zatwierdzonego zakresu

1.1 Najpierw odbiór, potem budowa

Cel: rozpoznać różnicę między atrakcyjną demonstracją a aplikacją, którą można jednoznacznie odebrać.

• analiza gotowej, celowo wadliwej aplikacji z perspektywy użytkownika biznesowego,
• rozdzielenie obserwowanego objawu, oczekiwanego zachowania i przypuszczenia o przyczynie,
• zapis pierwszych kryteriów akceptacji bez używania języka technicznego,
• Ćwiczenie "Kontrakt odbioru": uczestnicy testują wadliwy formularz i tworzą listę zachowań, które muszą działać przed akceptacją.

1.2 Problem, użytkownik i najmniejsze MVP

Cel: zamienić pomysł w mały produkt rozwiązujący jedno konkretne zadanie użytkownika.

• określenie użytkownika, jego sytuacji i zadania do wykonania,
• oddzielenie funkcji koniecznych od atrakcyjnych dodatków,
• wybór jednej ścieżki: od danych wejściowych do wyniku, który jest komuś realnie potrzebny,
• Ćwiczenie "Jedno zdanie, jeden użytkownik, jeden efekt": uczestnik skraca pomysł do problemu, głównego użytkownika i mierzalnego rezultatu.

1.3 Claude Code CLI, Desktop i zasady projektu

Cel: uruchomić bezpieczne środowisko pracy i świadomie dobrać interfejs do danego etapu procesu.

• porównanie Claude Code CLI do kontroli pracy w katalogu z Claude Code Desktop do wizualnego przeglądu zmian i podglądu aplikacji,
• rola Cowork przy briefie lub dokumentacji, bez mieszania go z budową aplikacji,
• katalog projektu, uprawnienia, instrukcje projektowe, hasła i klucze dostępu oraz dane testowe,
• Ćwiczenie "Bezpieczny start projektu": uczestnicy uruchamiają projekt referencyjny, zapisują instrukcje celu, ograniczeń i sposobu sprawdzania oraz potwierdzają, że żadne prawdziwe hasło ani klucz dostępu nie trafia do plików projektu.

1.4 Brief produktu i bramka zakresu

Cel: zakończyć dzień zatwierdzonym, jednostronicowym briefem i zakresem możliwym do realizacji podczas warsztatu.

• opis głównej ścieżki, danych wejściowych, wyniku, ograniczeń i tego, co świadomie zostaje poza zakresem,
• kryteria akceptacji dla wspólnej aplikacji referencyjnej oraz opcjonalnego własnego mini-SaaS,
• wybór ścieżki: dokładne odtworzenie projektu referencyjnego albo kontrolowane rozgałęzienie po wspólnym kręgosłupie,
• Ćwiczenie "Bramka zakresu MVP": uczestnik przedstawia jednostronicowy brief, a prowadzący zatwierdza zakres, zmniejsza go lub kieruje uczestnika do projektu referencyjnego.

Rezultat dnia: zatwierdzony jednostronicowy brief produktu, kryteria akceptacji i decyzja o zakresie projektu.

Dzień 2 - Od planu do pierwszej działającej wersji aplikacji

2.1 Zbadaj i zaplanuj przed budową

Cel: przygotować mały plan pierwszej pełnej ścieżki użytkownika, czyli drogi od wpisania danych do gotowego wyniku na ekranie - takiej, którą da się potem sprawdzić klikając.

• inspekcja istniejących plików i stanu projektu bez natychmiastowej zmiany,
• użycie trybu planowania oraz sprawdzenie zgodności planu z briefem i ograniczeniami,
• podział pracy na kroki, z których każdy kończy się możliwym do zaobserwowania rezultatem,
• Ćwiczenie "Plan pierwszej ścieżki": uczestnicy proszą Claude Code o zbadanie projektu, tworzą plan i zatwierdzają go dopiero po porównaniu z warunkami odbioru zapisanymi pierwszego dnia.

2.2 Zbuduj pierwszą działającą ścieżkę małymi krokami

Cel: uruchomić najkrótszą działającą ścieżkę - od tego, co użytkownik wpisze lub kliknie, do wyniku, który jest mu naprawdę potrzebny.

• budowa jednej ścieżki: od ekranu z danymi wejściowymi do zapisania lub pokazania wyniku,
• krótkie polecenia, jawne ograniczenia i zatrzymanie po każdym sprawdzalnym kroku,
• aktualizacja instrukcji projektowych, gdy pojawia się trwała decyzja,
• Ćwiczenie "Pierwszy wynik na ekranie": uczestnicy budują pierwszą działającą ścieżkę - w projekcie prowadzącego albo we własnym pomyśle - i uruchamiają aplikację w przeglądarce.

2.3 Wersjonowanie jako wehikuł czasu

Cel: zachowywać działające stany i bezpiecznie wracać po nieudanej zmianie.

• różnica między checkpointem Claude Code, wersją projektu i kopią opublikowaną,
• nazywanie punktów kontrolnych po osiągnięciu konkretnego zachowania,
• cofanie zmiany bez utraty całej dotychczasowej pracy oraz granice cofania działań zewnętrznych,
• Ćwiczenie "Kontrolowana awaria i powrót": uczestnicy zapisują działający stan, wprowadzają ryzykowną zmianę, oceniają rezultat i wracają do ostatniego poprawnego punktu.

2.4 Sprawdź zachowanie, ekran i przeglądarkę

Cel: sprawdzić gotową ścieżkę tak, jak sprawdzi ją użytkownik - klikając w aplikacji i oceniając to, co widać na ekranie.

• sprawdzenie trzech sytuacji: poprawne użycie, błędne dane i brak danych,
• porównanie podglądu w Claude Code Desktop z kontrolą w zwykłej przeglądarce,
• zrzuty ekranu, czytelność komunikatów, podstawowa kontrola widoku na różnych rozmiarach,
• Ćwiczenie "Trzy sytuacje": uczestnicy sprawdzają poprawne użycie, błąd i brak danych, zapisują wynik każdej próby oraz zlecają jedną poprawkę.

Rezultat dnia: pierwsza działająca ścieżka aplikacji, od danych wejściowych do wyniku na ekranie, sprawdzona przy poprawnym użyciu, przy błędzie i przy braku danych.

Dzień 3 - Testy, poprawki i bezpieczne dostarczenie

3.1 Debugowanie od objawu do poprawki

Cel: zgłaszać błędy w sposób, który pozwala agentowi znaleźć przyczynę bez chaotycznego przebudowywania aplikacji.

• odtworzenie błędu i zapis kroków, danych wejściowych, wyniku rzeczywistego i oczekiwanego,
• prośba o diagnozę i plan poprawki przed zmianą,
• ponowne uruchomienie testu błędu oraz sprawdzenie, czy poprawka nie zepsuła wcześniejszych zachowań,
• Ćwiczenie "Raport błędu bez zgadywania": uczestnik dokumentuje widoczny objaw, zleca diagnozę, zatwierdza małą poprawkę i wykonuje test regresji.

3.2 Bezpieczeństwo, dane i granice zastosowań

Cel: rozpoznać, kiedy aplikacja może pozostać prototypem lub narzędziem wewnętrznym, a kiedy wymaga wsparcia eksperta.

• ochrona haseł, kluczy dostępu i danych osobowych, minimalne uprawnienia oraz bezpieczne dane testowe,
• różnica między prywatnym podglądem, dostarczeniem wewnętrznym i publiczną produkcją,
• zakaz używania warsztatowego rezultatu do systemów krytycznych, medycznych, finansowych lub regulowanych,
• publiczna produkcja przetwarzająca dane osobowe wymaga eksperckiego audytu bezpieczeństwa, prywatności i zgodności; ukończenie kursu nie oznacza automatycznie bezpieczeństwa produkcyjnego,
• Ćwiczenie "Czerwone światło dla wdrożenia": uczestnicy oceniają scenariusze danych i zastosowań, wybierają bezpieczny sposób dostarczenia oraz zapisują warunki wymagające audytu.

3.3 Podgląd wdrożenia albo dostarczenie wewnętrzne

Cel: udostępnić rezultat w zakresie odpowiednim do jego ryzyka i gotowości.

• lista kontrolna przed publikacją i jawne zatwierdzenie działania zewnętrznego,
• przygotowanie podglądu wdrożenia bez danych wrażliwych albo lokalnego pakietu do użytku wewnętrznego,
• test po dostarczeniu, adres lub instrukcja uruchomienia oraz plan wycofania wersji,
• Ćwiczenie "Bezpieczne dostarczenie": uczestnik publikuje podgląd aplikacji albo przygotowuje lokalne lub wewnętrzne wydanie wraz z testem kontrolnym i instrukcją wycofania.

3.4 Przekazanie, utrzymanie i odbiór końcowy

Cel: przekazać aplikację tak, aby kolejna osoba mogła ją uruchomić, sprawdzić i bezpiecznie rozwijać.

• krótka dokumentacja celu, użytkownika, zakresu, uruchomienia, testów i znanych ograniczeń,
• zapis dalszych pomysłów poza MVP bez dokładania ich do bieżącego wydania,
• plan regularnych kopii, aktualizacji zależności, ponownych testów i odpowiedzialności właściciela,
• końcowy odbiór według kryteriów z Dnia 1 oraz uczciwe oznaczenie elementów nieukończonych,
• Ćwiczenie "Przekazanie w 10 minut": drugi uczestnik uruchamia lub otwiera projekt na podstawie dokumentacji, wykonuje test odbiorczy i zgłasza brakującą informację.

Rezultat dnia: przetestowana i poprawiona aplikacja udostępniona jako bezpieczny podgląd albo przygotowana do lokalnego lub wewnętrznego przekazania, wraz z planem wycofania, dokumentacją i planem utrzymania.