Poniższe notatki powstały na podstawie prezentacji o systematycznym podejściu do tworzenia aplikacji z wykorzystaniem sztucznej inteligencji. Wszystkie przemyślenia, obserwacje i praktyczne wskazówki pochodzą od autora prezentacji.
TL;DR
- Większość projektów AI kończy się porażką z powodu braku planowania i chaotycznego podejścia do kodowania
- 8-krokowy system zastępuje spontaniczne „vibe coding” systematycznym procesem od pomysłu do wdrożenia
- Kluczowe etapy obejmują planowanie MVP, wybór technologii, projektowanie UX/UI, specyfikację techniczną i implementację
- Metodologia „evaluator-optimizer” pozwala AI ewaluować własne rozwiązania i je poprawiać
- Praktyczny przykład: aplikacja do zarządzania promptami zbudowana w 2 godziny z godzinną poprawką błędów
- Planowanie zajmuje więcej czasu, jednak gwarantuje lepszy efekt końcowy niż chaotyczne kodowanie
- Narzędzia wspomagające: Claude Code, Gemini, Mobin do inspiracji designu, Playbook do zasad kodowania
Większość osób marzy o jednym promptie, który zbuduje aplikację marzeń. Rzeczywistość jest jednak inna – bez systematycznego podejścia 90% projektów AI kończy się frustracją i porzuceniem. Autor prezentacji przedstawia sprawdzone rozwiązanie tego problemu.
Dlaczego większość projektów AI kończy się porażką
Typowy cykl „vibe coding” wygląda znajomo dla każdego, kto próbował tworzyć aplikacje z AI:
- Pomysł na aplikację – bez głębszego przemyślenia
- Chaotyczne promptowanie – losowe funkcje, które mijają się z celem
- Próby naprawiania – walka z błędami na bieżąco
- Rozrosnięty kod – trudny do zarządzania
- Frustracja i walka – godziny bez widocznego postępu
- Porzucenie projektu – rozpoczęcie nowego cyklu
Prelegent podkreśla fundamentalną prawdę: „AI może pisać za ciebie linie kodu, pomagać w debugowaniu, może nawet pomóc wybrać stos technologiczny, ale nie jest jeszcze w stanie zastąpić ludzkiego myślenia i kreatywności.”
8-stopniowy system planowania aplikacji
Rozwiązaniem jest systematyczne podejście, które autor nazywa „planning mindset”. System składa się z ośmiu kluczowych kroków, które przekształcają mgliste pomysły w konkretne specyfikacje.
Checklist kompletnego systemu:
□ Krok 1: Zdefiniuj MVP i kluczowe funkcje
□ Krok 2: Wybierz stos technologiczny
□ Krok 3: Zaprojektuj user stories i UX
□ Krok 4: Określ stany interfejsu
□ Krok 5: Stwórz specyfikację techniczną
□ Krok 6: Ustal zasady kodowania
□ Krok 7: Zaplanuj zadania z ewaluacją
□ Krok 8: Generuj kod krok po kroku
Krok 1-2: od pomysłu do MVP i wyboru technologii
Pierwszy krok wykorzystuje persona prompting – autor każe AI wcielić się w rolę założyciela SaaS, który ma nadmierny fokus na rozwiązywaniu problemów. Jak wyjaśnia: „Jesteś bardziej obsesyjny na punkcie problemu niż rozwiązania.” To kluczowe, ponieważ zmusza do myślenia o rzeczywistych problemach użytkowników.
Proces jest iteracyjny – za każdym razem, gdy użytkownik odpowiada na pytania, system integruje odpowiedzi i regeneruje całkowicie nowy wynik. Dlatego możliwy jest ciągły proces dopracowywania koncepcji.
Format obejmuje elevator pitch, sformułowanie problemu, grupę docelową, unique selling point, funkcje z user stories, zagadnienia UX, wymagania niefunkcjonalne, strategię monetyzacji i krytyczne pytania do wyjaśnienia.
W praktycznym przykładzie aplikacji do zarządzania promptami autor jasno ogranicza zakres: „Chcę zbudować MVP. Jaka jest najmniejsza wersja tej rzeczy, która będzie faktycznie funkcjonalna i wartościowa dla kogoś?”
Drugi krok to wybór stosu technologicznego. Autor myśli o tym jak o „przypisywaniu stosu technologicznego do każdej z tych funkcji” – każda funkcja ma przypisane konkretne technologie. Z kolei wykorzystuje też diagramy systemowe, ponieważ „lubię mieć diagram systemu, żebym mógł na niego spojrzeć i zobaczyć, gdzie wszystko się łączy.”
Podaje praktyczny przykład: jeśli masz upload obrazów, musisz pomyśleć o CDN, kompresji, systemie kolejek, żeby serwer nie upadł przy tysiącach uploadów dziennie.
Krok 3-4: UX/UI i stany interfejsu
Trzeci krok to projektowanie user stories z głębszym zrozumieniem filozofii produktu. Autor podkreśla kluczowy insight: „Świetne produkty, czy to oprogramowanie, czy cokolwiek innego, sprawiają, że użytkownik czuje się w określony sposób w stosunku do siebie lub świata wokół niego. Jak możemy świadomie zmierzać w tym kierunku? Zamiast pozwalać modelowi językowemu robić co do cholery chce.”
Prelegent używa narzędzia Mobin do zbierania inspiracji – można wybrać aplikacje lub strony, przeszukać konkretne firmy jak 11labs i pobrać zrzuty ekranu jako inspirację. Następnie tworzy szczegółowe historie użytkownika w formacie „Jako X, chcę Y, żeby Z.”
Proces obejmuje również konkretne wytyczne UX jak wykorzystywanie przestrzeni oddechowej z strategicznymi akcentami kolorystycznymi do tworzenia hierarchii wizualnej, używanie negatywnej przestrzeni, upewnianie się, że nie przeciążamy użytkownika zbyt dużą ilością informacji oraz stopniowe odkrywanie informacji.
Etap kończy się bardzo szczegółowym opisem tego, jak użytkownicy będą przemieszczać się przez aplikację. Autor pokazuje przykłady: lewa boczna belka z zwijającym się drzewem folderów, natywne menu kontekstowe po prawym kliknięciu, funkcjonalność przeciągnij i upuść z wizualnym feedbackiem.
Czwarty krok to definiowanie stanów interfejsu. Jak wyjaśnia autor: „Każdy ekran technicznie może istnieć w różnych stanach. Podstawowy przykład: co się dzieje, gdy jest pusty? Co się dzieje, gdy żądanie się nie powiedzie? Co się dzieje, gdy użytkownik wykona udaną akcję?”
Przykład rejestracji pokazuje różne stany: stan początkowy z tekstem zastępczym, stan fokusowania z subtelnym podświetleniem i walidacją w czasie rzeczywistym, stan ładowania z animacją oraz stan sukcesu z płynną animacją przejścia.
Krok 5-6: specyfikacja techniczna i zasady kodowania
Piąty krok to stworzenie szczegółowej specyfikacji technicznej. Autor łączy wszystkie poprzednie elementy w spójny dokument zawierający architekturę systemu, szczegółowe wymagania dla każdej funkcji, modele danych, endpointy API oraz zagadnienia bezpieczeństwa. W rezultacie włącza też system projektowy z kolorami, typografią i komponentami.
Prelegent wydaje kluczowe ostrzeżenie: „Jeśli nie przejdziesz przez ten etap, powiem ci teraz, że dajesz ogromny poziom autonomii i kontroli modelowi językowemu, aby zdecydował, czym będzie ta aplikacja.” Oznacza to, że bez tej specyfikacji AI samo decyduje, jak aplikacja ma wyglądać i działać.
Cały dokument specyfikacji to około 15,000 tokenów – możliwy do zarządzania dla nowoczesnych modeli językowych, jednak wystarczająco szczegółowy, żeby zachować wszystkie detale w kolejnych krokach.
Mimo to autor podkreśla: „Wielu innych ludzi lekceważy te dwa etapy projektowe, przez które właśnie przeszliśmy. Pytają dopiero na tym etapie o generowanie projektów. Możesz to zrobić, ale nie otrzymasz niczego nawet zbliżonego do poziomu szczegółowości, który właśnie uzyskaliśmy z tego ćwiczenia.”
Szósty krok to ustalenie zasad kodowania jako guardrails. Autor wykorzystuje Playbook.com do znalezienia najlepszych praktyk dla wybranego frameworka. Te zasady działają jak „guardrails” – barierki ochronne podczas implementacji, zapobiegające błędom i zapewniające spójność kodu.
Krok 7-8: planowanie zadań i generowanie kodu
Siódmy krok wykorzystuje metodologię „evaluator-optimizer” z dużym kontekstem. Autor świadomie odchodzi od popularnych narzędzi do planowania zadań: „Wiele z tych narzędzi do planowania zadań jest naprawdę dobrych, jeśli chodzi o małe funkcje. Małe zadania, które trzeba wykonać. Jednak w przypadku czegoś tak dużego, jak budowanie tej całej rzeczy, straci tak dużo kontekstu.”
Zamiast tego wykorzystuje Gemini ze względu na bardzo duże okno kontekstu i lepsze zachowywanie instrukcji krok po kroku. Prelegent tworzy szczegółowy plan implementacji z 28 krokami, a następnie prosi AI o wielokrotną ewaluację własnego planu:
- Jak dobrze uwzględniono wszystkie elementy stosu technologicznego?
- Jak dobrze przemyślano zależności między krokami?
- Jak dobrze uwzględniono różne stany każdego ekranu?
Autor dzieli się kluczowym spostrzeżeniem: „Myślę, że ze wszystkiego, co robiłem z vibe coding, największym źródłem frustracji jest to, że spędzasz czas na szczegółowym opracowywaniu tego planu… A potem, gdy faktycznie budujesz tę rzecz, nie zachowuje wszystkich szczegółów.” Dlatego metodologia evaluator-optimizer jest tak ważna.
Ósmy krok to generowanie kodu krok po kroku. Autor wykorzystuje Claude Code i implementuje każdy element zgodnie z planem. Jednak wydaje ważną radę dla początkujących: „Jeśli jesteś początkującym, musisz zrozumieć swoje ograniczenia i spróbować pozwolić tym narzędziom spotkać się z tobą tam, gdzie jesteś.” Oznacza to dawanie mniejszych fragmentów zadań i sprawdzanie, co zostało zbudowane między krokami.
Praktyczny przykład – aplikacja do zarządzania promptami
Autor demonstruje cały proces na przykładzie aplikacji do zarządzania promptami. W rezultacie finalny produkt oferuje system folderów z hierarchią, podgląd promptów z podświetlaniem składni, obsługę XML i Markdown, wersjonowanie oraz integrację z Supabase.
Implementacja zajęła 2 godziny, z czego około 1,5 godziny to naprawa błędów TypeScript. Prelegent szczerze przyznaje: „Coś, co zrobiłbym inaczej, to wprowadzenie zasad dotyczących tego, jak system ma radzić sobie z TypeScript i typowaniem wszystkiego w projekcie.”
Finalny efekt to profesjonalna aplikacja z dashboard, który jak stwierdza autor, „faktycznie wygląda całkiem nieźle”, z funkcjami jak tworzenie promptów, automatyczne formatowanie XML/Markdown, wybór platform (Claude, OpenAI), statusy draft/published/archived, system tagów i folderów.
Plany rozwoju aplikacji pokazują potencjał systematycznego podejścia: „Rozważam stworzenie marketplace, żeby ludzie mogli kupować i handlować promptami między sobą. Myślę, że byłoby to naprawdę fajne. Chcę dodać różne funkcje społecznościowe. Chcę dodać funkcjonalność, gdzie możesz faktycznie wykorzystać system AI do poprawy swoich promptów.”
To dowodzi, że dobrze zaplanowana podstawa pozwala na łatwe rozszerzanie funkcjonalności w przyszłości.
Korzyści systematycznego podejścia
Porównując chaotyczne podejście z systematycznym planowaniem, autor pokazuje kluczowe różnice:
Chaotyczne podejście:
- Podstawowa funkcjonalność – bez przemyślanych detali
- Brak stanów interfejsu – tylko „szczęśliwa ścieżka”
- Frustracja podczas rozwoju – ciągłe naprawianie błędów
- Porzucanie projektów – brak jasnego kierunku
- Generyczne rozwiązania – podobne do wszystkich innych
Systematyczne podejście:
- Szczegółowe specyfikacje – zachowywane przez cały proces
- Przemyślane stany i przejścia – profesjonalny UX
- Kontrolowany development – jasny plan działania
- Ukończone projekty – wyższy wskaźnik sukcesu
- Unikalne aplikacje – dostosowane do konkretnych potrzeb
Autor podkreśla: „Chcesz aplikację, która będzie wyjątkowo twoja, prawda? Jeśli robisz to, co robi każdy inny i po prostu idziesz do narzędzia jak REPLit… po prostu otrzymasz cokolwiek losowego, co model językowy zdecydował, że to oznacza.”
Framework promptów do 8-krokowego systemu
Autor szczegółowo opisuje strukturę promptów używanych w każdym kroku. Oto framework oparty na jego wyjaśnieniach:
1. Prompt definicji MVP (Krok 1)
Struktura:
- Persona: „Jesteś założycielem SaaS z nadmiernym fokusem na rozwiązywaniu problemów. Jesteś bardziej obsesyjny na punkcie problemu niż rozwiązania.”
- Zadanie: Iteracyjne dopracowywanie MVP z regenerowaniem całego wyniku po każdej odpowiedzi
- Format: Elevator pitch, sformułowanie problemu, grupa docelowa, unique selling point, funkcje z user stories, zagadnienia UX, wymagania niefunkcjonalne, strategia monetyzacji, krytyczne pytania
Kiedy stosować: Na samym początku projektu, gdy masz ogólny pomysł i chcesz go przekształcić w konkretne specyfikacje MVP.
2. Prompt planowania tech stack (Krok 2)
Struktura:
- Persona: „Jesteś starszym inżynierem oprogramowania”
- Zadanie: „Uzyskaj naprawdę pełny obraz tej aplikacji” z „przypisywaniem stosu technologicznego do każdej z tych funkcji”
- Format: Dla każdej funkcji: 2-3 zdaniowy opis, technologie, wymagania + diagram systemu
- Input: Funkcje z kroku 1 + wybrane technologie
Kiedy stosować: Po zdefiniowaniu MVP, gdy potrzebujesz przypisać konkretne technologie do każdej funkcji.
3. Prompt user stories (Krok 3)
Struktura:
- Persona: „Założyciel SaaS” skupiony na doświadczeniu użytkownika
- Zadanie: Breakdown user stories w formacie „Jako X, chcę Y, żeby Z”
- Format: User stories + wypunktowany krok po kroku user journey + zagadnienia UX
- Wytyczne: „przestrzeń oddechowa z strategicznymi akcentami kolorystycznymi”, „stopniowe odkrywanie informacji”
Kiedy stosować: Po wybraniu tech stack, gdy chcesz przemyśleć jak użytkownicy będą korzystać z aplikacji.
4. Prompt style guide (Krok 4a)
Struktura:
- Input: Inspiracje wizualne (zrzuty ekranu z Mobin lub innych źródeł)
- Zadanie: Stworzenie style guide z kolorami, fontami, komponentami, animacjami
- Format: Comprehensive color palette, typography, spacing, animations
Kiedy stosować: Gdy masz user stories i chcesz zdefiniować wizualną identyfikację aplikacji.
5. Prompt stanów UI (Krok 4b)
Struktura:
- Input: Style guide z poprzedniego kroku
- Zadanie: Definiowanie stanów każdego ekranu (pusty, ładowanie, sukces, błąd)
- Format: Szczegółowe opisy stanów z animacjami i przejściami
Kiedy stosować: Po stworzeniu style guide, gdy chcesz przemyśleć wszystkie możliwe stany interfejsu.
6. Prompt specyfikacji technicznej (Krok 5)
Struktura:
- Input: Wszystkie poprzednie kroki + project rules z Playbook
- Zadanie: Stworzenie comprehensive PRD (Product Requirements Document)
- Format: Architektura systemu, wymagania techniczne, modele danych, endpointy API, bezpieczeństwo, infrastruktura
Kiedy stosować: Gdy masz kompletne UX/UI i chcesz wszystko połączyć w jedną techniczną specyfikację.
7. Prompt planowania zadań (Krok 7)
Struktura:
- Input: Pełna specyfikacja techniczna + project rules + core application intent
- Zadanie: „Stwórz szczegółowy plan krok po kroku, który zachowuje wysoki stopień szczegółowości”
- Format: Breakdown faza po fazie z konkretnymi krokami implementacji
Kiedy stosować: Po kompletnej specyfikacji, gdy chcesz przełożyć plan na konkretne zadania do implementacji.
8. Prompty evaluator-optimizer (Krok 7 – ewaluacja)
Struktura – Ewaluacja 1:
- Zadanie: „Oceń swój plan w stosunku do oryginalnej specyfikacji technicznej”
- Pytania: „Jak dobrze uwzględniłeś wszystkie elementy stosu technologicznego? Jak dobrze rozważyłeś zależności między różnymi krokami? Jak dobrze uwzględniłeś różne stany każdego ekranu?”
Struktura – Ewaluacja 2:
- Zadanie: „Jak dobrze określiłeś zagadnienia UX UI? Jak dobrze rozważyliśmy różne stany funkcji ekranu i jak się zmieniają?”
- Format: Dodanie sekcji UX/UI do każdego kroku
Kiedy stosować: Po pierwszym planie implementacji, żeby upewnić się, że nic nie zostało pominięte.
9. Prompt implementacji (Krok 8)
Struktura:
- Input: Pojedynczy krok z planu + kontekst (np. „upewnij się, że odwołujesz się do /style-guide.md”)
- Zadanie: Implementacja konkretnego kroku
- Rada: „Jeśli jesteś początkującym, musisz zrozumieć swoje ograniczenia i spróbować pozwolić tym narzędziom spotkać się z tobą tam, gdzie jesteś”
Kiedy stosować: Podczas implementacji, krok po kroku zgodnie z planem.
Kluczowa uwaga autora: Wszystkie oryginalne prompty są dostępne za darmo w grupie szkolnej poniżej oryginalnego wideo.
Kluczowy insight
Paradoks kontroli nad AI
Standardowo myślimy: AI to narzędzie, które pomaga nam budować dokładnie to, co chcemy
W praktyce okazuje się, że: Bez szczegółowego planowania to AI przejmuje kontrolę nad kluczowymi decyzjami projektowymi i decyduje, jak będzie wyglądać nasza aplikacja
Dlaczego to jest istotne: Jak trafnie ujął autor: „Jeśli nie przejdziesz przez ten etap, dajesz ogromny poziom autonomii i kontroli modelowi językowemu, aby zdecydował, czym będzie ta aplikacja.” W rezultacie oddajesz nieświadomie kontrolę nad architekturą, UX, funkcjonalnością i estetyką swojego produktu.
Test na jutro: Następnym razem gdy rozpoczynasz projekt z AI, zamiast od razu promptować „zbuduj mi aplikację do X”, spróbuj najpierw stworzyć szczegółową specyfikację w 8 krokach i sprawdź, jak drastycznie różni się poziom kontroli nad finalnym produktem.
Systematyczne podejście do tworzenia aplikacji z AI nie jest szybsze od chaotycznego kodowania, jednak gwarantuje znacznie lepsze rezultaty. Jak pokazuje praktyczny przykład, inwestycja w planowanie zwraca się jakością i funkcjonalnością finalnego produktu.
Kluczowe przesłanie autora: „Spędzisz więcej czasu na fazie planowania, ale otrzymasz z drugiej strony coś, co jest naprawdę dobre.” To fundamentalna różnica między podejściem systematycznym a chaotycznym – planowanie wymaga więcej czasu z przodu, jednak oszczędza dziesiątki godzin frustracji później.
Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://www.youtube.com/watch?v=arWg7gYVD_0
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.