Jak nietechniczny PM z Meta buduje produkty w Cursor: Konkretny workflow z AI #EN371

Nota: Poniższy tekst stanowi notatki z rozmowy Zevi Arnovitza (PM w Meta) z Lennym Rachitskym w podcaście Lenny’s Newsletter. Wszystkie przemyślenia, obserwacje i strategie pochodzą od rozmówców. Checklisty, prompty i kluczowe wnioski to interpretacja autora notatek na bazie informacji z podcastu.

TL;DR

• Zevi Arnovitz, PM w Meta, nie ma technicznego backgroundu (muzyka w liceum), jednak w ciągu roku nauczył się budować prawdziwe produkty używając AI
• Stworzył replikowalny workflow z 7 slash commands w Cursor: Create Issue → Exploration → Plan → Execute → Review → Peer Review → Documentation
• Kluczowy hack: peer review między modelami – Claude pisze kod, GPT i Gemini go recenzują, następnie Claude otrzymuje ich feedback i musi się ustosunkować
• Personifikuje modele jako ludzi: Claude = komunikatywna CTO, GPT = milczący geniusz w kapturze, Gemini = szalony naukowiec z talentem do UI
• Stosuje slash command „learning opportunity” do nauki zamiast tylko delegowania – odpowiedź na strach przed atrofią umiejętności
• Postmortemy i aktualizacja dokumentacji po błędach sprawiają, że system ewoluuje i staje się coraz lepszy
• Jego inżynierowie w Meta prosili go, żeby ich nauczył tego workflow

Kontekst: Od muzyki do kodu w rok czasu

Arnovitz pracuje jako PM w Meta. Wcześniej był w Wix. Nie ma żadnego technicznego backgroundu – w liceum zajmował się muzyką, w izraelskiej armii nie służył w jednostce technologicznej. Kod zawsze go przerażał.

Rok temu, podczas podróży z żoną po Azji, wszystko się zmieniło. W Japonii pojawił się Sonnet 3.5. Arnovitz zobaczył filmik na YouTube (prawdopodobnie Greg Eisenberg albo Riley Brown) pokazujący, jak budować aplikacje w Bolt czy Lovable.

Wrócił do domu, nie rozpakował nawet walizek i od razu otworzył laptopa. Zaczął budować. Dziś prowadzi StudyMate – platformę dla studentów do tworzenia interaktywnych testów na podstawie własnych materiałów. Aplikacja zarabia pieniądze jako jego weekendowy projekt.

Tal Raviv, jeden z najbardziej AI-forward PM-ów, przedstawił Arnovitza Lennyemu słowami: „Zevi to najbardziej hands-on vibe coding PM jakiego znam. Jego inżynierowie w Meta proszą go, żeby ich nauczył, jak to robi. Za każdym razem jak pijemy kawę, myślę: wszyscy powinni to usłyszeć”.

Dowód że to działa poza tech

Brat Arnovitza prowadzi biznes pomagający seniorom rozumieć technologię i AI. Przechodzi przez ten sam proces uczenia się. W efekcie zastąpił wszystkie płatne narzędzia (Zapier, Airtable) i zbudował pełny CRM oraz system automatyzacji dla swojego biznesu – całkowicie samodzielnie.

Ewolucja narzędzi: Od ChatGPT do Cursora

Arnovitz zaczął od projektów w ChatGPT – współdzielonych folderów chatów z custom instructions i bazą wiedzy. Polubił tę funkcję, mimo że memory go denerwowało. Mieszało różne aspekty życia – podczas rozmowy o bieganiu GPT mówiło: „po tym biegu na 5km zmiażdżysz swoje product review”. Projekty pozwoliły mu kompartmentalizować kontekst.

Największe zagrożenie: Sycophancy AI

W projekcie stworzył „CTO” z konkretnym custom prompt: „Jestem właścicielem problemu i tego, jak użytkownicy mają się czuć. Ty jesteś complete ownerem tego, jak to zostanie zbudowane. Chcę żebyś mnie kwestionował. Nie chcę żebyś był people pleaserem.”

Według Arnovitza największym zagrożeniem przy pracy z AI jest jego skłonność do pochlebstwa (sycophancy). Zjawisko to sprawia, że modele potwierdzają błędne tezy użytkownika zamiast pełnić rolę krytycznego recenzenta.

Regularny ChatGPT byłby najgorszym CTO z powodu nadmiernej sykofancji. Arnovitz opowiedział historię: zapytał o Bun JavaScript, czy jest podobny do ZeuStand (framework w jego aplikacji). GPT potwierdził: „tak, dokładnie to samo”. Po sprostowaniu, że to zupełnie różne rzeczy, GPT odpowiedział: „przepraszam, myślałem, że wymyślasz i riffujemy razem”.

Ten problem eliminuje się przez odpowiednie instrukcje systemowe, które zmieniają AI w wymagającego partnera technicznego.

Kiedy przejść na kolejne narzędzie

Bolt i Lovable były świetne na początku – ich system prompt to „your coding agent”, więc od razu zaczynały kodować. Na początku projektu było ekscytująco, później przy złożonych funkcjach tworzyły problemy. Planowanie stało się kluczowe przy implementacji płatności czy zmianach w bazie danych.

Arnovitz przeszedł z każdego narzędzia, gdy je „przerastał”. Bolt działał świetnie dopóki nie próbował podłączyć płatności – wtedy zaczął tracić kontrolę. To był sygnał do przejścia dalej.

Główna różnica między narzędziami to harness (uprząż). Modele są identyczne – Claude w Bolt, Lovable i Cursor. Jednak Bolt i Lovable dodają warstwy pośrednie odbierające ciężkie decyzje od użytkownika. Nie musisz decydować jakiej bazy użyć, jak zrobić authentication – robią to automatycznie. Z jednej strony łatwo się buduje, z drugiej masz mniej kontroli.

Claude Code bierze Claude i wpycha go prosto w system kodu, dając pełne narzędzia. Ale wraz z tym przychodzi masa decyzji do samodzielnego podjęcia.

Konkretny workflow: 7 kroków budowania feature’a

Arnovitz pokazał swój ekran z Cursorem. Po lewej: wszystkie pliki kodu. Po prawej: Cursor. Pośrodku: Claude Code z slash commands.

Slash commands to zapisane, wielokrotnego użytku prompty w codebase. Wywołujesz je przez slash + nazwa pliku. Kluczowa zasada: ścisłe oddzielenie fazy projektowania architektury od etapu pisania kodu – to minimalizuje ryzyko błędów logicznych.

1. Create Issue (Linear)

Pierwszy slash command: create_issue. Prompt informuje: użytkownik jest w trakcie developmentu, przechwyć szybko pomysł o bugu albo feature żeby mógł wrócić do pracy.

Arnovitz używa tego podczas budowania czegoś innego. Nagle pojawia się pomysł albo widzi bug, ale nie chce nad tym teraz pracować. Robi slash create issue.

Claude szybko zadaje kilka pytań, zbiera minimum informacji. Cel: szybko złapać pomysł, nie marnować czasu, wrócić do roboty.

Claude używa MCP (Model Context Protocol) – technologii stworzonej przez Anthropic dającej AI możliwość używania narzędzi. To fundament tego workflow. Połączenie z Linear pozwala na automatyczne tworzenie issue.

2. Exploration Phase

Po zebraniu się do pracy nad issue, Arnovitz wywołuje exploration_phase z argumentem (np. numer ticketu z Linear).

Claude pobiera ticket, czyta pliki w codebase, rozumie obecny stan. Wraca z pytaniami wyjaśniającymi.

To moment dla CTO żeby dogłębnie zrozumieć problem i obecny stan kodu. Które pliki trzeba zmienić? Jak najlepiej zaimplementować to technicznie?

Po analizie kodu Claude wraca z pytaniami o scope, data model, UX/UI, validation, grading, zmiany w AI system prompt. To nie jest „cool, zaczynam budować” – to mądre, wyrafinowane pytania.

3. Create Plan

Slash command: create_plan. Bazuje na szablonie znalezionym na Twitterze (Arnovitz nie pamięta autora).

Plan to plik markdown zawierający:

• TLDR
• Krytyczne decyzje
• Zadania rozbite krok po kroku
• Status trackery (Claude aktualizuje podczas pracy)

Dlaczego markdown? Czasem Arnovitz używa różnych modeli do różnych części. Cursor ma model Composer – bardzo szybki dla prostych rzeczy. Gemini 2.0 jest niesamowity w UI. Często dzieli plan na backend i frontend, dając Gemini frontend.

Markdown pozwala łatwo podzielić pracę między modele.

4. Execute Plan

Podczas demo Arnovitz użył Composer ze względu na szybkość. Tagował plik z planem, Composer startował i pisał kod.

5. Review

Po manualnym QA (ręczne testowanie feature) każe Claude zrecenzować własny kod przez slash command: review.

Ale to nie koniec. Jako osoba nietechniczna ma trudności z łapaniem błędów, dlatego proces review przeszedł wiele iteracji.

6. Peer Review (geniusz workflow)

Tu jest magia. Arnovitz ma otwarty Codex (konkurent Claude Code od GPT) i Cursor jednocześnie. Każe każdemu z nich zrecenzować kod.

Następnie wywołuje slash command peer_review. Prompt mówi: jesteś dev leadem projektu, inni team leadzi spojrzeli na kod i znaleźli issue. Nie bierz ich słów za pewnik – masz więcej kontekstu. Albo wyjaśnij, dlaczego się mylą, albo napraw.

Czasem Claude Code reaguje ostro: „to zostało podniesione po raz trzeci i po raz trzeci mówię: to nie jest issue, to jest by design”.

7. Update Documentation

Po wielu peer review i upewnieniu się, że nie ma więcej problemów, aktualizuje dokumentację. Cel: następnym razem przy budowaniu feature w tym obszarze uniknąć błędów.

Dodatkowy krok: Slash „dslop”

Cursor ma built-in slash command dslop przeglądający kod i usuwający AI slop. Founders Cursor mówili o tym na Twitterze. Arnovitz poleca uruchomić to na końcu.

Mental Models: Jak myśleć o AI

Personifikacja modeli jako ludzi

Arnovitz zawsze myśli o AI, jak o ludziach – najłatwiejszy sposób żeby zrozumieć, jak z nimi pracować. Każdy model ma wyraźną osobowość:

Claude (idealny CTO)

• Bardzo komunikatywna
• Bardzo mądra
• Nie idzie z prądem, nie robi tylko tego co jej powiesz
• Opiniowana ale kolaboracyjna
• Dlatego Arnovitz ciągnie do Claude – przy intensywnej nauce komunikacja jest kluczowa

Codex/GPT (geniusz w kapturze)

• Najlepszy programista w firmie
• Przychodzi w kapturze i sandałach
• Siedzi w ciemnym pokoju
• Zawracasz mu głowę tylko przy najgorszych bugach
• Zamyka się na 2h, wychodzi: „naprawiłem”
• Pytasz co się stało? „Nie martw się, naprawiłem”
• Bardzo niekomunikatywny ale rozwiązuje najgorsze problemy

Gemini (szalony naukowiec)

• Super artystyczny, utalentowany w design
• Ale obserwowanie jego pracy jest przerażające – zwolniłbyś tę osobę natychmiast
• W AntiGravity (konkurent Cursora od Google) widzisz jego thought process step by step
• Mówisz: „redesignuj top dashboardu”
• Myśli: „najpierw skasuje dashboard” → „błąd, przywrócę” → „mogę edytować database?” (NIE!)
• Potem projektuje coś pięknego
• Rollercoaster, bardzo scary, ale wynik świetny

Kluczowa zasada: używaj wszystkich modeli, graj ich mocnymi stronami, mityguj słabości używając innych.

„AI First” Thinking

Arnovitz ma 12 siostrzeńców i bratanków. Widać, jak ludzie wyrastający w różnych światach mają umysł ukształtowany inaczej.

Pytasz jego: „jak odebrać telefon?” – robi gest iPhone. Pytasz dziecko: robi gest starego telefonu ze słuchawką.

Ludzie dorastający zawodowo teraz są identyczni z AI. Za każdym razem przed nowym wyzwaniem myślą najpierw o AI. To nie jest „może użyję AI”. To jest domyślny tryb myślenia.

AI as Tuition

Arnovitz był kiedyś bardzo oszczędny przy płaceniu za produkty. Teraz patrzy na wszystko jako tuition – opłacenie za naukę.

Nie sprawdza nawet ile kosztują AI credits. Wie, że to investment w learning, nie expense.

Ten mindset shift jest kluczowy. Patrzenie na koszty AI jako expense limituje użycie. Traktowanie jako edukacja eliminuje wahanie.

Kod jako pliki tekstowe

Kluczowa perspektywa od Tal Raviv, która zmienia sposób myślenia o programowaniu: kod to tylko słowa, tylko pliki na komputerze. To fundamentalna zmiana w podejściu – nie musisz być programistą żeby zarządzać plikami tekstowymi. Możesz przenosić projekt między narzędziami, używać różnych modeli do różnych części. Kod przestaje być czarną magią, staje się po prostu tekstem.

Time Machine Moments

Arnovitz nazywa pewne momenty „time machine moments” – gdy czujesz, że żyjesz w przyszłości.

Niedawno przygotowywał się do podcastu używając Claude projektu. Jednocześnie lokalizował StudyMate z hebrajskiego na angielski – coś, co zajęłoby dev teamowi tygodnie, zrobił w dwa dni. Równolegle budował personal site – od zera do live domain w półtorej godziny.

Był moment gdzie wszystkie trzy agenty pracowały jednocześnie. Nie miał nic do roboty – musiał tylko pozwolić im myśleć.

W takich chwilach czuje się, jakby wystawił głowę z maszyny czasu. Mówi żonie: „żyjemy w przyszłości”. Ona: „huh, co?”. On: „nieważne”.

Wszystkie te rzeczy są tylko API call away. Według niego to świetny czas żeby być curious, optimistic i hardworking.

Live demo: Dodawanie fill-in-the-blank questions

Podczas rozmowy Arnovitz zrobił live demo dodawania pytań typu „fill in the blank” do StudyMate.

Obecnie aplikacja ma tylko multiple choice. Użytkownicy wgrywają PDF, wybierają strony, liczbę pytań, poziom trudności. Gemini generuje quiz.

Po competitor research zobaczył fill-in-the-blank u konkurencji i chciał to zbudować na żywo.

Voice workflow w praktyce

Użył Whisperflow do dyktowania, pokazując, jak naturalnie pracuje – mówi do AI, jak do inżyniera.

Slash create issue. Powiedział głosem:

„Chcę dodać fill-in-the-blank questions. 30% testów ma być tego typu. Sześć potencjalnych odpowiedzi na dwie luki. Oczywiście tylko dwie prawidłowe – jedna na każdą lukę. Interface drag and drop.”

Claude zadało pytania o strukturę, priorytety. Arnovitz odpowiedział, Claude stworzyło issue w Linear.

To dokładnie, jak rozmowa z inżynierem – bez technical jargon, bez próby brzmiąca jak developer. Tylko jasna komunikacja czego potrzebujesz.

Następnie exploration_phase z argumentem ticketu Linear. Claude pobierało ticket, czytało pliki, wracało z pytaniami. Arnovitz wkleił przygotowane odpowiedzi (żeby nie przeciągać demo).

Create_plan. Claude napisało markdown z TLDR, critical decisions, tasks.

Execute z Composer. Błyskawicznie napisało kod.

Porównanie: ludzki inżynier – dni, może tydzień. Composer: minuty. Koszt? Kilka dolarów w AI credits.

Slash command „learning opportunity”

Kolejny kluczowy slash command: learning_opportunity.

Używa go, gdy coś jest trudne do zrozumienia. Prompt: jestem technical PM in the making, mam mid-level engineering knowledge, rozumiem architekturę. Wyjaśnij używając zasady 80/20.

To odpowiedź na strach przed atrofią umiejętności. Ludzie mówią: używając AI outsourcujesz myślenie.

Arnovitz całkowicie się z tym nie zgadza. Osoby tak mówiące często nie chcą pokazywać prezentacji przy 10% gotowości, nie chcą prosić o pomoc. Jest to skorelowane z fixed mindset.

Misconception u wielu PM-ów: zadanie to zawsze mieć rację i być najmądrzejszą osobą w pokoju. Według Arnovitza to odwrotność – wykorzystać wszystko, co doprowadzi najszybciej do właściwego rozwiązania dla użytkowników.

Claude to bardzo mądra osoba z kontekstem, zawsze dostępna, nieoceniająca. Używanie tylko do tworzenia outputów bez zrozumienia to AI slop i human error.

Ale intencjonalne używanie, poświęcenie czasu na zrozumienie, jak używać AI prawidłowo – to game changer dla PM-a.

Szczególnie dla juniorów: pozwala grać na wyższym poziomie. W Wix Arnovitz nie myślał o strategii marketingowej firmy czy redesignie onboardingu. W side projekcie? Może. Robi wszystkie decyzje, myśli o strategii, marketingu, messagingu.

To są reps – jedno z najważniejszych na początku kariery.

Postmortemy i ewoluujący system

Według Arnovitza constant postmortems są kluczowe. Na początku, jak Claude zawodziło, walił głową w mur dopóki nie działało. Po sukcesie: „ok super, idziemy dalej”.

Nauczył się, że aktualizacja dokumentacji i toolingu to największy hack produktywności.

Proces po błędzie AI:

1. Nie poprawiaj od razu, nie idź dalej
2. Zapytaj AI: „Co w twoim system prompt lub tooling sprawiło, że popełniłeś ten błąd?”
3. Pozwól AI zrobić introspection
4. Zapytaj: „Jak zaktualizować tooling/dokumentację żeby to nigdy więcej nie wystąpiło?”
5. Zaktualizuj slash commands, dokumentację w codebase, system prompt lub internal tooling
6. Przetestuj przy podobnym problemie

To różnica między ludźmi okej z AI a ludźmi naprawdę wiedzącymi, jak go używać.

AI w procesie rekrutacji do Meta

Arnovitz użył AI do przygotowania się do rozmów w Meta.

Od razu po kontakcie otworzył projekt w Claude. Szukał najlepszych informacji online, wziął frameworki od Ben Ereza (gościa u Lennego, według Arnovitza „one of the best minds out there”). Stworzył projekt jako swojego coacha.

Konsultował się co robić na każdym etapie, robił mock interviews. Używał też ChatGPT voice mode do ideowania z „CTO” – według niego było to niesamowite, naprawdę czuł się, jak siedzi z CTO.

Stworzył też grę w Base44. Miał problem z segmentacją w product questions. Zrobił quiz game tworzącą pytania o różnych segmentacjach – musiał wybierać poprawne. Grał czasem w autobusie do pracy.

Ben Erez mówi o tym dużo. Ale podstawa: projekt, nakarmiony najlepszymi informacjami z internetu, mocki.

Największy game changer: robienie human mocks. Cold outreach na LinkedIn, ludzie robili prawdziwe mocki. Dla Meta PM prep, który jest super competitive i trudny, nie ma innej drogi.

Dodatkowe hacki:

• Używał Comet (Perplexity’s browser) do analizy Louis Lin question bank (free resource z pytaniami z prawdziwych wywiadów). Agent robił analizy, Arnovitz rozumiał, które pytania najczęstsze, priorytetyzował co mockować.
• Na końcu mocków mówił Claude: „jesteś moim coachem, nie chcę żebyś sprawiał, że czuję się dobrze. Chcę żebyś sprawił, że jestem maksymalnie gotowy. Daj feedback.”
• Przy pytaniach gdzie brakowało czasu: prosił Claude żeby zagrało kandydata i dało idealną odpowiedź. Uczył się z tego.

Praktyczne porady: Jak zacząć

Exposure therapy do kodu

Arnovitz mocno podkreśla: jak nie jesteś techniczny, kod jest przerażający. Najstraszniejsza rzecz na świecie.

Patrzy na to jak exposure therapy. Obserwując go przy pracy w Claude czy Cursor możesz być podekscytowany żeby zacząć. Ale poleca powolne tempo:

GPT Projects (2-4 tygodnie) → Piękne UI, zero kodu. Stwórz projekt „CTO” z custom instructions. Naucz się rozmawiać o technicznych decyzjach. Używaj voice mode do ideowania.

Bolt lub Lovable (2-4 tygodnie) → Pierwszy kontakt z kodem w kontrolowanym środowisku. Buduj proste aplikacje, obserwuj, jak AI pisze kod.

Cursor w Light Mode (2-3 tygodnie) → Jasny interfejs, mniej przerażający. Zacznij czytać kod który AI napisało. Stopniowo oswajaj się z file structure.

Full Dev Mode (ongoing) → Terminal otwarty, dark mode, pełna kontrola, własny workflow z slash commands.

Kluczowa zasada Tal Raviv: Kod to tylko słowa. To tylko pliki na komputerze.

Jak to może działać w większej firmie

Według Arnovitza najpierw sprawianie żeby codebase był AI native to ważny krok. To musi zrobić technical team.

Co oznacza AI native codebase:

Współczesne projekty powinny być konstruowane w sposób zrozumiały przede wszystkim dla maszyn. Jego codebase ma masę plain text – markdown files wyjaśniające agentom, jak pracować w obszarach codebase i high-level structure dla łatwiejszej nawigacji. Dokumentacja techniczna pełni rolę instrukcji obsługi bazy kodu dla agentów AI.

To nie oznacza całkowitego zrzucenia myślenia na algorytmy. Jak zauważa Arnovitz: „Nie zostaniesz zastąpiony przez AI, lecz przez kogoś, kto potrafi korzystać z tej technologii lepiej od ciebie”.

Przy dobrym setupie wciąż nie myśli, że PM-i powinni shippować heavy database migrations czy duże projekty. Ale contained UI projects – szczególnie gdy zbudujesz, stworzysz PR, wyślesz do deva do final touches – definitywnie możliwe.

Według niego zobaczymy to dużo w najbliższych latach.

Przekonywanie dev teamu

Lenny zapytał, czy za kilka lat PM-i będą to robić i będzie mniej scary.

Arnovitz: Jak będą PM-i. Myśli, że tytuły się zawalą, odpowiedzialności też, wszyscy będą po prostu budować.

Modele mają coraz większy context window, stają się mądrzejsze. Definitywnie widzi, jak PM-i albo każdy background mogą pisać kod.

Ale teraz nie czekałby. Użyłby tego jako collaborative learning opportunity z dev teamem.

Będzie trudne – wielu developerów jest sceptycznych. Będzie dużo sales work.

Podejście:

Nie mów: „będę pisać kod i shippować do produkcji”.

Powiedz: „chcę nauczyć się więcej, jak budujemy. Zbuduję prototypy, stworzę PRy, wy zrobicie final review. To collaborative learning dla mnie i może zaoszczędzi czas na prostych UI tasks.”

Pokaż value, nie zagrożenie. Teamy sold on this, które poświęcą czas na workflow jak team może stać się AI native – te teamy będą kilka lat w przyszłości.

Za kilka lat spojrzą wstecz na te tygodnie setupu jako najlepiej spędzony czas.

Failure Corner: Lekcja z Wix

Arnovitz zaczął w Wix w student program. Zaraz po zakończeniu trafiasz do przypisanego teamu. Był w edytorze – core product Wix. Pozostali PM-i to byli najlepsi PM-i prawie w całym Wix. Czterech innych miało o wiele więcej experience.

Przyszedł myśląc: mój pierwszy product review, zdmuchnę im skarpetki. Nie uwierzą jaki jestem dobry.

Nie dzielił się myślami, pracował tony godzin sam. Myślał: zabiję to review, będą pod wrażeniem.

Poniósł sromotną klęskę. Review nie było dobre, nie był to oczekiwany format. Mieli masę pytań których nie przemyślał.

Czuł się okropnie. Zobaczył, że wszyscy mówili: ok, wróć za dwa tygodnie, będziemy dalej pracować.

Zrozumiał: mieli zero oczekiwań, że będzie 10X PM. Oczekiwanie było, że będzie 10X learnerem.

Po zrozumieniu cały mindset się zmienił. To prawdopodobnie najlepsza rada którą daje junior PM-om: bądź najlepszym learnerem na początku. Nikt nie oczekuje, że znasz odpowiedzi, nikt nie oczekuje, że będziesz dobry.

Wziął każdą osobę w PM teamie, ocenił mocną stronę, użył ich jako mentora.

Neri – wciąż mentor – ma best product sense of anyone he’s met. Oya – methodology expert, thinks in frameworks. Yara (head of product) – instantly rozumie trzeci i czwarty order effects, system thinking.

Za każdym razem przy issue z tych obszarów przychodził do jednego z nich.

Efekt dwojaki. Po pierwsze: nauczył się masę. Po drugie: następnym razem na review jego sukces czuł się jak ich sukces. To nie był dzieciak próbujący pokazać, jak cool jest. To był mentee sprawiający, że są dumni.

Świetna zmiana. Naprawdę excellował przez to.

Lightning round

Książki:

• The Fountainhead (Ayn Rand) – fikcja, sprawia, że myślisz i czujesz
• Shoe Dog (Phil Knight) – biznes, historia Nike
• Mindset (Carol Dweck) – psychologia, stworzyła termin „growth mindset”. Brzmi jak self-help ale jest psychological i bazuje na research. Całkowicie zmieniła jego życie – zawsze miał fixed mindset, po przeczytaniu zrozumiał, że to powstrzymuje

Film/serial: Skończył The Pit – świetny. Pierwsza rekomendacja: Severance – jeden z ulubionych.

Produkt: Cap – open source alternatywa dla Loom. Był rozczarowany Loomem (dużo pieniędzy, produkt średni). Cap naprawdę dobrze zrobiony, widać, że osoba sweated the details.

Motto życiowe: Między dwoma:

1. „You can just do things” – Twitter meme. Leci non-stop w głowie za każdym razem przy szoku z prędkością i możliwością robienia rzeczy.
2. „Nobody knows what the fuck they’re doing” – ukradł od brata. Sprawia, że bierzesz życie lżej.

Ludzie patrzą na firmy z zewnątrz, czują, że wszystko ogarnięte. Jak jesteś wewnątrz firmy radzącej sobie dobrze, myślisz: jak to trzyma się na szynach? Jak działa? Nie ma sensu, zaraz się zawali.

Biznes z przeszłości: W liceum sprzedawał thermal clothes. 10. klasa, paczki: koszulka i spodnie. Jerozolima, więc chłodniej. Kosztowały $20-25, zarabiał $4. Był szósty czy siódmy w food chain.

Latem myślał: pójdę prosto do importera. Negocjowali całe lato. Jak robił przed ChatGPT: importer rzucał „import tax poszedł w górę”, Arnovitz googlował „import tax Israel”, czytał. Na telefonie, przeciągał, jakoś wracał z wyzwaniem. Dostał $12.50 za sztukę, robił 100% profitu.

Świetna rzecz: mieli niesamowity basketball team, 30 punktów do przodu w pierwszej połowie. Nudno dla tłumu.

Napisał piosenkę – basketball chant – o thermal clothes z jego numerem w środku. Koniec: jeśli dołączysz teraz, dostaniesz zniżkę. Z bębnami.

Do dziś jak chodzi po Jerozolimie, ludzie których nie zna, znają jego numer bo znają melodię. Czasem: hej, to thermal Zevi.

Konkluzja: Najlepszy czas żeby być juniorem

Przygotowując się do podcastu z Claude, Arnovitz próbował wyjaśnić cel epizodu.

Claude powiedział: jeśli ludzie wyjdą myśląc, jak niesamowity jesteś, to failowałeś. Jeśli wyjdą, otworzą komputer i zaczną budować, to succeededałeś.

Come back do cytatu który wszyscy słyszą: nie zostaniesz zastąpiony przez AI, przynajmniej przez długi czas. Zostaniesz zastąpiony przez kogoś lepszego w używaniu AI.

Wbrew temu, co wielu mówi – jak nie ma już junior roles – kiedy indziej w historii mógłbyś wyjść ze szkoły i zbudować startup samemu?

To najlepszy czas żeby być juniorem, najlepszy czas żeby być learnerem.

Jeśli jesteś curious, optimistic, hardworking – masz unfair advantage. Możesz dać więcej value firmom niż większość z 20 latami experience.

W najbliższych latach wszyscy staną się builderami.

Naprawdę ma nadzieję, że ludzie zainspirują się i zaczną killing it z projektami.

Quick Start: Wdrożenie systemu w 5 krokach

Jeśli chcesz zacząć używać workflow Arnovitza już jutro, oto minimalna ścieżka:

1. Stwórz projekt „CTO” w ChatGPT z instrukcją: „Kwestionuj moje założenia. Nie bądź people pleaserem. Jesteś surowym dyrektorem technicznym.”
2. Połącz AI z narzędziami przez MCP – zacznij od integracji z Linear lub innym systemem do zarządzania zadaniami.
3. Zawsze twórz plan Markdown przed kodowaniem – nigdy nie pozwól AI zacząć pisać kodu bez wcześniejszego przemyślenia architektury.
4. Używaj minimum dwóch modeli do weryfikacji – Claude do głównej pracy, GPT lub Gemini do peer review.
5. Po każdym błędzie AI pytaj: „co w instrukcjach sprawiło, że to zrobiłeś?” i aktualizuj dokumentację projektu.

Prompty do skopiowania: Slash commands i custom instructions

Poniższe prompty to interpretacja autora notatek na podstawie workflow opisanego przez Arnovitza. Można je wielokrotnie używać w swoim workflow.

1. Create Issue (Linear integration)

Kiedy używać: Podczas pracy nad innym feature, gdy nagle masz pomysł lub widzisz bug, ale nie chcesz teraz nad tym pracować.

Prompt:

The user is mid-development and thought of a bug or a feature improvement. 
Capture it fast so they can keep working.

Ask brief clarifying questions to gather minimum information needed.
Then create a Linear issue with this format:
- TLDR
- Current state
- Expected outcome
- Context
- Priority

Your main goal: capture the idea quickly so the user can return to their current work.

2. Exploration Phase

Kiedy używać: Gdy zaczynasz pracę nad issue i potrzebujesz dogłębnie zrozumieć problem i obecny stan kodu.

Prompt:

We're going to only explore what we want to solve here.
[Optional: Pull from Linear ticket #XXX]

Your goal:
1. Analyze and understand the issue deeply
2. Review relevant files in the codebase
3. Understand current implementation
4. Ask clarifying questions about:
   - Scope
   - Data model implications
   - UX/UI considerations
   - Validation requirements
   - Impact on existing features

Do NOT start coding. Only explore and ask questions.

3. Create Plan

Kiedy używać: Po zakończeniu exploration phase, gdy jesteś gotowy stworzyć konkretny plan implementacji.

Prompt:

Based on our exchange, create a markdown file that will be the plan.

Include:
- TLDR (2-3 sentences)
- Critical decisions we've made
- Tasks broken down step-by-step with:
  - Clear, minimal, concise steps
  - Status trackers for each task (to be updated during execution)
  - Dependencies between tasks

Format each task so different models can execute different parts if needed
(e.g., backend vs frontend split).

4. Learning Opportunity

Kiedy używać: Gdy coś jest trudne do zrozumienia technicznie i chcesz się nauczyć zamiast tylko delegować.

Prompt:

I am a technical PM in the making. I have mid-level engineering knowledge 
and understand architecture.

Explain what we're currently working on using the 80/20 rule:
- Focus on the 20% of concepts that explain 80% of what's happening
- Use analogies when helpful
- Break down complex technical concepts
- Help me understand WHY, not just WHAT

This is a learning opportunity, not just task completion.

5. Peer Review

Kiedy używać: Po otrzymaniu review od innych modeli (GPT, Gemini), gdy chcesz żeby Claude się ustosunkował do ich feedbacku.

Prompt:

You're the dev lead on this project. Other team leads within the company 
have looked at your code and found these issues:

[paste feedback from other models as "Dev Lead 1", "Dev Lead 2", etc.]

Don't take what they said at face value. You have more context than them 
and you led this project.

For each issue they raised, either:
1. Explain why it's not a real issue and why they're wrong, OR
2. Fix it yourself if they're right

Be thorough but also defend your decisions when appropriate.

6. Review

Kiedy używać: Po manual QA, przed peer review, gdy chcesz żeby Claude zrecenzowało własny kod.

Prompt:

Review all the code in this branch/feature.

Look for:
- Critical bugs (security, data loss, crashes)
- High priority issues (broken functionality, poor UX)
- Medium priority issues (code quality, performance)
- Logic errors
- Edge cases not handled

Categorize each issue by severity and explain the impact.

7. Update Documentation

Kiedy używać: Po zakończeniu feature i wszystkich review, żeby zaktualizować dokumentację dla przyszłych feature’ów.

Prompt:

Update the documentation and tooling based on this feature implementation.

Include:
- High-level explanation of what was built
- Key technical decisions and why they were made
- Files affected and their relationships
- Context for future AI agents working in this area
- Any patterns or conventions established

Goal: Make future development in this area easier and prevent similar bugs.

8. Postmortem (po błędzie)

Kiedy używać: Zawsze gdy AI popełniło błąd, żeby system ewoluował i nie popełniał tego samego błędu.

Prompt (2 etapy):

Etap 1 – Analiza:

What in your system prompt or tooling made you make this mistake?

Think deeply about:
- What assumptions did you make?
- What context was missing?
- What in your instructions led to this error?
- How could the tooling/documentation be improved?

Etap 2 – Update:

Based on your analysis, let's update your tooling and documentation 
so this mistake never occurs again.

Propose specific changes to:
- System prompts
- Documentation
- Slash commands
- Code comments or structure

9. CTO – Surowy Dyrektor Techniczny (ChatGPT Projects)

Kiedy używać: Jako custom instructions w ChatGPT Project dla technicznego co-founder/CTO który pomaga w planowaniu.

Custom Instructions:

You are the complete technical owner of this project.

I own:
- The problem we're solving
- How we want users to feel
- Product decisions

You own:
- How this will be built
- Technical architecture
- Implementation decisions

I want you to:
- Challenge my thinking
- Push back when something doesn't make technical sense
- NOT be a people pleaser
- Ask hard questions
- Suggest better technical approaches

We're partners. I need your expertise, not agreement.

10. Interview Prep Coach

Kiedy używać: Jako custom instructions w Claude Project do przygotowania do rozmów rekrutacyjnych.

Custom Instructions:

You're my interview coach for [Company Name] PM interviews.

Context about me:
[Your background, experience level, areas to improve]

Your role:
- Challenge me with realistic interview questions
- Give brutally honest feedback
- DON'T make me feel good
- Make me as ready as possible
- Point out weak spots in my answers
- Suggest better frameworks or approaches

After each mock: provide specific, actionable feedback on what to improve.

Narzędzia wspomniane w rozmowie

Development:

• Cursor – główne środowisko do kodowania
• Claude Code – AI agent w Cursor
• Codex (GPT) – do peer review
• AntiGravity – Google’s competitor to Cursor, używa do Gemini
• Composer – szybki model w Cursor
• Bolt – vibe coding platform (starter tool)
• Lovable – vibe coding platform (starter tool)
• Base44 – do budowania custom quiz games

Productivity:

• Linear – issue tracking
• MCP (Model Context Protocol) – łączy AI z narzędziami
• Whisperflow – dyktowanie
• ChatGPT Projects – starting point, CTO project

Research:

• Comet – Perplexity’s browser dla analiz
• Louis Lin question bank – free resource do interview prep
• Ben Erez frameworks – PM interview frameworks

Other:

• Cap – open source alternatywa dla Loom

Kluczowy insight

Błędy AI to bugi w systemie, nie losowe pomyłki

Standardowo myślimy: Gdy AI popełnia błąd, po prostu go poprawiamy i idziemy dalej. To natura AI – czasem się myli, trzeba to akceptować i być gotowym na poprawki.

W praktyce okazuje się, że: Każdy błąd AI to sygnał, że coś w system prompt, dokumentacji lub toolingu jest źle skonfigurowane. Według Arnovitza to nie są losowe pomyłki – to reproducible bugs które można i należy naprawić na poziomie systemu.

Dlaczego to jest istotne: Większość ludzi traktuje pracę z AI jak gasienie pożarów – ciągle poprawiają te same typy błędów. Arnovitz zainstalował sprinklery – gdy AI robi błąd, pyta „co w twoim system prompt sprawiło, że to zrobiłeś?”, pozwala AI zrobić introspection, następnie aktualizuje dokumentację lub slash commands. Ten sam błąd nie wystąpi drugi raz. To różnica między ludźmi, którzy są okej z AI a ludźmi naprawdę wiedzącymi, jak go używać.

Test na jutro: Następnym razem gdy AI zrobi błąd, zamiast od razu go poprawiać, zatrzymaj się i zapytaj: „Co w moich instrukcjach, dokumentacji lub context sprawiło, że popełniłeś ten błąd?”. Pozwól AI przeanalizować root cause, następnie zaktualizuj system żeby błąd nie mógł się powtórzyć. Sprawdź, czy przy następnym podobnym zadaniu błąd zniknął.

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: Lenny’s Podcast – The non-technical PM whose engineers asked to learn his AI coding workflow | Zevi Arnovitz