O czym jest ten film
- Planowanie jest kluczowe w budowaniu funkcji i aplikacji z pomocą AI — sukces agentic engineeringu zależy od operatora, który dobrze zaplanował pracę.
- Autor krytykuje typowe użycie „plan mode”: jeden lakoniczny prompt, włączenie trybu planowania, brak lektury planu i od razu budowanie.
- Jego metoda to najpierw wielokrotna rozmowa z agentem — aż model naprawdę rozumie, co jest w głowie autora, łącznie z omówieniem kompromisów.
- Dopiero po tej rozmowie wchodzi w plan mode i każe agentowi zapisać plan jako plik MD w folderze
plan, a potem budować. - Pliki MD służą przede wszystkim samemu autorowi — jako pamięć projektu, gdy pracuje równolegle w wielu kartach i wraca do funkcji po czasie.
- Na żywo planuje aplikację towarzyszącą (mobile companion app) dla swojej platformy Pluto — świadomie nie ma być kopią desktopu/webu.
- Rozmowa z agentem generuje pomysły: „approve z ekranu blokady”, inbox akceptacji, kanban zadań, dzienny briefing, przechwytywanie głosem.
- Kluczowa decyzja: iOS-only (natywny SwiftUI) czy multiplatforma przez Expo — autor wybiera Expo, bo jego klienci biznesowi używają też Androida.
- Omawia realne pułapki wydajności: streaming czatu w React Native wymaga wirtualizacji listy od pierwszego dnia, inaczej „tnie”.
- Efekt: agent sam zapisuje plan/road mapę do pliku MD, bo „zna” nawyki autora z wcześniejszych rozmów — i można go przekazać dowolnemu agentowi (Cursor, Claude Code, Codex).
Redakcyjne tłumaczenie
Planowanie to podstawa
Planowanie to jedna z najważniejszych rzeczy, jakie możesz robić, budując funkcje i aplikacje z pomocą AI. Inżynieria oparta na agentach udaje się tylko wtedy, gdy ty — operator — dobrze zaplanowałeś pracę. Kiedy myślisz o planowaniu, od razu przychodzi ci do głowy „plan mode” i pewnie widziałeś, jak twój ulubiony influencer-builder mówi, że go nie używa.
Rzecz w tym, że mój sposób planowania — który plan mode uwzględnia — przynosi mi ogromne efekty w budowaniu funkcji i aplikacji: czy to praca dla klienta, praca zawodowa, moje własne projekty, czy Pluto. To właśnie pokażę w tym filmie: jak planuję. Po jego obejrzeniu będziesz świetnym planistą, a to pomoże ci budować świetne funkcje.
(Informacja dodatkowa: „plan mode” to tryb w narzędziach typu Cursor czy Claude Code, w którym agent najpierw przedstawia plan działania, zamiast od razu zmieniać kod.)
Jak planuje większość ludzi — i dlaczego to za mało
Tak planuje większość: używa plan mode i wpisuje prompt w stylu „zbuduj mi X”. Włączają tryb planowania, model planuje, a oni nawet tego nie czytają i po prostu budują. Klasyczny przykład: otwieram Cursor, nową kartę i piszę: „Zbuduj mi nową stronę dashboardu z analityką całego mojego użycia”. Przełączają plan mode, wciskają enter — i agent ma tylko tę jedną linijkę kontekstu, tę jedną instrukcję.
Oczywiście, jeśli używasz dobrego modelu jak Opus 48 albo GPT 55, z całym tym myśleniem, wygeneruje ci przyzwoity plan. Ale moim zdaniem to za mało. Model będzie robił za ciebie mnóstwo założeń, a to po prostu słabe doświadczenie produktowe. Powinieneś dokładnie wiedzieć, co chcesz zbudować. A jeśli tego nie wiesz — moja metoda bardzo ci pomoże.
Moja metoda: najpierw rozmowa, dopiero potem plan mode
Mój sposób planowania jest zupełnie inny. Prowadzę z agentem wielokrotną wymianę zdań. Dopiero gdy jestem pewny, że agent rozumie to, co mam w głowie, i wie dokładnie, co chcę zbudować — przechodzę dalej. Omawiam też kompromisy: co, jeśli zrobimy tak, a co, jeśli inaczej? I dopiero po tej długiej dyskusji wchodzimy w plan mode.
A kiedy już jesteśmy w plan mode, nie każę agentowi od razu budować. Każę mu stworzyć plik MD w moim folderze plan. Dopiero potem budujemy.
Wiele osób pyta: po co te pliki MD? Niektórzy mówią, że są bezużyteczne. Otóż te pliki MD są dla mnie. Są po to, żebym pamiętał, co się dzieje. Zwykle pracuję równolegle — jedna karta buduje funkcję, a w kolejnych planuję następne rzeczy. Gdy agent „gotuje”, mogę zagrać w Among Us albo obejrzeć film na YouTube. Ale jeśli chcę działać dalej, w innej karcie planuję. Zazwyczaj mam jedną kartę budującą funkcję i kilka kart planujących naraz.
Przykład z folderu plan
Pokażę mój folder plan. Mam w nim podfoldery: active, apps, desktop, simplify. W apps jest funkcja, nad którą pracuję: chcę, żeby ludzie mogli bardzo szybko konfigurować dowolne CLI na swojej instancji Pluto — jak App Store, po prostu klikasz i pobierasz. To jest wygenerowany plan. Ale to nie jest standardowy plan z plan mode — powstał po mnóstwie wymian zdań, i to nie tylko między mną a agentem, lecz także między mną a jednym z inżynierów z naszego product studio.
O takie plany mi chodzi, bo po pierwsze wiem, co się dzieje i co ma powstać, a po drugie daję agentowi niezbędny kontekst. Zamiast słabych planów, gdzie tylko mówisz, czego chcesz, i wciskasz plan mode — musisz zacząć rozmawiać. W tym wątku budujesz kontekst dla agenta, żeby dokładnie zrozumiał, co chcesz zbudować.
Co budujemy: aplikacja towarzysząca dla Pluto
Zaplanujmy coś razem. Większość z was zna Pluto — to moja agentowa platforma dla firm. Jest tam dedykowana karta czatu, zadania, rutyny, własny e-mail dla agenta, ponad tysiąc konektorów, indeksowanie plików, OCR. Można łączyć się przez iMessage, Telegram, Slack, dać agentowi własną kartę płatniczą (zamówiłem nią ostatnio shawarmę), numer telefonu, podłączyć konta bankowe, a nawet z nim rozmawiać głosem.
Chcę zaplanować aplikację towarzyszącą — mobilny companion app. Nie ma być jeden do jednego z aplikacją desktopową ani webową, bo to po prostu niewykonalne. Piszę więc do agenta: „Chcę zbudować mobilną aplikację towarzyszącą dla Pluto. Nie oczekuję, że będzie miała wszystkie funkcje i będzie identyczna z desktopem czy webem, ale ma być na tyle użyteczna, żeby ludzie mogli z niej korzystać — czatować, dostawać powiadomienia i tym podobne. Chcę, żebyś przeprowadził burzę mózgów, jak mogłaby wyglądać świetna aplikacja towarzysząca, i podzielił się przemyśleniami”.
Robię to nie w plan mode. Prowadzimy rozmowę. Jeśli model zrobi się nerwowy i próbuje od razu budować, każę mu przestać. Na tym etapie chcę tylko rozmawiać i planować.
Pierwsza iteracja pomysłów
Pierwsza iteracja gotowa (jeszcze się streamuje, ale zasadniczo skończona). Model zadaje mi nawet pytania. Przejrzyjmy od góry:
- Mobile to skrzynka agenta i pilot zdalny, a nie kokpit. To trafne — nie próbuj skurczyć całego dashboardu; zadaniem companion appu jest do mnie docierać, dać mi zielone światło dla agenta, pozwolić z nim rozmawiać i utrzymywać moją świadomość tego, co się dzieje.
- Momenty-zabójcy (wyróżniki). To rzeczy, które sprawiają, że aplikacji używa się codziennie, i mapują się wprost na modele danych, które już mam.
- Akceptacja z ekranu blokady — funkcja-bohater. Mam już zapytania o akceptację z karty agenta (kwota, sprzedawca, cel, termin ważności). Push w stylu: „Pluto chce wydać 42 dolary na aplikację OpenAI” — akceptuj albo odrzuć. Świetne.
- Propozycje szkiców akcji (action draft). Kiedy komunikujesz się z agentem Pluto, są trzy opcje: approve (agent po prostu wykonuje zadanie), draft (prosi o akceptację przy rzeczach, które wymagają człowieka w pętli — wysłanie maila, wydanie pieniędzy) oraz trzecia opcja, którą jest wdrożenie subagenta. Agent analizuje zadanie i jeśli jest ciężkie i zablokowałoby głównego agenta, uruchamia subagenta. Ostatecznie jest też block — jeśli próbujesz zrobić coś dziwnego, agent tego nie wykona.
- Statusy zadań: zrobione / zablokowane / wymaga ciebie — świetne dla widoku kanban.
- Dzienny briefing i dostarczanie rutyn. Uwielbiam to.
- Przechwytywanie głosem — voice-first. Szybkie przechwytywanie, czat na telefonie, push-to-talk.
Do MVP (wersja pierwsza) wrzucam więc: parowanie urządzenia, czat, powiadomienia push, skrzynkę akceptacji, kanał aktywności i odpytywanie o status agenta. Fast follows: zadania, rutyny, pliki, widżety na ekranie głównym plus live activity.
(Informacja dodatkowa: modele zwykle przeszacowują czas pracy, bo myślą kategoriami człowieka — „to zajmie dwa tygodnie”. W praktyce robimy to teraz, w dwie–trzy godziny.)
Kluczowa decyzja: iOS-only czy multiplatforma
Model pyta wprost o otwarte decyzje. Najważniejsza: budować companion app na Androida i iOS naraz, czy trzymać się wyłącznie iOS? Ze SwiftUI wszystko wygląda świetnie i czuje się natywnie. Z Expo dopracowanie zajmie dużo czasu — ale muszę zadać sobie pytanie: czy klienci na Androidzie są tego warci?
Część mnie chce zbudować natywną aplikację. Ale są ludzie na Androidzie. Czy moi klienci — firmy i ich pracownicy — mają telefony z Androidem? Tak, mają. Dlatego myślę, że powinniśmy zrobić pełne Expo.
Nie kończę jednak rozmowy — model znów chce przeskoczyć do „idź budować / planować”. Piszę więc dalej: „Jeśli zbudujemy aplikację w Expo, czy możemy sprawić, by wyglądała i działała natywnie, zwłaszcza po stronie iOS? Bardzo lubię SwiftUI, wiem, że jest Expo UI, czyli natywny port. Chcę mieć pewność, że aplikacja wygląda i czuje się natywnie, jest szybka, ma szybkie kliknięcia. Da się to zrobić?”.
Odpowiedź agenta: natywny feel jest dziś realny
Agent odpowiada: natywny feel jest teraz realny, bez owijania w bawełnę. Expo UI ustabilizowało się w Expo SDK; API zmieniono, by odzwierciedlało komponenty Apple. Nigdy nie jesteś odcięty od SwiftUI. Natywne powiadomienia są teraz natywne, live activities są stabilne. Obie platformy na tym zyskują.
Jak zagwarantować szybkie kliknięcia? Dotknięcie wydaje się natychmiastowe, bo stan Convex jest już „ciepły” dzięki subskrypcjom na żywo — dlatego warto używać Convex. Natywne gesty działają natywnie.
Uczciwe zastrzeżenia dla tej konkretnej aplikacji: streaming czatu to jedyna prawdziwa pułapka wydajności. Natywna implementacja przerenderowuje całą listę wiadomości przy każdym tokenie i będzie „tnąć” — to jedyne miejsce, gdzie React Native regularnie się potyka. Rozwiązanie jest znane i nietrudne: batchowanie i wirtualizacja listy. Ale trzeba to zaprojektować od pierwszego dnia, a nie doklejać później — bo w Pluto czat to główna powierzchnia. Warto najpierw zbudować prototyp, żeby zminimalizować ryzyko.
To się nie dzieje samo. Leniwa aplikacja Expo wciąż będzie sprawiać wrażenie web view; natywny feel jest efektem świadomej pracy. I trzeba utrzymywać dwie implementacje dla najbardziej wyrafinowanych elementów. Pełne natywne SwiftUI plus pełne natywne Compose to nadal absolutny złoty standard wierności, ale to dwukrotność pracy i odcięcie od wspólnego kodu TypeScript. Skoro chcesz obie platformy — trzymaj się Expo.
Road mapa i plik MD
Podsumowuję dla modelu, czego chcę: prosta aplikacja towarzysząca, multiplatformowa, szybka. Pozostaje ustalić strukturę i road mapę. Proszę: „Rozumiesz już cały kontekst i to, czego naprawdę chcę. Zbuduj road mapę, jak to zbudujemy, krok po kroku: co pierwsze, co drugie, co trzecie”.
Dla wielu z was może to wyglądać, jakbym spędzał całą wieczność na planowaniu — kiedy w końcu budowanie? Otóż właśnie dlatego, że poświęciłem ten czas na planowanie, gdy AI zbudowało aplikację, wyszła bliska temu, czego chciałem. Jeśli robisz plan raz i od razu budujesz, efekt bywa niczym, co sobie wyobrażałeś. To małe poświęcenie jest bardzo ważne. A w tym czasie mogę planować coś jeszcze.
Model kończy i tworzy plik MD — zwróćcie uwagę, że umieścił go w moim folderze plan, w podfolderze mobile. Nie wiem, czy dodałem to w agents.md. Nie dodałem — agent po prostu wiedział, na podstawie wszystkich rozmów o tej aplikacji, że tak właśnie chcę to mieć. Zbudował road mapę: cel (natywnie działające iOS…), diagram, stack technologiczny, zasady przewodnie i fazy. Najpierw chce udowodnić na prawdziwym urządzeniu trzy najbardziej ryzykowne integracje, zanim zbudujemy na nich funkcje: że działa auth, że działa streaming, że działa push i że czuje się to natywnie. Dopiero potem reszta. Szanuję to.
Ostateczny plan i sedno metody
W tym miejscu normalnie wciskam plan mode — ale agent niemal wiedział, że to właśnie robię. Piszę więc: „Masz cały kontekst i całą road mapę. Zbuduj ostateczny plan, żeby doprowadzić to do końca”. Wchodzimy w plan mode, wciskamy enter. Agent generuje plan, a ja każę mu utworzyć plik markdown w folderze plan, w konkretnym podfolderze — bo może nie zbuduję tego dzisiaj, ale chcę mieć plan pod ręką. Gdy przyjdzie czas, będę dokładnie wiedział, gdzie skończyłem, co chciałem zrobić i co myślałem. Pliki MD są tak samo dla ciebie, jak i dla agenta.
Wdrożone zostają subagenty; używamy Composera 255 — świetnego i bardzo taniego modelu do takich rzeczy. Plan wygenerowany: zbuduj mobilną aplikację towarzyszącą, nowy klient Convex, zakres i założenia. Jest piękny diagram (potrzebujemy go, bo pomaga zrozumieć), pokazane jest nawet, jak mógłby wyglądać streaming czatu, poszczególne fazy — i lista zadań (to-do). Listę zadań lubię przy pierwszym planie, bo pomaga agentowi.
To jest mój sposób planowania. Ten plan możesz dać Claude Code, Codexowi, dowolnemu agentowi. Ma wszystkie szczegóły — jak dokładnie aplikacja ma wyglądać i działać. Kiedy agent to zbuduje, nawet jeśli nie będzie idealnie zgodne z tym, co sobie wyobraziłem, będzie naprawdę bliskie. Zainwestuj trochę czasu w planowanie, w rozmowę i wymianę zdań z agentem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozmawiaj z agentem, zanim włączysz tryb planowania
Na czym polega: Zamiast wrzucać jeden prompt i od razu klikać plan mode, prowadzisz z agentem wielokrotną wymianę zdań, aż naprawdę zrozumie, co masz w głowie. Plan mode to ostatni krok, nie pierwszy.
Jak stosować: Zacznij od otwartego promptu „przeprowadź burzę mózgów i podziel się przemyśleniami”, a nie „zbuduj X”. Reaguj na każdą propozycję, dopytuj, aż intencja jest jasna. Dopiero wtedy każ agentowi zaplanować.
Na co uważać: Model będzie próbował przeskoczyć do budowania — trzeba go jawnie powstrzymywać („stop, jeszcze rozmawiamy”). Nie kończ rozmowy, dopóki masz otwarte pytania.
2.Zapisuj plany jako pliki MD w dedykowanym folderze
Na czym polega: Po ustaleniach agent tworzy plik markdown w folderze plan (z podfolderami tematycznymi), zamiast od razu pisać kod.
Jak stosować: Utwórz strukturę plan/ z podfolderami (active, apps, mobile itd.). Każ agentowi zapisywać tam plan przed budowaniem. Traktuj te pliki jako pamięć projektu, do której wracasz po dniach.
Na co uważać: Plik ma wartość tylko, jeśli powstał po realnej rozmowie — automatyczny plan z jednego promptu będzie równie pusty jak sam prompt. Utrzymuj też porządek w nazewnictwie, żeby odnaleźć, gdzie skończyłeś.
3.Pliki planów są tak samo dla ciebie, jak dla agenta
Na czym polega: MD-ki pełnią podwójną rolę: dają agentowi kontekst, a tobie pozwalają pamiętać zamysł, gdy pracujesz równolegle albo wracasz do funkcji po czasie.
Jak stosować: Pisz plan tak, byś sam za tydzień zrozumiał decyzje i kompromisy. Zapisuj też funkcje, których nie budujesz dziś — żeby mieć gotowy punkt startu na później.
Na co uważać: Nie traktuj planu jako jednorazowej ściągi dla modelu. Jeśli pominiesz uzasadnienia decyzji, stracisz połowę wartości pliku, gdy sam do niego wrócisz.
4.Świadomie omawiaj kompromisy, nie tylko wymagania
Na czym polega: Autor jawnie roztrząsa alternatywy („co, jeśli tak, co, jeśli inaczej”) — np. iOS-only vs multiplatforma — zanim podejmie decyzję.
Jak stosować: Przy każdej większej decyzji poproś agenta o zestawienie za i przeciw oraz o „uczciwe zastrzeżenia”. Podejmij decyzję na podstawie realnych ograniczeń (kim są twoi użytkownicy, ile masz czasu), a nie preferencji estetycznych.
Na co uważać: Łatwo dać się ponieść „ładniejszej” technicznie opcji (tu: natywny SwiftUI). Zakotwicz decyzję w faktach o użytkownikach — klienci na Androidzie przeważyli na rzecz Expo.
5.Wymuszaj „uczciwe zastrzeżenia” i pułapki wydajności z góry
Na czym polega: Agent sam wskazał, że streaming czatu w React Native „tnie”, jeśli wirtualizacji listy nie zaprojektuje się od pierwszego dnia.
Jak stosować: Pytaj wprost: „gdzie to się może wywalić / co jest największym ryzykiem wydajności?”. Ryzykowne elementy zaadresuj w architekturze i prototypie, zanim zbudujesz na nich resztę.
Na co uważać: Takie rzeczy trudno doklejać później. Jeśli krytyczna powierzchnia (tu: czat) ma znaną pułapkę, uczyń ją elementem fazy pierwszej, a nie „fast follow”.
6.Buduj najpierw najbardziej ryzykowne integracje
Na czym polega: Road mapa zaczyna się od udowodnienia na prawdziwym urządzeniu trzech najryzykowniejszych rzeczy: auth, streaming i push — zanim powstaną funkcje na wierzchu.
Jak stosować: Ustaw fazę zero jako „de-risking”: zbuduj cienki prototyp weryfikujący najtrudniejsze integracje. Dopiero po ich potwierdzeniu rozwijaj funkcje.
Na co uważać: Kuszące jest zaczynanie od widocznych, „efektownych” funkcji. Jeśli fundamentalna integracja okaże się niewykonalna później, przepiszesz wszystko powyżej niej.
7.Pracuj równolegle: jedna karta buduje, kilka planuje
Na czym polega: Gdy jeden agent „gotuje” (buduje funkcję), autor w innych kartach planuje kolejne rzeczy, zamiast bezczynnie czekać.
Jak stosować: Trzymaj jedną kartę na aktywne budowanie i kilka na planowanie. Wykorzystuj czas oczekiwania na dłuższe zadania agenta na przygotowanie następnych.
Na co uważać: Równoległość działa tylko, jeśli każdą nitkę porządkujesz plikiem MD — inaczej zgubisz się, do czego wrócić. Nie mnóż kart bez zapisanego kontekstu.
8.Nie ufaj szacunkom czasu podawanym przez model
Na czym polega: Modele przeszacowują czas („dwa tygodnie”), bo myślą kategoriami ludzkiej pracy — w praktyce z agentem to godziny.
Jak stosować: Traktuj estymaty modelu jako względne (co jest trudniejsze od czego), a nie bezwzględne. Planuj zakres na podstawie realnego tempa swojej pracy z agentem.
Na co uważać: Nie odwracaj błędu w drugą stronę — nie zakładaj, że wszystko jest banalne. Elementy oznaczone jako ryzykowne (streaming) faktycznie wymagają uwagi.
9.Inwestycja w planowanie zwraca się jako trafność efektu
Na czym polega: Dłuższe planowanie sprawia, że zbudowana funkcja jest bliska temu, co autor sobie wyobrażał — zamiast być „niczym, czego chciałeś”.
Jak stosować: Potraktuj czas na rozmowę i pisanie planu jako część budowania, a nie stratę. Zmierz sukces tym, jak blisko wynik trafia w zamysł za pierwszym podejściem.
Na co uważać: Planowanie nie daje idealnego wyniku — daje „naprawdę bliski”. Nie oczekuj perfekcji za pierwszym razem; oczekuj drastycznie mniej poprawek.
10.Plan jest przenośny między agentami
Na czym polega: Gotowy plik MD z diagramem i listą zadań można oddać dowolnemu agentowi — Cursor, Claude Code, Codex — bo zawiera cały kontekst, wygląd i działanie.
Jak stosować: Pisz plany niezależnie od narzędzia: cel, stack, zasady, fazy i konkretne to-do. Dołączaj diagram, bo ułatwia zrozumienie zarówno tobie, jak i agentowi.
Na co uważać: Przenośność zależy od kompletności pliku. Jeśli kluczowe decyzje zostały tylko w wątku czatu, a nie w MD, kolejny agent ich nie „odziedziczy”.