TL;DR

Commituj zmiany religijnie – Vibe coding może się rozjechać w sekundę, version control to Twoja jedyna siatka bezpieczeństwa
Memory files to gra w innej lidze – dokumentuj wzorce i błędy, żeby AI nie powtarzał tych samych problemów w kółko
Czytaj wyniki AI jak orchestrator – bezmyślne kopiowanie to droga donikąd, buduj intuicję i zrozumienie kodu
Self-documenting loops ratują dupę – AI często buduje funkcje, ale nie łączy ich ze sobą, dokumentacja wyłapuje te luki
Czasem lepiej zacząć od nowa – duże projekty potrafią się rozjechać, git revert to szybsza opcja niż walka z zepsutym kodem
Three-loop planning przed pierwszą linią kodu – Product Manager + UX Engineer + System Architect = fundament sukcesu

Poniższy tekst to notatki z video Seana, który przez tysiące godzin testował narzędzia do programowania wspomaganego AI – od Lovable przez Cursor po Claude Code. Sean pracuje w startupach, doradza firmom oraz wdraża systemy AI w rzeczywistych biznesach. Wszystkie przedstawione przemyślenia, obserwacje i metody pochodzą z jego doświadczeń praktycznych.

Zasada 1: Commituj zmiany jak od tego zależy Twoje zdrowie psychiczne

Sean podkreśla fundamentalną prawdę: Vibe coding potrafi się rozjechać błyskawicznie. System nagle wykonuje operację, która kompletnie łamie ważną część aplikacji. Co gorsza, czasem nie umie cofnąć zmian poprawnie.

Bez save pointu jesteś kompletnie w kropce.

Rozwiązanie stanowi własny system kontroli wersji. Mimo że brzmi nudno, według Seana to największa dźwignia sukcesu. Zapewnia szczegółowy system checkpointów, do którego zawsze można wrócić.

Praktyczne kroki dla każdej nowej funkcji:

Twórz branch: git checkout -b feature/nazwa-funkcji
Nazywaj systematycznie: Sean stosuje wzorzec feature/ + nazwa funkcji
Generuj opisowe commit messages: pozwól systemowi opisać wykonane zmiany
Wykorzystuj git diff do debugowania: porównuj stany plików gdy błąd powraca

Przykład z jego praktyki: „Implemented comprehensive password validation system” z pełnym opisem zmian na frontend i backend. Następnie push do GitHub, przegląd kodu oraz scalenie do main branch.

Najważniejsza część: możliwość cofnięcia się do wcześniejszych commitów. Sean opisuje scenariusz, gdzie błąd został naprawiony 3 commity temu, jednak pojawił się ponownie. Git diff pozwala porównać stany plików i zobaczyć co działało wcześniej.

Zasada 2: Memory files – Twoja tajna broń przeciwko powtarzającym się błędom

Większość nowoczesnych coding agentów oferuje system memory files. Sean zauważa, że dopiero przy dłuższych projektach widać prawdziwą wartość tej funkcji.

Konkretny przykład z praktyki: W trakcie 5-6 godzinnego projektu budowy aplikacji od pomysłu do działającego rozwiązania, Sean tworzył aplikację wykorzystującą GraphQL do komunikacji frontend-backend. Problem polegał na tym, że za każdym razem przy tworzeniu nowego API endpoint system nie potrafił znaleźć tożsamości zalogowanego użytkownika.

Efekt? Błędne koło. System łamał działającą funkcję, nie potrafił użyć istniejącej funkcji autoryzacji i wszystko się sypało. Co gorsza, próby naprawy prowadziły do fundamentalnej zmiany funkcji, która łamała każdy inny element aplikacji. Sean tracił godziny na debugowanie zamiast budować funkcje, które użytkownicy rzeczywiście zobaczą.

Sedno problemu: System miał gotową funkcję getCurrentUser która działała, ale za każdym razem przy nowym endpoincie próbował ją „naprawić” zamiast po prostu użyć. Zmiana tej funkcji powodowała, że Sean zostawał wylogowany ze wszystkich ekranów i musiał wyczyścić cały system.

Rozwiązanie przez memory file:

Sean dodał do pliku pamięci trzy kluczowe zasady:

Sprawdzaj istniejące queries: weryfikuj czy istnieje już query dla danego zapytania
Waliduj frontend mutations: upewnij się, że frontend mutuje prawidłowo
Referencuj podobne endpointy: zawsze odwołuj się do podobnych endpointów żeby zrozumieć działające wzorce

Moment dodania tego do memory file = koniec problemu na zawsze.

Jak podkreśla Sean: „W momencie gdy dodałem to do pliku pamięci, ten błąd przestał istnieć. Nigdy więcej nie popełnił tego błędu.”

Sean zauważa praktyczny aspekt: „To może zająć 3-4 minuty aktualizacji pliku, ale oszczędza 3-4 godziny debugowania.” Zamiast walczyć z problemami autentykacji, mógł się skupić na budowaniu funkcji dla użytkowników.

Zasada 3: Czytaj wyniki AI jak orchestrator, nie jak zombie

Vibe coding nie równa się bezmyślności. Sean kładzie nacisk na myślenie jak orchestrator. Wiedza o tym co budujesz stanowi klucz do osiągnięcia poziomu 99% innych programistów AI.

Vibe coding to kolejna wielka ewolucja w nauce. Jeśli zwracasz uwagę, nie tylko unikasz jednorazowych problemów, ale również budujesz wiedzę o tym jak rzeczywiście tworzyć solidne rozwiązania.

Przy tworzeniu systemu bezpieczeństwa haseł większość ludzi zobaczy wyniki wszystkich zmian i przejdzie dalej. Sean radzi budować nawyk czytania rzeczywistych rezultatów. Zajmuje kilka minut więcej, jednak budujesz prawdziwe zrozumienie.

Praktyczne korzyści:

Budujesz prawdziwe zrozumienie zamiast copy-paste workflow
Łapiesz niechciane zmiany zanim zepsują działające funkcje
Uczysz się podczas kodowania – każdy wynik to lekcja
Rozwijasz intuicję kiedy AI próbuje „naprawić” działający kod

Studium przypadku: Sean odkrył przez czytanie wyników AI, że system za każdym razem modyfikował funkcję getCurrentUser i przez to sypała się cała autentykacja. Bez analizy chain of thought nigdy by tego nie zauważył.

Sean wykorzystuje Claude Code z Cursor żeby tłumaczyć skomplikowane części „jak dla piątoklasisty”. Przykład: wyjaśnienie jak działa entropy-based scoring dla haseł. Claude Code planning mode to dodatkowy poziom – pozwala łapać problemy przed implementacją.

Długoterminowa korzyść: To nie tylko pomaga w danym momencie, ale pozwala budować systemy awaryjne, automacje oraz procedury do stałego doskonalenia. Dlatego też następna zasada to self-documenting loops.

Zasada 4: Self-documenting loops – dokumentuj lub giń

Najgorsze co możesz zrobić to zbudować coś, czego nie rozumiesz. Sean ostrzega: narzędzia AI często budują funkcje, ale nie podpinają całej zaawansowanej funkcjonalności.

Czasem tworzą coś zaawansowanego, jednak biorą skróty w implementacji.

Studium przypadku z vector database:

Sean budował skomplikowaną funkcję z wieloma vector databases przechowującymi dane użytkowników. W tym przypadku była to aplikacja z przepisami – system miał przechowywać informacje o przepisach w vector database, żeby gdy użytkownik pyta o przepis który przygotował lub chce przygotować, mógł wykorzystywać tę bazę do odpowiedzi.

Przed requestem do OpenAI system miał pobierać odpowiednie vectory i wysyłać je w odpowiedzi.

Co się stało? System zbudował wszystkie endpointy. Funkcjonalność była dostępna. Mógł embedować oraz pobierać z vector database. Ale nigdy nie podpiął części, która miała wstrzykiwać te dane do requestu OpenAI.

Sean odkrył to dopiero po poproszeniu systemu o dokumentację wszystkich plików użytych w funkcji. System odpowiedział: „Tak, zbudowaliśmy te inne rzeczy też, ale nie są jeszcze podpięte. Chcesz żebym to teraz podpiął?”

Jak implementować dokumentację:

Podstawowy tryb (Cursor): Komenda „przeanalizuj [nazwa feature] i udokumentuj jak działa” z referencją do przykładowego poziomu szczegółów.

Zaawansowany tryb (Claude Code): hooks lub customized agent, który automatycznie dokumentuje funkcje po zbudowaniu nowej funkcji.

Dokumentacja powinna zawierać: pliki utworzone/zmodyfikowane, kluczowe możliwości, punkty integracji oraz to co nie zostało jeszcze podpięte.

Kluczowa obserwacja Seana: Te narzędzia potrafią budować tak szybko, że wyprzedzają naszą zdolność zrozumienia i zapamiętania tego co zostało zbudowane. Jeśli byłbyś programistą tworzącym wszystkie te pliki i funkcje ręcznie, pamiętałbyś gdzie leżą różne części kodu, do czego się podłączają – bo to robiłeś. Bez tego potrzebujemy systemów zapasowych żeby zachować wiedzę o tym co budujemy, dlaczego i jak to działa.

Zasada 5: Kiedy zacząć od nowa zamiast walczyć z zepsutym kodem

Sean nazywa modele „maszynami do produkowania śmieci” gdy kontekst się rozrasta. Przy dużych projektach narzędzia często schodzą z szyn. Czasem łatwiej zacząć od nowa.

Tu wraca znaczenie commitowania kodu – można wrócić do wcześniejszego commita.

Praktyczne komendy git:

git log --oneline – pokazuje historię commitów z ID. Widzisz gdzie jesteś (HEAD) oraz gdzie było „zanim się zepsuło”
git checkout [commit-id] – przenosi do punktu gdy wszystko działało. Wszystko co było później – znika

Sean radzi: nie marnuj czasu, tokenów oraz zdrowia psychicznego. Cofnij się do stanu gdy rzeczy nie były kompletnie zepsute.

Zasada 6: Three-loop planning cycle – planuj zanim napiszesz pierwszą linię kodu

Absolutnie konieczne według Seana, szczególnie dla osób bez doświadczenia w programowaniu.

Większość programowania AI zaczyna się od prostego pomysłu podczas dnia. „Mógłbym zbudować aplikację na to. Inni zapłaciliby jeśli ja bym zapłacił.”

To świetny początek, jednak to za mało kontekstu żeby rzeczywiście coś zbudować.

Trzy pętle planowania:

1. Product Manager prompt Przekształca surowy pomysł w strukturalny plan. Kim są personas użytkowników? Jak będą używać aplikacji? Co idzie do MVP, a co do kolejnych wersji? Buduje executive summary – prezentację tego czym rzeczywiście jest aplikacja oraz jaki główny problem rozwiązuje.

Kluczowy element: dla każdej funkcji tworzy konkretne user stories w formacie „As a [blank], I want to [blank] so that I can [blank]”. Definiuje kryteria akceptacji – jak wiemy kiedy funkcja jest ukończona i działa. Mapuje zależności między funkcjami oraz główne punkty interakcji dla użytkownika.

Sean podaje przykład aplikacji, która może zrobić zdjęcie menu restauracyjnego i przekształcić je w przepis do przygotowania w domu. Z takiego pomysłu buduje szczegółowe wymagania funkcjonalne i niefunkcjonalne.

2. UX/UI Engineer prompt
Kodyfikuje jak zbudować piękne doświadczenie użytkownika. Tworzy paletę kolorów. Dla każdej funkcji z aplikacji projektuje feature z góry – co musi być tam bazując na user journeys.

Szczegółowy poziom: definiuje zagadnienia UX, ograniczenia techniczne (np. maksymalny rozmiar uploadu zdjęcia), główne zasady designu. Dla każdego ekranu określa co musi być obecne bazując na ścieżkach użytkownika zdefiniowanych w etapie Product Manager.

3. System Architect prompt Bierze wymagania produktowe oraz user workflows. Buduje kompletny dokument architektury technicznej. Przegląd systemu, zależności, architektura komponentów, APIs, baza danych, bezpieczeństwo, infrastruktura, monitoring wydajności, obsługa błędów.

Efekt końcowy:

Zero dwuznaczności. Backend engineer agent wie dokładnie co budować – każdą funkcję, modele danych, endpointy, jak działają interakcje, co zwracać. Frontend engineer nie będzie zgadywał funkcji – będzie czerpał je z wyników UX Engineer z wiedzą o backend endpoints.

Te trzy etapy to konieczność według Seana. Bez względu na to czy używasz Lovable czy przyszłą iterację Claude Code 99.

Dodatkowy kontekst: Sean ma na swoim kanale cały film o „pięciu niezbędnych promptach dla każdego programisty AI” – te trzy planning prompts to pierwsze z tej listy. Używa ich jako Claude Code agents, ale działają równie dobrze jako zwykłe prompty w dowolnym systemie.

Wyzwanie od Seana

Te zasady oddzielają majsterkowiczów od ludzi, którzy potrafią budować rzeczywiste rozwiązania z tymi narzędziami. Celem jest dostanie się do top 1% ludzi budujących naprawdę wartościowe rozwiązania dla konkretnych, prawdziwych problemów.

Wyzwanie: wybierz 1-3 z tych zasad oraz zaimplementuj je w swoim workflow w tym tygodniu. Zobacz jak wpływają na Twój proces.

Prawda jest taka: programowanie AI bez procesu to dobry sposób na tworzenie zepsutego kodu, o którym marzyłeś żeby działało. Opanuj te fundamenty teraz, żeby być w tej elitarnej grupie.

Checklist profesjonalnego programisty AI

Przed rozpoczęciem projektu:

Przeprowadź three-loop planning (Product Manager → UX Engineer → System Architect)
Zdefiniuj personas użytkowników oraz główny problem do rozwiązania
Stwórz dokument architektury technicznej
Przygotuj paletę kolorów oraz zagadnienia UX

Przed każdą nową funkcją:

Stwórz nowy branch: git checkout -b feature/nazwa
Zaktualizuj memory file z wzorcami dla tej funkcji
Sprawdź czy podobne funkcje już istnieją w projekcie

Po ukończeniu funkcji:

Wygeneruj opisowy commit message
Udokumentuj jak funkcja działa (pliki, integracje, możliwości)
Sprawdź czy wszystkie komponenty są rzeczywiście podpięte
Push → Przegląd → Scalenie

Gdy coś się zepsuło:

Sprawdź git log --oneline żeby znaleźć działający stan
Użyj git checkout [commit-id] zamiast walczyć z zepsutym kodem
Zaktualizuj memory file żeby uniknąć tego problemu w przyszłości

Podczas pracy z AI:

Czytaj wyniki AI zamiast bezmyślnie kopiować
Wykorzystuj planning mode żeby łapać błędy przed implementacją
Pytaj o wyjaśnienia skomplikowanych części „jak dla piątoklasisty”
Sprawdzaj czy AI nie próbuje modyfikować działających funkcji

Kluczowe spostrzeżenie

Paradoks szybkości AI

Standardowo myślimy: Szybkość AI to zawsze zaleta – im szybciej buduje kod, tym lepiej.

W praktyce okazuje się, że: AI może budować tak szybko, że wyprzedza naszą zdolność zrozumienia i zapamiętania tego co zostało stworzone. Jak zauważa Sean: „Te narzędzia potrafią budować tak szybko, że wyprzedzają naszą zdolność zrozumienia oraz zapamiętania tego co zostało zbudowane.”

Dlaczego to jest istotne: Ta szybkość bez kontroli prowadzi do aplikacji, które wyglądają na działające, ale nikt nie wie jak naprawdę funkcjonują. Tracisz kontrolę nad własnym projektem.

Test na jutro: Następnym razem gdy AI skończy budować funkcję, zamiast od razu przechodzić do następnego zadania, poświęć 5 minut na przeczytanie co właściwie zostało zbudowane oraz sprawdź czy rozumiesz połączenia między komponentami.

Ten wpis jest częścią kolekcji notatek z ciekawych podcastów, webinarów oraz innych treści, które uznajemy za wartościowe. Wszystkie przedstawione przemyślenia oraz obserwacje pochodzą od Seana z jego video o zasadach AI coding.

Tag: Memory Files Coding

6 zasad AI coding, które oddzielają profesjonalistów od amatorów #EN250