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
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.