Poniższe notatki pochodzą z prezentacji Sean’a, eksperta w dziedzinie sztucznej inteligencji i vibe coding. Wszystkie przedstawione przemyślenia, obserwacje i wnioski to rezultat jego doświadczeń w pracy z narzędziami AI do programowania.

TL;DR – najważniejsze punkty

Planowanie to 60-70% procesu – większość czasu programowania powinna być poświęcona na planowanie, nie na samo kodowanie
Używaj dokumentowanych stosów technologicznych – LLM-y są trenowane na konkretnych przykładach kodu, więc wybór popularnych technologii redukuje halucynacje
Zapisuj zmiany między konwersacjami – praktyka, którą wielu początkujących programistów pomija, a która może uratować projekt
Checkpoint restore to ratunek – funkcja przywracania do checkpointów to jeden z największych wkładów w vibe coding
Zarządzaj konwersacjami świadomie – długie chaty zużywają coraz więcej tokenów, dlatego warto tworzyć nowe konwersacje w naturalnych punktach przerwania
Podejście od projektu – projektuj interfejsy i stany aplikacji przed rozpoczęciem kodowania
Zrozum kod przed akceptacją – doświadczeni użytkownicy potrafią wyłapać błędy szybciej niż AI
MVP najpierw, potem rozszerzanie – unikaj budowania całej aplikacji na raz

Dlaczego systematyczne podejście do vibe coding ma znaczenie

Vibe coding staje się codziennością dla tysięcy deweloperów na całym świecie. Sean jednak zauważa kluczowy problem: większość użytkowników nie ma wystarczającego doświadczenia w programowaniu. W rezultacie powstają luki w zrozumieniu procesu.

Według prezentującego, gdy umiejętność techniczna staje się towarem dostępnym dla wszystkich, najważniejsze pytanie brzmi: co cię wyróżni? Odpowiedź jest prosta – zrozumienie tego, co robisz.

Fundamenty planowania i przygotowania

Wybór dokumentowanych technologii

Sean rozpoczyna od podstawowej zasady: używaj szeroko udokumentowanych stosów technologicznych. Modele językowe jak Claude są trenowane na konkretnych przykładach kodu. Gdy wybierasz popularną technologię, masz już przewagę.

Prawdopodobieństwo jest takie, że ktoś już napotkał problemy, z którymi się zmagasz i udokumentował rozwiązania. To z kolei redukuje prawdopodobieństwo, że AI będzie halucynować rozwiązania, które nie działają.

Sean dodaje istotną obserwację: tradycyjni software developerzy i inżynierowie zawsze będą potrzebni, bo ktoś musi zbudować początkowe rozwiązania, na których AI się później uczy.

Planowanie jako fundament sukcesu

Sean rekomenduje spędzenie 60-70% czasu programowania w fazie planowania. Dlaczego? Modele językowe nie są dobre w architektowaniu złożonych rozwiązań przy jednoczesnym implementowaniu kodu.

Jego czteroetapowy proces planowania:

Definicja stosu technologicznego – wybór technologii i identyfikacja wymagań funkcji
Dokumentacja techniczna – punkty końcowe API, schemat bazy danych, logika komponentów
User experience – kompletne historie użytkownika i zarządzanie stanem aplikacji
Granularne planowanie – szczegółowe zadania implementacyjne

Takie podejście odpowiada prawdziwemu procesowi rozwoju oprogramowania.

Mądre zarządzanie kontekstem

Większość narzędzi AI oferuje symbole @ do dodawania kontekstu. Sean radzi używać tej funkcji świadomie. Modele językowe mają limity kontekstu, dlatego przekazywanie całej bazy kodu z każdym zapytaniem prowadzi do chaosu.

Prezentujący podkreśla: ty najlepiej wiesz, jaki kontekst jest potrzebny. Kontrolowanie poziomu szczegółów w każdym prompcie zapewnia lepsze wyniki.

Zapisywanie zmian między konwersacjami

Sean ostrzega, że praktyka zapisywania zmian powoli zanika wśród początkujących vibe coderów. Jednak zapisywanie zmian jest proste do wykonania i tworzy migawkę kodu.

Jeśli cokolwiek się zepsuje, możesz po prostu wrócić do punktu w czasie, gdy rzeczy faktycznie działały. Oznacza to również, że możesz pracować nad różnymi funkcjami jednocześnie i łączyć je razem, gdy są gotowe.

Dla większości vibe coderów zakończenie konwersacji to naturalny punkt przerwy, w którym warto zapisać swoje zmiany.

Optymalizacja pracy z AI

Pamięć systemowa jako ochrona przed powtarzaniem błędów

Nic nie jest gorsze niż zmaganie się z tym samym problemem dwukrotnie – ostrzega Sean. Dlatego zaleca wykorzystanie pamięci systemowej dostępnej w większości AI IDE.

Każde rozwiązanie znaczącego problemu – od stylowania aplikacji po usuwanie błędów – powinno być zapisane w pamięci. Te wspomnienia utrzymują się między projektami, w rezultacie oszczędzając czas na ponowne wynajdywanie koła.

Proszenie o różne perspektywy

Gdy standardowe podejście nie działa, Sean stosuje prostą taktykę. Prosi system o trzy różne sposoby rozwiązania problemu z wyjaśnieniem, dlaczego każde może być skuteczne lub nie.

Wydaje się, że to zmusza system do rzeczywistego przemyślenia słuszności rozwiązania. Przykład z jego praktyki: problemy z kompresją audio w React Native zostały rozwiązane dopiero po zastosowaniu tej metody.

Workflows oceny i optymalizacji

Sean czerpie inspirację z agentów AI, które używają oceniających i optymalizujących modułów. Można jednak poprosić system o ocenę wyniku względem przewodnika stylu lub sprawdzonych praktyk bezpieczeństwa.

Inteligentny wybór modeli

Sean podkreśla, że różne rodziny modeli lepiej radzą sobie z różnymi zadaniami programistycznymi. Claude 3.7 sonnet thinking jest powszechnie uważany za jeden z najlepszych LLM-ów do kodowania, choć niektóre thinking models Google’a zaczynają przyciągać uwagę.

Jego podejście: używa Claude 3.7 niemal wyłącznie do planowania i architektury, ale gdy napotka na bug, który nie poddaje się rozwiązaniu, przełącza się na inne modele. Można myśleć o tym jak o stawianiu ich przeciwko sobie.

Przykład z rzeczywistego świata: aplikacja Manis łączy różne modele do obsługi różnych zadań w różnej kolejności, aby osiągnąć idealny rezultat.

Konfiguracja narzędzi i środowiska

Project rules jako nieoznaczone bohaterowie

Project rules to jedne z najważniejszych, ale niedocenianych funkcji narzędzi AI coding. Sean zaleca minimum trzy zestawy reguł: frontend, backend i style guide.

Istnieje naprawdę niesamowite narzędzie zwane cursor.directory – to gigantyczne repozytorium różnych reguł, które możesz sprawdzić w zależności od tego, czym faktycznie jest Twój projekt.

Można jednak pójść dalej i stworzyć reguły dla schematów baz danych, zarządzania stanem czy optymalizacji wydajności.

Task planning jako połączenie architektury z kodem

Sean szczególnie ceni narzędzie Claude Taskmaster, które przekształca szeroki projekt w granularną listę zadań. To łączy ogólną architekturę projektu z rzeczywistym kodowaniem linia po linii.

Dlaczego to działa? Narzędzia jak Replit czy v0 robią dokładnie to samo – wykonują szczegółowe planowanie zadań, ale ukrywają to przed użytkownikiem.

Wybór narzędzia dopasowanego do Twoich potrzeb

Sean obserwuje, że każdy ma swoje ulubione IDE i będzie bronić swojego wyboru. Cursor, Windsurf, Augment, Cline, Root code – wszyscy mają swoją ulubioną wersję.

Jego rada: wybierz narzędzie, które ma sens dla Twojego poziomu doświadczenia, kontekstu życia i budżetu. Nie czuj, że musisz używać konkretnego narzędzia, bo widzisz influencera, którego obserwujesz.

Konkretne wskazówki:

Dla początkujących bez dużego budżetu: Windsurf, Cursor – świetna opcja
Dla bardziej doświadczonych z większym budżetem: Root code lub Cline mogą być lepsze ze względu na robustne limity kontekstu

Podejście od projektu

Jedną z największych zmian w procesie Sean’a było projektowanie ekranów przed kodowaniem funkcji. Chcę przemyśleć najpierw, jak użytkownik będzie doświadczać tej aplikacji.

Kluczowe elementy tego podejścia:

Mapowanie user experience – różne stany ekranów i typy interakcji
Obsługa wyjątków – błędy, sukcesy, pierwsze użycie funkcji
Dynamika interfejsu – animacje i przejścia wpływające na doświadczenie

Najlepsze praktyki developerskie

Tryby niestandardowe dla powtarzalnych zadań

Sean wykorzystuje tryby niestandardowe dla różnych przypadków użycia. Tryb usuwania błędów trenowany na idealnej metodzie rozwiązywania bugów. Tryb architect dla brainstormingu szerszych funkcji.

To ogromna korzyść dla przepływu pracy i bardziej przewidywalnego sukcesu.

Aktualna dokumentacja jako konieczność

Sean ostrzega przed używaniem nieaktualnej dokumentacji: Ta przestrzeń zmienia się tak szybko, że bez aktualnych docs będziesz mieć zły czas.

Najbardziej skuteczne metody to bezpośrednie indeksowanie w Cursor/Windsurf, manualne scrapowanie i umieszczanie w folderze projektu, oraz serwery MCP jak context7 dla dokumentacji w czasie rzeczywistym.

Usuwanie błędów z wczesnymi zwrotami i logowaniem

Sean radzi prosić system o dodanie wczesnych zwrotów i szczegółowego console.log podczas usuwania błędów. LLM-y są zaskakująco dobre w rozwiązywaniu problemów, gdy dostaną logi tego, co dzieje się na każdym etapie.

Bonus: można dodać to do trybów niestandardowych dla automatycznego logowania podczas usuwania błędów.

Checkpoint restore jako ratunek

Sean uważa checkpoint restoration za jeden z największych wkładów w uniwersum vibe coding. W chatach Cursor i Windsurf dostępne są opcje przywracania do checkpointów.

To coś w rodzaju wersji dla biednych z zapisu zmian lub przywracania do poprzedniego zapisu zmian po tym, jak coś się zepsuje. Gdy napotykasz problemy lub coś nieoczekiwanie się psuje, możesz łatwo przywrócić kod do stanu sprzed zmiany.

To daje czas na prawdziwe zapisanie zmian i przemyślenie, jak można zmienić prompt, aby uniknąć ponownego wystąpienia problemu.

Bezpieczeństwo i finalizacja

Zrozumienie kodu przed akceptacją

Zaleciłbym wyrobienie sobie nawyku faktycznego czytania kodu generowanego przez AI. Doświadczeni użytkownicy często wyłapują problemy szybciej niż model językowy.

Gdy AI powie „hmm, tak, to dobry punkt, masz rację” – to znak, że zrozumienie kodu może zapobiec problemom.

MVP-first mentality

Sean przyznaje, że to rada, której sam powinien częściej słuchać. Zbuduj najprostszą wersję, która przyniesie wartość, a dopiero potem rozszerzaj.

Przestroga z jego doświadczenia: spędził półtora roku z partnerem biznesowym budując całą aplikację, którą mogliby wypuścić fragmentami, tylko po to, by odkryć, że użytkownicy nie korzystają z 75% funkcji, które zbudowali.

Sean ostrzega przed pokusą budowania wszystkiego naraz. Nie chcesz, żeby Twój projekt zmieniający życie skończył w koszu na śmieci porzuconych projektów, bo stał się zbyt nieporęczny i dziki do obsługi.

Kontrole bezpieczeństwa jako standard

Sean zaleca regularne sprawdzanie krytycznych części kodu pod kątem znanych sprawdzonych praktyk bezpieczeństwa. Nic nie byłoby gorsze niż zbudowanie świetnej aplikacji, zdobycie użytkowników i utrata zaufania z powodu czegoś, czego można było uniknąć.

Jasne określenie stosu technologicznego w project rules

Sean ostrzega przed frustrującą sytuacją, gdy LLM losowo dodaje redundantne biblioteki lub narzędzia do projektu. Problem nasila się, gdy nie rozumiesz dobrze używanej technologii. Możesz zacząć z jednym ORM dla Supabase, a w połowie projektu system zaczyna używać innego.

Najlepszym sposobem na uniknięcie tej sytuacji jest używanie project rules, gdzie jasno określasz, czym jest Twój stos technologiczny i do czego służą te elementy.

Zarządzanie konwersacjami i tokenami

Sean zwraca uwagę na problem, z którym mierzy się wielu użytkowników. Większość AI-powered IDE wysyła całą konwersację jako kontekst do modelu językowego.

Staje się to bolesne szczególnie w narzędziach jak Root code czy Cline: jedną sekundę jesteś na 10,000 tokenów, zadajesz jedno proste pytanie i skaczesz do 25,000 tokenów, potem 46,000 tokenów.

Sean radzi znajdowanie naturalnych punktów przerwania do tworzenia nowych konwersacji. Jeśli nie jest faktycznie konieczne posiadanie całego kontekstu tego, o czym właśnie rozmawiałeś w prompcie, który zaraz zadasz, prawdopodobnie powinieneś po prostu przejść do nowej konwersacji.

Praktyczna checklista dla efektywnego vibe coding

Przed rozpoczęciem projektu

Wybrałem dokumentowany stos technologiczny
Przygotowałem 4-etapowy plan projektu
Skonfigurowałem project rules (frontend, backend, style guide)
Jasno określiłem stos technologiczny w project rules (unikanie redundantnych bibliotek)
Sprawdziłem aktualność dokumentacji używanych narzędzi

Podczas programowania

Używam świadomie kontekstu (@symbols)
Zapisuję zmiany między konwersacjami
Czytam i rozumiem generowany kod przed akceptacją
Proszę o różne perspektywy przy trudnych problemach
Używam checkpoint restore gdy coś się psuje
Tworzę nowe konwersacje w naturalnych punktach przerwania

Optymalizacja przepływu pracy

Zapisuję rozwiązania trudnych problemów w pamięci
Przełączam między modelami AI przy trudnych bugach
Przeprowadzam kontrole bezpieczeństwa przed wdrożeniem
Testuję wersję MVP przed rozszerzaniem

Praktyczne prompty – gotowe do użycia

Sean wspomina kilka konkretnych promptów i technik promptowania, które sprawdzają się w codziennej pracy z AI:

Prompt na różne perspektywy rozwiązania

Kiedy stosować: Gdy standardowe podejście do problemu nie działa lub AI daje powtarzające się, nieudane rozwiązania.

Daj mi trzy różne sposoby rozwiązania tego problemu i wyjaśnij, dlaczego każde podejście może być skuteczne, a dlaczego może nie działać. Dodatkowo oceń każde rozwiązanie w skali 1-10 pod kątem prawdopodobieństwa sukcesu.

Prompt na usuwanie błędów z logowaniem

Kiedy stosować: Gdy usuwasz błędy lub budujesz nowe funkcje i potrzebujesz lepszego wglądu w działanie kodu.

Dodaj wczesne zwroty i szczegółowe console.log do tej funkcji, aby pokazać, co dzieje się na każdym etapie wykonania.

Prompt na zapisywanie zmian

Kiedy stosować: Gdy nie pamiętasz, jak zapisać zmiany między konwersacjami.

Wygeneruj komendę git do zapisania moich aktualnych zmian z odpowiednim opisem.

Kluczowy insight

Mniej kontekstu = lepsze wyniki

Standardowo myślimy: Przekażmy AI jak najwięcej kontekstu – cały kod, wszystkie pliki, kompletną historię konwersacji. Więcej informacji oznacza lepsze rozwiązania.

W praktyce okazuje się, że: Sean odkrył, że kontrolowane dozowanie kontekstu daje znacznie lepsze rezultaty. Jeśli próbowałbym przekazać na przykład całą moją bazę kodu z każdym zapytaniem, wyszłoby to kompletnie spod kontroli i przegapiłby wszystkie szczegóły, których szukam.

Dlaczego to jest istotne: Modele językowe mają maksymalne limity kontekstu i gdy są przeciążone informacjami, tracą fokus na konkretnym problemie. Zamiast wykorzystywać pełną moc obliczeniową na rozwiązanie twojego zadania, marnują ją na przetwarzanie niepotrzebnych danych.

Test na jutro: Następnym razem gdy prosisz AI o pomoc z kodem, zamiast dodawać wszystkie dostępne pliki, wybierz tylko te 2-3 najbardziej związane z problemem i sprawdź, czy odpowiedź jest bardziej precyzyjna i użyteczna.

Podsumowanie praktyczne

Sean kończy słowami: Gdy umiejętność techniczna staje się towarem, zrozumienie tego, co robisz, staje się premium, za które ludzie będą płacić.

Najważniejsze wnioski z jego doświadczenia:

Planowanie przed kodowaniem oszczędza więcej czasu niż wydaje się na pierwszy rzut oka
Zapisywanie i dokumentowanie to safety net, który uratuje projekt
Zrozumienie generowanego kodu to różnica między frustracją a produktywnością
Podejście MVP-first chroni przed utknięciem w nieskończonych projektach

Prezentujący dodaje na zakończenie, że ten materiał był faktycznie wartościowy dla mnie, a jestem pewien, że był też dla was, podkreślając, że nawet doświadczeni praktycy mogą skorzystać z systematyzacji swojej wiedzy.

Metadane artykułu

Główne słowo kluczowe: vibe coding wskazówki

Słowa kluczowe: vibe coding, AI programming, programowanie z AI, developer tools, coding best practices, artificial intelligence, software development, tech productivity, Sean vibe coding, AI coding tips

Zajawka (150 znaków): 21 sprawdzonych wskazówek do vibe coding od eksperta Sean’a. Planowanie, narzędzia, bezpieczeństwo – kompletny przewodnik po programowaniu z AI.

Description (150 znaków): Praktyczne notatki z prezentacji Sean’a o vibe coding. 21 wskazówek, checklisty i gotowe prompty dla efektywnego programowania z AI.

Ten wpis stanowi część kolekcji notatek z ciekawych prezentacji, podcastów i innych treści edukacyjnych. Oryginalne źródło: prezentacja „Supercharge Your Vibe Coding in 21 Easy-to-Apply Tips” autorstwa Sean’a – https://www.youtube.com/watch?v=RmcvVONkrWE

Tag: Tech Productivity

21 wskazówek do vibe coding, które zmienią Twoje podejście do programowania z AI #EN217