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

Tag: Systematyczne Kodowanie

8-krokowy system tworzenia aplikacji z AI – od chaosu do sukcesu #EN216