O czym jest ten film
- Autor, który nie potrafi programować, zbudował własną mikroaplikację do generowania miniatur (ThumbForge) wyłącznie za pomocą Claude Code i Codeksa.
- Materiał dotyczy budowania małych narzędzi na własne potrzeby, a nie wielkich SaaS-ów „w weekend”.
- Pomysł na aplikację wyrósł z istniejącego skilla w Claude Code — inspiracji warto szukać w narzędziach, których już się używa.
- Kluczem jest planowanie przed kodowaniem: tryb planowania, odwrócone „grillowanie” pytaniami i spisanie dokumentu wymagań (PRD).
- Duży plan tnie się na małe „slice’y” — kawałki pracy zakończone testami jednostkowymi i commitem.
- Testowanie z perspektywy użytkownika autor zleca agentowi przez „computer use” — AI samo klika po aplikacji.
- Dwa agenty (Claude i Codex) wzajemnie audytują swoją pracę, wyłapując błędy, których pojedynczy model nie zauważa.
- Nocne pętle (komenda
goal) pozwalają agentowi pracować samodzielnie przez kilka godzin, gdy autor śpi. - Cała metoda opiera się na jednej osi: potrzeba → plan → egzekucja → audyt → noc.
- To nie historia spektakularnego sukcesu, tylko realnego, drobnego progresu — aplikacja nadal jest w budowie i nie zarabia.
Redakcyjne tłumaczenie
Wprowadzenie — skąd wziął się ThumbForge
Jeszcze dobre dwa lata temu myślałem, że Java i JavaScript to jedno i to samo. Spoiler: nie jest. A dziś stworzyłem własną mikroaplikację bez napisania ani jednej linijki kodu. ThumbForge to aplikacja do generowania miniatur, którą rozwijam od około półtora miesiąca i która doczekała się już pierwszych beta-testerów. Całość ogarniam za pomocą Claude Code i Codeksa i przyznam szczerze, że czuję się trochę tak, jakbym grał w symulator startupu — tyle że w prawdziwym życiu.
(Informacja dodatkowa: „vibe coding” to budowanie oprogramowania przez opisywanie w języku naturalnym, co ma powstać, i zdanie się na model AI, który generuje kod — bez samodzielnego programowania. Claude Code i Codex to narzędzia-agenci od Anthropic i OpenAI działające w terminalu.)
Za chwilę podzielę się z tobą sześcioma bardzo praktycznymi lekcjami z budowania tej mikroaplikacji — takimi, które od razu wdrożysz i przetestujesz u siebie. Chcę jednak wyraźnie zaznaczyć: ten film jest o vibe codowaniu małych aplikacji na własne potrzeby, a nie o wielkich SaaS-ach powstających w dzień czy tydzień.
Wiesz, co się dzieje z większością projektów spod znaku „zbudowałem apkę w weekend”? Umierają w poniedziałek. ThumbForge nie umarł.
Lekcja 1: Pomysł znajdziesz w narzędziach, których już używasz
Zanim ThumbForge stało się działającą aplikacją, było skillem w Claude Code. Tak — miałem skilla do generowania miniatur, pokazywałem go nawet w jednym z poprzednich odcinków. Problem w tym, że generowanie było w nim niewygodne, a do tego korzystałem z Higgsfield przez MCP i CLI, więc pod koniec miesiąca zwyczajnie brakowało mi kredytów.
(Informacja dodatkowa: „skill” w Claude Code to zapisany zestaw instrukcji i procedur, który rozszerza możliwości agenta. MCP i CLI to sposoby łączenia narzędzi zewnętrznych z modelem.)
Pewnego dnia stwierdziłem, że fajnie byłoby zrobić coś z działającym interfejsem — coś, nad czym będę miał większą kontrolę i co wyjdzie mnie kilkukrotnie taniej, bo podepnę własny klucz API. Podczas jednego z sobotnich streamów przedstawiłem ten pomysł widzom i tam zaczęła się cała przygoda. Siedzieliśmy dobre trzy, może cztery godziny i zbudowaliśmy pełnoprawny, działający prototyp ThumbForge. Pamiętam moment euforii, gdy pod koniec streama wygenerowaliśmy pierwszą miniaturę. Kliknąłem „wygeneruj” — nie było idealne, ale działało.
Stąd pierwsza lekcja: jeśli nie masz pomysłu, jaką aplikację zbudować, rzuć okiem na skille i narzędzia, z których już korzystasz. Być może znajdziesz tam coś, co cię zainspiruje. To już nie pierwszy raz, gdy zamieniłem skilla w Claude Code w małą mikroaplikację na własne potrzeby. ThumbForge narodziło się z realnej potrzeby, a nie z ambicji zbudowania czegoś wielkiego.
Lekcja 2: Nie zaczynaj od „zbuduj mi aplikację” — najpierw planuj
Moim zdaniem najgorsze, co możesz zrobić, to otworzyć Claude Code, Codeksa czy dowolne inne narzędzie AI i powiedzieć: „Zbuduj mi aplikację X” — zwłaszcza gdy, tak jak ja, nie potrafisz kodować. Zbudowanie działającego prototypu zajęło mi kilka godzin, a zajęłoby kilkanaście, gdyby nie podpowiedzi społeczności na czacie podczas transmisji. Wielki shoutout dla Bartka Marczuka, który podesłał mi na streamie paczkę skilli Mata Pococka — korzystam z niej po dziś dzień i bardzo ci ją polecam.
Zanim agent wygenerował pierwszą linijkę kodu, spędziłem około półtorej godziny na samym planowaniu i przemyśleniu rzeczy z Claude Code. To bardzo ważny krok, który większość osób — zwłaszcza nietechnicznych — niestety pomija. Jeśli zadanie jest złożone, ma wiele etapów, to zanim przejdę do właściwej pracy, uruchamiam tryb planowania, czyli tak zwany plan mode.
W przypadku ThumbForge podeszliśmy do tego nieco inaczej. Na początku odpaliliśmy skill „Grill Me” z paczki Mata, który odwraca role: to AI zaczyna cię przepytywać. Dostajesz jedno pytanie naraz, Claude czeka na twoją odpowiedź, zanim pójdzie dalej, i podaje swoje rekomendacje — co często było nieocenione. Czy klucz API ma być w lokalnej zmiennej środowiskowej, a może szyfrowany w pliku? Co się dzieje, gdy użytkownik wgra plik większy niż 10 MB? Sam bym sobie tych pytań nie zadał, bo nie znam się na programowaniu.
Gdy etap grillowania mam już za sobą, przechodzę do tworzenia dokumentacji projektu. Tu ponownie polecam paczkę Mata, a konkretnie skill „to-PRD”.
(Informacja dodatkowa: PRD (Product Requirements Document) to dokument wymagań produktowych — spisuje, co aplikacja ma robić, dla kogo i jak. Autor nagrał osobny film tłumaczący pojęcia takie jak PRD, MCP czy CLI.)
Zwykle proszę Claude’a, żeby zapisał PRD w formacie Markdown, w wybranym miejscu — na przykład w folderze „Pobrane”. Następnie komendą clear czyszczę kontekst i przechodzę do kolejnego kroku. Spoiler: tym krokiem wciąż nie jest kodowanie.
Poświęcam dużo czasu na planowanie, bo gdybym na streamie po prostu napisał „zrób mi apkę do miniatur”, dostałbym coś, co nie działa — albo co działa, ale rozsypuje się po dodaniu kolejnej funkcjonalności. ThumbForge rozwijam od półtora miesiąca, dostało masę aktualizacji, testują je różni ludzie — i do tej pory, odpukać, się nie posypało.
Lekcja 3: Potnij plan na małe kawałki (slice’y) z testami
Mamy gotowe PRD, ale problem w tym, że to wciąż duży, przerażający plik. Zanim agent zabierze się za kodowanie, chcemy zamienić plan w coś, co da się ogarnąć w małych, pojedynczych kawałkach. I tu znów wracamy do paczki skilli od Mata — tym razem do skilla „to-issues”.
Wracam do okienka ze świeżym kontekstem, przeciągam PRD i uruchamiam skill. Działa on tak, że tnie duży plan na małe slice’y — konkretne kawałki pracy. Dlaczego tak robię? Bo o wiele łatwiej przetestować pojedynczy kawałek osobno niż cały projekt naraz. Każdy slice kończy się testami jednostkowymi, które projektuje Claude — sam takich rzeczy nie ogarniam.
(Informacja dodatkowa: testy jednostkowe to automatyczne sprawdzenia weryfikujące, czy pojedynczy fragment kodu działa poprawnie. „Commit” to zapis stanu projektu w systemie kontroli wersji, do którego można wrócić.)
Zasada jest prosta. Testy świecą się na zielono — robimy commit i przechodzimy do kolejnego slice’a. Testy świecą się na czerwono — cofamy się o jeden krok, a nie o całość. To moje absolutne koło ratunkowe jako nieprogramisty. Pomyśl o tym tak: gdyby każdy błąd cofał mnie do zera, tego filmu raczej by nie było — projekt umarłby w pierwszym tygodniu, a ja rzuciłbym klawiaturą o ścianę.
Lekcja 4: Testuj aplikację oczami użytkownika — zleć to agentowi
Slice’y gotowe, testy jednostkowe też. Ale kto sprawdza, czy aplikacja działa z perspektywy użytkownika? Pojawia się pytanie: „Robert, skoro nie umiesz programować, to skąd w ogóle wiesz, że twoja aplikacja działa tak, jak powinna?”. Świetne pytanie.
Claude Code projektuje testy jednostkowe, które sprawdzają, czy wygenerowany kod działa — ale te nie weryfikują, czy apka jako całość ma sens dla użytkownika, czy kliknięcia, ekrany i przepływy poprawnie ze sobą współgrają. Do tego potrzebowałem czegoś innego. Mocno zainspirowałem się wpisem Borisa Czernego, twórcy Claude Code — napisał on mniej więcej tak, że najlepiej takie testowanie aplikacji zlecić samemu Claude’owi.
(Informacja dodatkowa: „computer use” to funkcja pozwalająca modelowi AI samodzielnie sterować przeglądarką i komputerem — klikać, przewijać, wypełniać pola.)
Korzystam z computer use, dzięki któremu Claude czy Codex mogą sterować moją przeglądarką i komputerem. Wysyłam agenta, żeby przeklikał za mnie wszystkie najważniejsze rzeczy w aplikacji. Agenci wołają mnie do działania tylko w dwóch przypadkach: gdy coś wymaga ludzkiej ingerencji (na przykład precyzyjnego zaznaczenia czegoś na ekranie — tu agent nie jest dość dokładny) oraz gdy coś jest płatne (na przykład płatne wygenerowanie miniatury — wtedy agent pyta mnie wcześniej o zgodę).
Zwykle wygląda to tak, że Claude Code tworzy checklistę rzeczy do sprawdzenia, a Codex łączy się z aplikacją i klika — bo computer use lepiej mi działa w Codeksie. W rezultacie aplikacja sama się testuje, kiedy ja robię kawę. To jest ten moment, w którym vibe coding wchodzi za mocno — a nie jakieś „zbudowałem aplikację w 32 minuty”.
Lekcja 5: Dwa agenty wzajemnie audytujące swoją pracę
Skoro agenci pracują przy kodowaniu i testowaniu, rodzi się kluczowe pytanie: co się stanie, gdy jeden agent popełni błąd, którego sam nie zauważy? Kiedyś usłyszałem, że autor kodu jest jego najgorszym recenzentem — i okazuje się, że dotyczy to również AI. To jak z moim newsletterem: zdarza mi się nie zauważyć własnych literówek. Dlatego dobrze, żeby na wygenerowany kod czy plan spojrzał ktoś drugi. U mnie tym drugim jest kolejny cyfrowy agent — o nieco innym charakterze.
Claude to, moim zdaniem, sprytna i cwana bestia, idealna do planowania. Codex to model bardziej pragmatyczny, który trzyma resztę w ryzach i pilnuje porządku. Dlatego najczęściej używam Opusa do przemyśleń i tworzenia planów, które potem przesyłam do oceny Codeksowi. Bywa i tak, że zlecam wykonanie planu Codeksowi, a jego pracę sprawdza Claude.
(Informacja dodatkowa: Opus to jeden z modeli Claude od Anthropic. „Codex for CC” to darmowa wtyczka OpenAI dostępna na GitHubie, pozwalająca zlecać Codeksowi audyt w ramach bieżącej sesji Claude Code.)
Polecam wtyczkę Codex for CC autorstwa OpenAI — dzięki niej Claude może przesłać gotowy plan do audytu Codeksa w bieżącej sesji, bez przeskakiwania między narzędziami. Na koniec pracy, gdy wdrożymy coś nowego, proszę agenta, który generował kod, o przygotowanie notatki dla drugiego agenta oraz o wygenerowanie planu audytu, żeby ten drugi mógł sprawdzić jego pracę.
Ciekawostka: w repozytorium ThumbForge na GitHubie mam ponad 35 commitów, które są bezpośrednim znaleziskiem Codeksa i które wynikały wyłącznie z błędów drugiego agenta — czyli Claude Code. Bez tego nie wyłapalibyśmy ich wcale albo nie tak szybko. Wniosek: dwa agenty patrzące na ten sam problem z różnych perspektyw wyłapują rzeczy, których sam bym w życiu nie dostrzegł.
Lekcja 6: Nocne pętle — praca agenta, gdy śpisz
Mając PRD podzielone na slice’y, korzystam ze specjalnego skilla, który utworzyłem na bazie dokumentacji Anthropic, Codeksa i materiałów znalezionych w sieci. Za jego pomocą zlecam Claude’owi lub Codeksowi przygotowanie promptu do komendy goal, dostępnej zarówno w Codeksie, jak i w Claude Code — częściej używam jej w narzędziu OpenAI.
(Informacja dodatkowa: goal (cel) sprawia, że agent pracuje nad zadaniem w pętli, tura po turze, aż je ukończy. Uwaga autora: to on sam uruchamia pętlę — agent wykonuje zadanie w pętli, ale jej nie inicjuje.)
Całość przypomina zostawienie zmywarki na noc — tyle że rano zamiast czystych naczyń masz zrobiony spory kawałek projektu. Zwykle daję Codeksowi pełny dostęp, żeby nie musiał mnie o wszystko pytać (mam to zabezpieczone różnymi hookami systemowymi), i odpalam go w nocy. Codex pracuje, kiedy ja śpię. Rano wstaję, biorę kawę, patrzę na raport od Codeksa i przesyłam całość do audytu Claude’owi.
Warto zaznaczyć, że u mnie ta pętla nie wygląda tak spektakularnie jak na filmach zagranicznych guru AI. Codex nie pracuje dwóch czy trzech dni, tylko nieprzerwanie od jednej do czterech godzin — i sprawdza mi się to świetnie. Żeby taka pętla miała sens, musisz mieć jasno sprecyzowany cel, który da się zmierzyć. U mnie Codex po każdym slice’ie robi testy jednostkowe: jak zapalą się na zielono — commit i dalej; jak nie — próbuje kilka razy. Jeżeli po trzech, czterech próbach się nie uda, a można pominąć krok, to go omija, zapisuje notatkę i idzie dalej; jeśli nie da się pominąć — informuje mnie.
Przy komendzie goal warto dać twardy limit i wyjście awaryjne: jeśli agent wywali się na czymś trzy, cztery, pięć razy, cofamy zmiany, zapisujemy notatkę i — jeśli nie ma blokad — przechodzimy dalej.
Podsumowanie
Poznałeś sześć lekcji, które działają na jednej osi — osi czasu: potrzeba, plan, egzekucja, audyt, noc. Każdy etap mojego workflow był możliwy dopiero wtedy, gdy poprzedni został zrobiony porządnie.
Pamiętaj, że ThumbForge to wciąż mikroaplikacja, która nie zarabia i jest w trakcie budowy. To nie jest historia spektakularnego sukcesu, tylko historia drobnego sukcesu, realnego progresu i procesu. To zaledwie wierzchołek góry lodowej wskazówek, których używam w codziennej pracy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Szukaj pomysłu na aplikację w narzędziach, których już używasz
Na czym polega: Autor nie wymyślił aplikacji „od zera” — zauważył, że jego istniejący skill do miniatur jest niewygodny i drogi, i to stało się zalążkiem produktu.
Jak stosować: Przejrzyj swoje skille, automatyzacje i codzienne narzędzia. Punkty tarcia (coś jest wolne, drogie, niewygodne) to najlepsze kandydatury na własną mikroaplikację.
Na co uważać: Nie myl realnej potrzeby z ambicją zbudowania „czegoś wielkiego”. Metoda działa dla narzędzi na własny użytek, a nie dla SaaS-ów mających zarabiać od pierwszego dnia.
2.Nigdy nie zaczynaj od „zbuduj mi aplikację X”
Na czym polega: Rzucenie agentowi ogólnego polecenia bez planu kończy się kodem, który nie działa albo rozsypuje się przy pierwszej nowej funkcji.
Jak stosować: Przy złożonych zadaniach najpierw uruchom tryb planowania (plan mode) i poświęć realny czas (autor: ~1,5 godziny) na przemyślenie z modelem, zanim powstanie pierwsza linijka kodu.
Na co uważać: Etap planowania jest niewidoczny i kuszące jest, by go pominąć — zwłaszcza dla nietechnicznych. To właśnie tu najczęściej przegrywa się cały projekt.
3.Odwróć role — pozwól AI przepytać ciebie (grillowanie)
Na czym polega: Skill typu „Grill Me” sprawia, że to AI zadaje ci pytania (po jednym naraz) o decyzje, których sam byś nie przewidział — bezpieczeństwo klucza API, limity plików itd.
Jak stosować: Na początku projektu użyj skilla przepytującego, żeby wyciągnąć z siebie i z modelu wymagania. Odpowiadaj konkretnie i korzystaj z rekomendacji modelu.
Na co uważać: Grillowanie ma sens tylko wtedy, gdy naprawdę odpowiadasz przemyślanie — pobieżne „tak/nie” da pozornie wypełnioną, ale bezużyteczną specyfikację.
4.Spisz PRD i wyczyść kontekst przed kodowaniem
Na czym polega: Efektem planowania jest dokument wymagań (PRD) w Markdownie — jedno źródło prawdy o tym, co aplikacja ma robić.
Jak stosować: Poproś model o zapisanie PRD do pliku, potem komendą clear wyczyść kontekst, żeby wejść w kolejny etap „na świeżo”, z dokumentem jako punktem odniesienia.
Na co uważać: Samo PRD to wciąż duży, „przerażający” plik — nie oddawaj go agentowi do wykonania w całości (patrz punkt 5). Dokument jest wejściem do dalszej pracy, nie końcem.
5.Tnij plan na slice’y zakończone testami i commitami
Na czym polega: Duży plan dzieli się na małe, testowalne kawałki. Zielone testy → commit i dalej; czerwone → cofnięcie o jeden krok, a nie o cały projekt.
Jak stosować: Użyj skilla dzielącego PRD na „issues”/slice’y. Niech każdy kończy się testami jednostkowymi projektowanymi przez model i osobnym commitem, żeby zawsze mieć punkt powrotu.
Na co uważać: Bez granularnych commitów jeden błąd może cofnąć cię do zera i zabić projekt. Ta dyscyplina to główne „koło ratunkowe” nieprogramisty.
6.Testy jednostkowe to za mało — testuj przepływ użytkownika przez computer use
Na czym polega: Testy jednostkowe sprawdzają kod, ale nie to, czy kliknięcia, ekrany i przepływy mają sens dla człowieka. Agent z computer use sam przeklikuje aplikację.
Jak stosować: Zleć agentowi (autorowi lepiej działa Codex) przejście najważniejszych ścieżek w aplikacji. Niech Claude przygotuje checklistę, a drugi agent ją wyklika.
Na co uważać: Ustaw twarde bariery — agent ma wołać cię, gdy potrzebna jest ludzka precyzja lub gdy akcja jest płatna (np. generowanie kosztujące pieniądze). Inaczej ryzykujesz niezamierzonymi kosztami.
7.Ustaw dwóch agentów, by audytowali się nawzajem
Na czym polega: Autor kodu jest jego najgorszym recenzentem — dotyczy to też AI. Claude planuje i tworzy, Codex (bardziej pragmatyczny) audytuje i pilnuje porządku, i odwrotnie.
Jak stosować: Po wdrożeniu zmiany poproś agenta piszącego kod o notatkę i plan audytu dla drugiego agenta. Użyj wtyczki Codex for CC, żeby audyt odbywał się w jednej sesji.
Na co uważać: Efekt zależy od różnicy „charakterów” modeli i dobrego przekazania kontekstu (notatka + plan audytu). Sam audyt bez konkretnego planu tego, co sprawdzić, wyłapie mniej.
8.Używaj pętli goal do nocnej, samodzielnej pracy agenta
Na czym polega: Komenda goal sprawia, że agent pracuje nad zadaniem tura po turze aż do ukończenia. Autor odpala ją na noc — rano czeka gotowy kawałek projektu i raport.
Jak stosować: Zdefiniuj mierzalny, sprawdzalny cel, nadaj agentowi odpowiedni dostęp (zabezpieczony hookami) i uruchom pętlę wieczorem. Rano przejrzyj raport i przekaż go do audytu drugiemu modelowi.
Na co uważać: To ty uruchamiasz pętlę, nie agent. Realny czas pracy to raczej 1–4 godziny niż spektakularne „dni bez przerwy” z filmów guru. Pełny dostęp bez zabezpieczeń hookami jest ryzykowny.
9.Zawsze dawaj pętli twardy limit i wyjście awaryjne
Na czym polega: Bez limitu agent może utknąć na jednym problemie w nieskończoność. Reguła: po 3–5 nieudanych próbach cofnij zmiany, zapisz notatkę i — jeśli nie ma blokady — idź dalej lub zawołaj człowieka.
Jak stosować: Wpisz do promptu jasny warunek stopu i ścieżkę awaryjną. Przy pomijalnym kroku niech agent go omija i zapisuje, a przy krytycznym — zatrzymuje się i informuje ciebie.
Na co uważać: „Mierzalny cel” jest warunkiem sensownej pętli — testy jednostkowe (zielone/czerwone) są tu naturalnym miernikiem. Bez kryterium sukcesu pętla marnuje czas i tokeny.
10.To proces na osi czasu, nie jednorazowy trik
Na czym polega: Cały workflow to sekwencja: potrzeba → plan → egzekucja → audyt → noc. Każdy etap jest możliwy dopiero, gdy poprzedni zrobiono porządnie.
Jak stosować: Traktuj budowę mikroaplikacji jako powtarzalny cykl rozłożony w czasie (autor: półtora miesiąca, dziesiątki aktualizacji), a nie jako „apkę w weekend”.
Na co uważać: Nie oczekuj spektakularnego sukcesu ani przychodów — to metoda na realny, drobny progres i narzędzia na własny użytek. Pominięcie wcześniejszego etapu podważa wszystkie kolejne.