O czym jest ten film
- Premiera modelu GPT 5.6 i pokaz, jak korzysta z niego Dan Shipper — gość Grega Isenberga.
- Codex (aplikacja desktopowa OpenAI) przedstawiony jako „system operacyjny do pracy”, a nie tylko narzędzie dla programistów.
- Praktyczny setup do obsługi poczty: aplikacja „Tend”, która zamienia nieprzeczytane maile w karty z gotowymi szkicami odpowiedzi.
- Koncepcja „pulsów”, „przypiętych wątków”, „routerów” i „heartbeatów” — wzorce organizacji pracy w Codeksie.
- Porównanie GPT 5.6 z modelem Fable: 5.6 to „solidne A”, Fable to „S+”, ale wolniejszy i droższy.
- Teza o „agent-native SaaS” — oprogramowaniu projektowanym pod współpracę użytkownika i agenta w jednym miejscu.
- Argument przeciw „apokalipsie SaaS”: ludzie płacą za utrzymanie, nie za pierwszą wersję produktu.
- Wspólne zbudowanie na żywo mini-produktu „Turnaround” — odznaki potwierdzającej aktywne utrzymanie aplikacji.
- Podział twórców na „piratów” (szybko do 70%) i „architektów” (dopracowanie do 100%).
- Rada na start: zacznij od jednej prostej rzeczy, kieruj się ciekawością, a nie FOMO.
Redakcyjne tłumaczenie
Wprowadzenie
Greg Isenberg: GPT 5.6 właśnie się pojawił i to duża rzecz. Mój znajomy Dan Shipper testuje go od tygodni, a w tym odcinku pokaże wam, jak używać Codeksa z GPT 5.6, żeby prowadzić swoje życie prywatne i firmę. Jego setup jest naprawdę świetny. Do końca odcinka dowiecie się, gdzie 5.6 sprawdza się, a gdzie nie. Nauczycie się też korzystać z Codeksa w naprawdę ciekawy sposób, żeby zarabiać, być produktywniejszym i automatyzować całą tę nudną robotę. Cieszyłem się, że mogłem gościć Dana — to studnia wiedzy i pokazuje wszystko. Miłego oglądania, do zobaczenia na końcu.
Bardzo się cieszę na tę rozmowę. Dan Shipper. Błagałem go, żeby przyszedł — i przyszedł. Dan, czego się dziś nauczymy?
Dan Shipper: Nauczymy się, jak używać Codeksa do prowadzenia całego swojego życia i jak zbudować przy jego pomocy dobry biznes softwarowy.
Greg: Masz moją uwagę.
Dan: Zaczynamy?
Greg: Ruszamy.
Czym jest Codex
Dan: Jeśli nie używałeś Codeksa, to jest to odpowiedź OpenAI na Claude Code, Claude Desktop i Claude Co-Work. Jeśli już go używałeś, mogłeś mieć do czynienia z Codex CLI, którego odradzam — to jest po prostu słabe. Ale aplikacja desktopowa Codex to jest to, czym mogłaby być aplikacja Claude Desktop, gdyby ktoś ją wyrzucił i zbudował od nowa z pytaniem „jaki jest idealny sposób, żeby to zrobić?”.
(Informacja dodatkowa: „Claude Code”, „Claude Desktop” i „Claude Co-Work” to narzędzia agentowe firmy Anthropic; Codex to odpowiednik OpenAI.)
Bo w tej chwili w aplikacji Claude Desktop masz osobno czat, osobno kod, osobno co-work i ciągle się zastanawiam, którego użyć. A Codex — no, teraz też mają dwie zakładki, ale to jest dużo prostsza, czystsza i mocniejsza implementacja. Bo powstała, kiedy OpenAI zdążyło już zobaczyć ten nowy paradygmat: używanie agenta na własnym komputerze do pracy umysłowej. To już się zaczęło dziać dzięki Claude Code i Claude Co-Work, a OpenAI jakby przewinęło cały ten bałaganiarski etap i powiedziało: „to jest idealna implementacja”.
Mam wrażenie, że Anthropic ma teraz trochę „mandat nieba”, a OpenAI jest mocno niedoceniane — i myślę, że Codex jest tego powodem.
GPT 5.6 kontra Fable
Dan: Codex z 5.6 to według mnie najbardziej użyteczny, najmocniejszy i najszybszy model konkretnie do pracy umysłowej — i do kodowania, ale przede wszystkim do pracy umysłowej. To nie jest poziom Fable — Fable jest jak taktyczny pocisk jądrowy, tak potężny, że aż nielegalny. Ale nie chcę używać militarnych porównań, więc odejdę od tego, bo to nie broń. To bardziej jak posiadanie Porsche: świetne do jeżdżenia po mieście, zrobisz w nim wszystko, jest szybkie i dobrze się prowadzi. Świetnie nadaje się do współpracy.
(Informacja dodatkowa: „Fable” to nazwa najmocniejszego, ale wolnego i drogiego modelu, o którym rozmówcy mówią jako o klasie „S+”.)
Fable traktuję jako coś, do czego trzeba mieć dużo umiejętności, żeby dobrze go używać. A 5.6 po prostu działa do wszystkiego, czego od niego chcesz. To długi sposób powiedzenia, że 5.6 i Codex to miejsce, w którym spędzam cały swój czas. To mój system operacyjny do pracy. Robię tam wszystko — od maili, przez pisanie, po — co teraz zaczynam — trenowanie modeli, co uważam za nową granicę.
Greg: Nawet nie wiem, co to znaczy. Chcę do tego wrócić później w odcinku.
Dan: Wejdźmy w to. Krótka zapowiedź: trenowanie własnego modelu to następny krok po zrobieniu własnego skilla. Jeśli zrobiłeś skilla do czegoś i nie działa idealnie, to fine-tuning modelu jest kolejnym krokiem. Do niedawna było to całkowicie poza zasięgiem i niepraktyczne. Ale 5.6 — i po części Fable, jeśli obejdziesz zabezpieczenia — ułatwia zbudowanie i uruchomienie pipeline’u uczenia maszynowego. Od zdobycia danych, przez tworzenie danych syntetycznych, po prowadzenie eksperymentów. Uważam, że teraz mogą to robić także osoby, które nie są inżynierami uczenia maszynowego.
Obsługa poczty: aplikacja „Tend”
Greg: Jestem zaintrygowany. Chętnie zobaczę, co masz. Podzielisz się ekranem?
Dan: Jedziemy. Tak obsługuję pocztę. To jest mała aplikacja, którą zbudowałem. Nazywa się „Tend” i zanim ten odcinek wyjdzie, prawdopodobnie będziesz mógł ją dostać jako bibliotekę open source, którą wypuszczę. Ale szczerze — możesz po prostu wrzucić ten film do Codeksa i powiedzieć „zrób coś takiego”, a on to zrobi.
Zasadniczo aplikacja przechodzi przez moją skrzynkę każdego dnia i znajduje każdy nieprzeczytany mail. Dla każdego robi kartę, która streszcza treść, i dołącza szkic odpowiedzi. Mogę wtedy powiedzieć: „nie zająłem się tym jeszcze, znajdź kilka wolnych terminów w tym tygodniu i pokaż mi je w szkicu” — i on to zrobi. Przechodzę tak przez maile jeden po drugim.
Greg: To przypomina mi, jak wyobrażam sobie odpowiadanie na listy przez bardzo bogatych menedżerów w latach 60., w stylu „Mad Men”.
Dan: Dokładnie to samo, tyle że teraz może to robić każdy.
Przypięte wątki, pulsy i feedy
Dan: Fajne w tej aplikacji jest to, że działa nie tylko na skrzynkę. Mamy aplikację pocztową o nazwie Kora, która jest pełnym doświadczeniem skrzynki zaprojektowanym do używania właśnie w ten sposób. Ale to jest open-source’owy eksperyment — jeśli jesteś twórcą, możesz zbudować własny.
Mój Codex jest zbudowany tak, że mam mnóstwo przypiętych wątków — po jednym na każdą część życia, na której mi zależy. To jest wątek mojej firmy. Zamiast przeglądać skrzynkę, znajdzie wszystkie slacki i notatki ze spotkań, których jeszcze nie widziałem, i zamieni je w karty. Daje mi obraz tego, jakie sprawy dzieją się w firmie, a ja decyduję, czy dana rzecz mnie interesuje. Jeśli tak, mogę powiedzieć „napiszę do Brandona” i zapytać, co się dzieje. Jeśli nie — po prostu archiwizuję.
Co ciekawe, z czasem uczy się, na czym mi zależy i co powinien mi przynosić, a także jaka jest zwykle najlepsza kolejna akcja — czyli to, co normalnie bym zrobił. Po przejściu przez feed — czy to firmowy, czy skrzynkę — kompiluje wnioski z tego, co polubiłem albo nie, co zarchiwizowałem, na co odpowiedziałem, i zamienia to w poprawione prompty. Widać tu wszystkie prompty: politykę feedu, na czym mi zależy, co mam na głowie, jak sięgać po konkretne źródła. To po prostu zmienia sposób, w jaki pracuję każdego dnia, bo wszystko można zamienić w feed z kartami i najlepszą kolejną akcją.
A z 5.6 po prostu widzisz lepsze wyniki. Powiedziałbym, że 5.5 był w porządku, ale niewystarczająco dobry. Ten szkic maila jest tak, jakbym sam go napisał. Może coś bym lekko zmienił — i czasem zmieniam — ale przy 90% maili, które są o umawianiu spotkań i ogólniejsze, jest świetny. To bardzo dobry pisarz i robi znacznie mniej błędów. Nie wysyła maili, których pewnie bym nie chciał wysłać. Jest bardziej ostrożny. I bardzo zaradny — łatwo łączy się ze Slackiem, łatwo przegląda sieć. Wynająłem nowe mieszkanie i dosłownie kazałem mu przeszukiwać Facebook Marketplace i renderować, jak będzie wyglądał pokój gościnny. To jest szalone.
Codex jako system operacyjny
Dan: Myślę, że ludzie nie doceniają, jak elastyczne i potężne to narzędzie. Ma w sobie model obrazów, a do tego potrafi zmieniać inne wątki. Mogę sprawić, że ten wątek napisze do innego wątku Codeksa i nagle orkiestrujesz różne agenty robiące różne rzeczy.
Greg: To był mój moment olśnienia z Codeksem — gdy zacząłem odwoływać się do innych wątków i on zapamiętywał rzeczy. Powiedziałeś, że Codex to system operacyjny; widziałem tę tezę od dawna, ale dopiero gdy zacząłem naprawdę łączyć rzeczy ze sobą, zrozumiałem — to plus przeglądarka.
Dan: Dokładnie — to wrażenie systemu operacyjnego. Powodem, dla którego mogę robić tu całą swoją pracę, jest wbudowana przeglądarka. To jest Proof — edytor markdown, który zrobiłem. To mój dzisiejszy dzień: planuję go, klikam rzeczy, a potem mówię „dodaj agendę do wywiadu do podcastu o pomysłach na startupy” i Codex to robi. Kiedy on to robi, ja piszę sobie na dole kilka myśli. On idzie i robi researche — wie, co budujemy, wie, jakie mam pomysły. To jedna z najlepszych rzeczy: ma cały kontekst tego, kim jesteś i na czym ci zależy, i może go wnieść do każdej aplikacji, której używasz.
Model będący potężnym jest ważny, ale model jest tylko tak potężny, jak kontekst, który możesz mu dać. A to jest podłączone do całego twojego komputera i całego internetu.
Dlaczego „apokalipsa SaaS” to bzdura
Dan: Uważam, że „apokalipsa SaaS” to bzdura. Owszem, vibe-koduję sobie tę aplikację do skrzynki, ale 99% świata będzie chciało używać czegoś, co utrzymuje ktoś inny. Tak, możesz wszystko zrobić za jednym strzałem, ale trudną, rzadką umiejętnością jest przejście do: czy potrafisz zbudować i utrzymać coś w czasie. A to wciąż jest drogie i trudne.
(Informacja dodatkowa: „vibe coding” to potoczne określenie szybkiego generowania działającego kodu przez AI bez dbałości o strukturę; „oneshot” — wygenerowanie czegoś za jednym podejściem.)
Ogólnie myślę o oprogramowaniu tak: jeśli możesz wnieść do niego swojego agenta, to jest bardzo potężne — dajesz mu strukturę, w której może działać. Mamy teraz spory biznes konsultingowy. Pierwsze, co spróbowaliśmy zrobić, to zvibe-kodować własny CRM jako połączenie agenta i Google Sheets. Da się to zrobić, ale szybko robi się z tego bałagan. Przeszliśmy więc na dostawcę CRM, który ma CLI — przemyśleli wszystkie drobne przypadki brzegowe i będą to robić dalej — a my możemy robić właściwą robotę zamiast vibe-kodować rekordy klientów. Jestem bardzo optymistyczny wobec SaaS-u, zwłaszcza takiego zaprojektowanego do używania wewnątrz przeglądarki Codeksa.
Greg: Tak — możesz zbudować cokolwiek, ale ludzie płacą za utrzymanie. Jeśli to coś działa, chętnie za to zapłacę. Kolejnym momentem olśnienia było zobaczenie mojego SaaS-u po prawej stronie i tego, jak wymienia się on z moimi wątkami — jak można się tak odbijać w tę i z powrotem. Wygląda, jakbyś mógł dosłownie spędzić 99% czasu w Codeksie albo w jakiejś super-aplikacji.
Dan: Zgadzam się. Trochę waham się, czy koncept super-aplikacji zadziała, ale absolutnie — to jak system operacyjny. Mówimy „aplikacja”, ale to naprawdę system operacyjny.
Budujemy na żywo: „Turnaround”
Dan: Zbudujmy coś. Skoro maintenance jest tym, za co ludzie płacą, bo cokolwiek można teraz zrobić za jednym strzałem, chcę zrobić mały SaaS, który pomaga ludziom pokazać, że ich aplikacja jest utrzymywana. Na GitHubie jest już coś takiego — widać liczbę commitów w danym okresie — ale potrzebujemy tego dla każdej aplikacji SaaS w internecie: żeby było widać, że ktoś to utrzymuje. I nie tylko to — kiedy zgłoszono błąd albo poproszono o funkcję, ile czasu zajęło jej naprawienie czy dodanie. To sygnał, że ktoś nad tym pracuje, a nie że to vibe-kodowany strzał na raz.
Nazwijmy to „Turnaround”. Idea jest taka: wartość SaaS-u nie leży w budowie pierwszej wersji, tylko w utrzymaniu. Potrzebujemy sposobu, żeby ludzie prowadzący aplikacje mogli pokazać wykonywane utrzymanie — czyli czas obsługi od zgłoszenia błędu do naprawy albo ogólną liczbę commitów. Chcę ładną odznakę do wstawienia na stronie „o nas”, która potwierdza, że aplikacja jest aktywnie utrzymywana. Trochę jak GitHub, ale ma wyglądać dobrze, nowocześnie, „AI i futurystycznie”. Każdy może się zapisać, wstawić odznakę na stronie, a naszą rolą jest weryfikacja na backendzie. Powinno działać z dowolnym źródłem — Linear, Notion, cokolwiek.
(Informacja dodatkowa: efekt dźwiękowy przy dyktowaniu pochodzi z aplikacji „Monologue” — narzędzia speech-to-text zespołu Dana.)
5.6 kontra Fable — ile brakuje
Greg: Powiedziałeś, że to nie do końca Fable, ale blisko. Jak blisko — 80%, 90%? Fable jest na 100%.
Dan: Fable to model klasy S+, tak dobry, że aż nielegalny, a to jest model klasy A. Nie zhakujesz NSA za pomocą 5.6. Z Fable dosłownie opróżniliśmy backlog błędów — mogłeś go po prostu puścić i, o ile byłeś gotów wydać pieniądze, sam się opróżniał. Z 5.6 tak nie jest — musisz trochę pomyśleć, żeby naprawić błędy. Ale blisko — powiedzmy 60–70%. Fable to jednak inna kategoria, bo jest też tak wolny i drogi, że w zasadzie nadaje się tylko dla ludzi robiących uczenie maszynowe albo orkiestrujących floty agentów — a to umiejętność, której większość ludzi jeszcze nie ma.
Gust i punkt widzenia modelu
Dan: Codex pyta: co odznaka ma obiecywać klientom — „żywa”, „responsywna” czy „niezawodna”? I podoba mi się, że jest rekomendowana opcja: „niezawodna”.
Greg: Całkiem dobre, prawda?
Dan: Tak. To był mankament wcześniejszych modeli — nie miały gustu… nie chcę używać słowa „gust”, nie powinniśmy go używać. Nie miały punktu widzenia, opinii. A 5.6 ma dobre wyczucie. Podobają mi się różne wektory: czy jest żywa, responsywna, niezawodna. Częściowo używam tu naszej wtyczki compound engineering, ale to są po prostu dobre opcje.
(Informacja dodatkowa: „compound engineering plugin” to wtyczka autorstwa Kierana Classena, twórcy Kory, zbierająca jego praktyki inżynierii AI.)
Na pytanie, co się dzieje, gdy aktywność ustaje — stan zmienia się automatycznie, ale bez oceniania. Po prostu: „jeden commit w ciągu ostatnich 30 dni” albo coś w tym stylu. Model powinien używać konkretów, żeby powiedzieć, co się dzieje, żebyś sam mógł to zobaczyć — a nie osądzać „żywa” kontra „martwa”.
Od strony szybkości — jest świetny, bardzo szybki i konkretny. Nie pisze za dużo.
LFG, goal i trening modelu
Greg: Co to jest LFG i „goal”?
Dan: LFG to znowu nasza wtyczka compound engineering, autorstwa Kierana Classena, który prowadzi Korę i jest genialnym inżynierem AI. LFG przechodzi przez cały cykl: zaplanuj, wykonaj pracę, przejrzyj ją, skompiluj wnioski i idź dalej, aż będzie zrobione. A „goal” to wersja Codeksa polegająca na daniu modelowi wysokopoziomowego, długoterminowego celu, do którego dąży, aż go osiągnie.
Na przykład jedna z rzeczy, które robię — trenuję model do robienia korekt tekstu. Ten cel działa od czterech godzin i po prostu go zostawiłem. A cztery godziny to szczerze mało — w weekend miałem jeden czy dwa, które szły po jakieś 20 godzin każdy. To bardzo przyjemne móc powiedzieć: „tu chcę, żebyś dotarł, oto weryfikowalne kryteria, które powiedzą mi, że skończyłeś, a ja zajmę się czymś innym”. Choć w praktyce odkryłem, że jestem uzależniony od oglądania strumienia na żywo, czego nienawidzę, ale tak już mam.
Punkt kontrolny projektowy w 5.6
Dan: Kolejna miła rzecz w 5.6 to punkt kontrolny projektowy. Starają się, żeby był lepszy w designie. Nie jest idealny — z jakiegoś powodu zawsze chce robić ciepłe, papierowe tła. Jest lepiej, ale nie idealnie — dałbym mu B, podczas gdy wcześniejsze modele były na C lub D.
Greg: Ale przynajmniej pyta.
Dan: Przynajmniej pyta. Przynajmniej myśli o ciepłym papierze, a ja mogę powiedzieć „nie, chcę chłodny papier”. W przeszłości po prostu skakał do wniosków — i wtedy masz stronę wyglądającą jak wszyscy inni. Pewnie dają ci teraz szansę dodania kontekstu, zanim ruszą dalej.
Wielka szansa: SaaS „codex-native”
Dan: Uważam, że jest ogromna szansa na aplikacje SaaS natywne dla Codeksa. Pomyśl o dowolnym narzędziu SaaS, którego używasz — poczta, CRM, cokolwiek. Każde oprogramowanie, którego używasz codziennie, byłoby lepsze, gdyby było zbudowane do używania wewnątrz czegoś takiego jak Codex, gdzie możesz wnieść do niego agenta, który ma cały kontekst o tobie.
I nie chodzi o to, żeby projektować to jako CLI, gdzie agent działa bez ciebie i tylko delegujesz. Chodzi o to, żebyś ty i agent pracowali razem na tej samej powierzchni, wewnątrz Codeksa. To zresztą programiści już wiedzą — przeglądarka istnieje właśnie dlatego, że budując aplikację chcesz używać jej w tym samym miejscu, w którym używa jej agent, żeby pętla sprzężenia zwrotnego była krótsza. To samo dotyczy każdej pracy umysłowej. Kto to zrozumie, ma ogromną szansę, bo większość aplikacji nie jest tak zaprojektowana.
Greg: Czy myślisz, że klienci będą szukać tych agent-native aplikacji?
Dan: Jeśli są mądrzy. Jest grupa wczesnych entuzjastów, która zaczyna to rozgryzać, i minie chwila, zanim stanie się to głównym nurtem. Ale szansa polega na tym, żeby zacząć budować pozycję jako aplikacja codex-native dla konkretnej kategorii, tak żeby gdy przyjdzie masowa adopcja, być tym miejscem, do którego ludzie idą. Zacząłbym pozycjonować się pod to i robić landing page’e o używaniu produktu wewnątrz Codeksa.
Mając wgląd w te firmy, myślę, że wiele firm modelowych i dużych firm AI widzi to jako kierunek, w którym rzeczy się poruszają. Jedna z fajnych rzeczy: dziś firmy SaaS instalują agenty w swoich produktach, więc muszą płacić koszty tokenów. W tym świecie jesteś po prostu dostawcą SaaS, hostujesz oprogramowanie — brak kosztów tokenów, a marże wracają do poziomu zwykłego biznesu softwarowego zamiast biznesu AI. To świetne.
Greg: To też świetne dla ludzi, którzy nie chcą iść drogą finansowania przez fundusze VC. Wiele osób mówi: „chciałbym zbudować biznes, który robi 10 milionów rocznie przy niskich kosztach”. Ludzie patrzą na te agent-native SaaS-y i widzą: firma robi 80 milionów przychodu rocznie, ale wydaje 60 milionów na tokeny. Dla niektórych to ciekawe, dla innych nie.
Zastanawia mnie jedno — dystrybucja. To nie jest podobne do ery mobilnej, gdy był App Store. Zbudowałem aplikację w 2013 roku, zostaliśmy wyróżnieni w App Store i dostawaliśmy 25 000 pobrań dziennie tylko z tego wyróżnienia. Byłoby świetnie, gdyby Codeksy i Cloud’y tego świata zaczęły promować aplikacje, które poprawiają doświadczenie.
Dan: Założę się, że będą. OpenAI uruchomiło już dosłownie trzy czy cztery różne sklepy z aplikacjami. Co roku mają nowe podejście do sklepu, bo wiedzą, że ten schemat działa świetnie. Sklep z aplikacjami jest niesamowity, bo masz ekosystem i ludzi budujących w nim — a chodzi nie tylko o to, co ty zbudujesz, ale o wartość, którą odblokowujesz dla wszystkich innych budujących na twojej platformie. Założę się, że w ciągu roku OpenAI i Anthropic będą miały sklepy z aplikacjami budowanymi specjalnie pod używanie wewnątrz tych usług. Może nawet Cursor. Nie mam żadnych informacji z wewnątrz — to po prostu zbyt dobra okazja biznesowa i logiczna rzecz, jeśli dorastałeś w erze aplikacji i widziałeś, jak dobry był App Store.
Ocena efektu „Turnaround”
Dan: No i mamy — ciepłe, papierowe tło. To jest jego podejście: poprawili design, ale to pewien rodzaj płaskiej estetyki, która moim zdaniem nie jest tu odpowiednia. Patrzymy na zmockowaną wersję embeda: na stronie „o nas” Kory — 26 commitów w ciągu 30 dni — widać, jak aktywny jest projekt. Nie wiem, czy „commity” to właściwe słowo, zwłaszcza jeśli mamy to nazwać „Turnaround”. To w zasadzie strona statusu dla ery vibe-kodowania, pokazująca, czy w projekcie dużo się dzieje. Nie do końca podoba mi się początkowa wizualna realizacja, ale widać, o co chodzi.
Greg: Zupełnie. To jakieś 75% drogi.
Dan: Tyle, że mogę to zobaczyć i pewnie opublikować taki landing page. Ale szczerze — na tym etapie poszedłbym do Claude’a po właściwy design i przeniósł go z powrotem tutaj, bo wciąż uważam, że Claude ma lepsze wyczucie, zwłaszcza Fable, ale nawet 4.8 byłoby tu lepsze. Dla takiego produktu możliwość zrozumienia go na pierwszy rzut oka jest najważniejsza, a tu Opus i ogólnie Claude wciąż są z przodu.
(Informacja dodatkowa: „Opus”, „4.8” i „Fable” to modele z rodziny Claude firmy Anthropic; Dan sugeruje sięganie po nie do zadań designerskich.)
Modele open source i fine-tuning
Greg: Co sądzisz o używaniu np. Cursora czy Codeksa z lokalnymi modelami? Jest cała nowa fala lokalnych modeli. Jesteś „token maxi”, który używa tylko OpenAI i Anthropic, czy jak o tym myślisz?
Dan: Mam przeczucie, że modele open source będą bardzo ważne dla mojego sposobu pracy. Obecnie nie są. Po pierwsze, jako osoba i w tym, co pokrywamy, po prostu chcę być na czele — chcę cały czas „fable-maxować”. Ale zaczynamy dochodzić do punktu, gdzie nawet dla mnie postępy w surowej inteligencji są w pewnym stopniu trudne do skonsumowania. Nie mam wystarczająco dużego problemu, żeby używać Fable do wszystkiego. Używam go, ale nie do wszystkiego.
Gdy zaczniemy zbliżać się do tego sufitu, gdzie nie umiem skonsumować dodatkowej mocy modelu, wtedy szybkość, koszt i wydajność staną się ważniejsze — i wtedy zainteresuję się włączaniem większej liczby modeli open source do swojego workflow. Poza tym, robiąc fine-tuning, musisz używać modeli open source, bo żadna z głównych firm — przynajmniej OpenAI i Anthropic — właściwie już nie robi fine-tuningu.
Uważam to za wielki obszar szansy. Te modele wciąż nie potrafią robić korekty tekstu tak jak korektor. To dziwne, bo korekta nie powinna być taka trudna — przynajmniej do jakichś 70%. Mamy wewnętrzne dane: przez pięć–sześć lat zrobiliśmy dziesiątki, jeśli nie setki tysięcy korekt. Powinniśmy móc zamienić to w wytrenowany model i go sprzedać. Myślę, że jest wiele organizacji z tym samym rodzajem danych bazowych, które mogą zamienić w produkt albo zdolność.
Jak dowieźć od 70% do 100%: piraci i architekci
Dan: Co dostaliśmy? „Neutralna odznaka”, podglądy Kory i Monologue. Ale jak to zaimplementować, żeby się aktualizowało? Widzę, że próbuje obejść ten trudny problem. Otwórzmy README. Ta wersja waliduje odznakę, publiczny rejestr, tożsamość wizualną, język pomiaru, konta, uwierzytelnianie, trwałość, rozliczenia, pobieranie danych z GitHuba i wygenerowany kod embeda. Pewnie powinienem był poświęcić trochę więcej czasu, żeby go docisnąć i wydobyć z niego najlepsze. Powiedziałbym, że jesteśmy na 70%. Potrzeba jeszcze trochę dogotowania języka projektowego i implementacji, żeby faktycznie podpiąć to pod twój GitHub albo Linear.
Greg: Ludzi zaciekawiłoby, jak Dan Shipper bierze vibe-kodowany projekt od 70% do 100% w Codeksie z 5.6.
Dan: Dobre pytanie. To, co przed chwilą powiedziałem — po prostu to robisz. Powiedziałem mu: „zrób pełną wersję V1”.
Mam takie rozróżnienie na dwa typy ludzi w epoce AI — albo dwa typy twórców: piratów i architektów. Pirat mówi: „doprowadzę to do 70%, zbadam pole możliwości i zbuduję coś, co działa na tyle, żebym mógł ocenić, czy to ma wartość”. Architekt jest świetny w mówieniu: „to jest wartościowe, ale nieprzemyślane — jak zamienić to w dobrze naoliwioną maszynę, która naprawdę działa?”.
Ponieważ wiem, że sam jestem taki — „mam pomysł, idę coś zbudować, wytrenować model przez weekend, zrobić małą aplikację” — dobieram sobie architekta, który czerpie energię z tego, że przychodzę z ekscytującą nową rzeczą, i ma przyjemność w wzięciu tej uformowanej w 70% rzeczy i zamienieniu jej w coś naprawdę dopracowanego. To nowy, ciekawy podział. Kiedyś mówiliśmy „potrzebuję technicznego współzałożyciela”, a teraz to już nie to, bo każdy potrafi kodować. Teraz chodzi o twój zestaw wrażliwości i chęć — zrobić coś nowego i szybko, kontra zrobić coś dopracowanego i wysokiej jakości. Obie rzeczy są bardzo ważne.
Mailroom, routery i heartbeaty
Greg: Jak jeszcze używasz Codeksa na żywo?
Dan: Mamy maile, mamy różne „pulsy”. Puls to coś, co uruchamia się codziennie albo kilka razy dziennie, zbiera wszystkie informacje i wkłada je w karty. Zbudowałem też coś, co nazwałem „Mailroom” — daje mojemu Codeksowi adres e-mail, który jeździ na wierzchu mojej poczty. Znasz format z plusem w mailach — możesz zrobić np. greg+codex@gmail.com. Wykorzystuję ten format, żeby zarejestrować adres wewnątrz mojej poczty. Mam „dan+codex” z losowym ciągiem znaków, żeby nie dało się go tak po prostu odgadnąć.
(Informacja dodatkowa: „format z plusem” to standardowa funkcja Gmaila — wszystko po znaku „+” przed „@” trafia do tej samej skrzynki, co pozwala tworzyć adresy-aliasy.)
Mam wątek-router, który regularnie — co pięć czy piętnaście minut — sprawdza tę skrzynkę. Ten adres mogę komuś dać. Na przykład mamy wewnętrznego agenta w naszym Slacku. Gdy ktoś prosi mnie o coś, a ja nie jestem najlepszy w rzeczach operacyjnych, wie, żeby zapytać agenta w Slacku, a ten wie, żeby napisać maila do mojego Codeksa zamiast do mnie. Widzę, co się dzieje, ale on się tym zajmuje za mnie. Samo podpięcie Codeksa pod adres e-mail — czy przez Mailroom, czy inaczej — jest niedocenianie potężne.
I ogólnie: nauczenie się, jak działają „heartbeaty” — gdzie wątek jest aktywowany co jakiś czas — oraz „routery” — gdzie mail wpada do wątku, który sprawdza pocztę cały czas, i jest routowany dalej: czy trafia do skrzynki, do pulsu firmowego, czy gdzie indziej — to kolejny bardzo dobry wzorzec dobrego używania Codeksa.
Greg: Chciałbym po prostu skopiować sposób, w jaki Dan Shipper używa Codeksa, i zduplikować go, zamiast wrzucać transkrypt tego filmu do Codeksa — choć pewnie by to rozgryzł. Szkoda, że nie ma łatwiejszego sposobu.
Dan: To dobry pomysł, szczerze. Zróbmy to — nowy Codex. Ta rzecz „Tend”, którą ci pokazałem, jest częścią próby zrobienia tego. Ale jest jeszcze mnóstwo innych drobiazgów — routery, heartbeaty — które zdecydowanie mógłbym spakować. To akurat, co teraz buduje, pewnie nie zamieni się w wielką rzecz, bo to tylko backend, więc jak w ogóle to pokazać — to jest pytanie. Możemy przejść dalej.
Jak zacząć: pobierz, daj dostęp, zysk
Greg: Co jeszcze ludzie powinni wiedzieć o Codeksie i 5.6? Jeśli ktoś chce prowadzić firmę albo życie prywatne na Codeksie — od czego musi zacząć?
Dan: Ludzie myślą „Codex, czyli do kodowania” — a to nieprawda. Albo mówią „ale ja już używam ChatuGPT” — a to zupełnie co innego, w ogóle nie to samo. Pierwszy krok to po prostu pobrać. Drugi — dać mu dostęp do komputera. Trzeci — zysk.
Jedną z rzeczy, które uwielbiam, jest powiedzenie: „czy możesz zaproponować mi rzeczy, które możesz dla mnie zrobić, na podstawie tego, jak używam komputera?”. Codex ma coś, co nazywa się „Chronicle” — automatycznie robi zrzuty ekranu twojego komputera i lokalnie zamienia je w feed dający mu kontekst o tym, kim jesteś i co robisz. Z czasem buduje ten feed: „Dan pracuje w Slacku, rozmawia z Brandonem o tej rzeczy” albo „jest z Gregiem i rozmawiają o tematach na odcinek” — i to poprawia jego odpowiedzi.
Ludzie mogą uznać za niepokojące, że robi zrzuty ekranu. Można to włączać i wyłączać — Chronicle to research preview, jest opcjonalny. Ja mam go włączonego, bo wszystko jest lokalne, a ogólnie wolę, żeby miał więcej kontekstu o mnie, żeby odpowiedzi były lepsze.
Wypuszczają też ciągle nowe rzeczy. Właśnie wypuścili coś, czego sam jeszcze nie używałem, więc nie mogę się osobiście wypowiedzieć, ale wygląda świetnie — wtyczka do nagrywania i odtwarzania. Uruchamiasz ją, mówiąc „obserwuj, jak to robię”, a ona nagrywa twój ekran podczas zadania i automatycznie zamienia to w skilla, żeby wykonać to w przyszłości. Takie rzeczy są super.
(Informacja dodatkowa: Greg i Dan doprecyzowują później, że wtyczka nazywa się „record and replay”.)
Zmiana nastawienia: zarządzasz systemem, nie robisz roboty
Dan: Każde powtarzalne zadanie — zdecydowanie rób wewnątrz Codeksa. Zawsze, gdy robię pracę na komputerze poza nim, myślę: jak mógłbym zrobić to tutaj? Bo jest zmiana nastawienia — od robienia pracy samemu do zarządzania systemem, który robi pracę za ciebie. To ta sama zmiana, którą przechodzą menedżerowie albo założyciele, gdy zatrudniają pracowników. To specyficzna umiejętność ery — nie dla każdego kawałka pracy, ale dla pewnej jej części: przełączenie nastawienia na „to nie chodzi o żadnego pojedynczego maila, tylko o system, który obsługuje moją pocztę — i to jest moja praca”.
Greg: Tak myślę o optymalizacji życia na Codeksach i Claude Code — mam zestaw SOP-ów, standardowych procedur operacyjnych. Wkładam je do tych aplikacji: „jeśli zdarzy się to, zareaguj tak albo zrób tę rzecz”. To dla mnie klucz — żeby robił nudne zadania na wysokim poziomie. Jeśli to potrafisz, to cudowne.
Zacznij od jednej prostej rzeczy — ciekawość zamiast FOMO
Dan: Zgadzam się. I dodałbym: nie patrz na mój setup ani swój i nie myśl „muszę zbudować całą tę machinę”. Skończysz, marnując mnóstwo czasu na setup, który nie działa. Zacznij od jednej prostej rzeczy, która czyni twoje życie lepszym i która cię interesuje. Zrób to, a potem buduj z czasem. Ja też nie zacząłem tak, jak teraz wygląda mój system — zacząłem od „oto problem, który mam, zobaczmy, czy potrafię go rozwiązać”. Rozwiązałem, potem budowałem dalej. Każdego system będzie wyglądał trochę inaczej.
Jeśli jesteś w świecie oprogramowania od dawna, rozpoznasz w tym sposób, w jaki ludzie używali Notiona pięć lat temu czy Roam. Z oprogramowaniem do produktywności zawsze jest pokusa, żeby pracować bardziej nad systemem niż nad pracą i budować gigantyczną, złożoną machinę. Lepiej zacząć od czegoś prostego i budować to, czego potrzebujesz, żeby zrobić główną rzecz, którą chcesz zrobić — zamiast robić z rzeczy pobocznej rzecz główną.
Greg: Sto procent. Jesteśmy z tobą największymi nerdami, więc oczywiście pchamy rzeczy do ekstremum — i przez to jest zabawnie. Ludzie lubią nas słuchać, bo widzą, ile da się zrobić. Ale to może być przytłaczające — patrzą i myślą „nigdy nie ustawię wszystkich tych rzeczy”. A prawda jest taka, że to, co działa u nas, może nawet nie działać u ciebie. Możesz znaleźć zupełnie inny sposób automatyzacji swojego życia i biznesu — trzy czy cztery rzeczy i to wystarczy.
Dan: Dokładnie. Zdarza się też, że widzisz coś takiego i masz przytłaczające FOMO. A to nigdy nie jest dobry sposób wchodzenia w nową technologię. Dużo lepiej wejść w nowe narzędzie AI, bo jesteś naprawdę ciekawy i naprawdę czegoś od niego chcesz — a nie dlatego, że boisz się zostać w tyle. Więc gorąco polecam: znajdź coś, co cię autentycznie ekscytuje, żeby użyć do tego Codeksa, zamiast używać go z lęku przed przegapieniem.
Greg: Dan Shipper, byłeś hojny ze swoim czasem i dzieleniem ekranu — odsłoniłeś wszystko, doceniam to. Wrzucę linki do śledzenia Dana i jego publikacji w opisie. Gorąco polecam. Coś na koniec?
Dan: Nie. Dziękuję za zaproszenie, było świetnie. Zawsze przyjemność. Do zobaczenia następnym razem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Traktuj Codeksa jak system operacyjny do pracy, nie jak narzędzie do kodowania
Na czym polega: Aplikacja desktopowa Codex z modelem GPT 5.6 może obsługiwać całą pracę umysłową — pocztę, planowanie, research, zarządzanie firmą — dzięki wbudowanej przeglądarce i dostępowi do całego komputera oraz internetu.
Jak stosować: Pobierz aplikację desktopową (nie CLI), daj jej dostęp do komputera i zacznij od pytania „na podstawie tego, jak używam komputera, zaproponuj rzeczy, które możesz dla mnie robić”. Za każdym razem, gdy robisz pracę poza Codeksem, pytaj siebie: „jak mógłbym zrobić to tutaj?”.
Na co uważać: Nie myl aplikacji desktopowej z Codex CLI, który Dan odradza. Nie oczekuj magii bez kontekstu — model jest tylko tak dobry, jak informacje, które mu dasz o sobie i swojej pracy.
2.Zacznij od jednej prostej automatyzacji, nie od kopiowania cudzego setupu
Na czym polega: Rozbudowane systemy Dana i Grega powstawały stopniowo, od jednego rozwiązanego problemu. Próba zbudowania całej machiny naraz kończy się marnowaniem czasu na system, który nie działa.
Jak stosować: Wybierz jeden konkretny, powtarzalny problem, który cię irytuje (np. przeglądanie skrzynki), rozwiąż go, a dopiero potem dobuduj kolejne elementy. Trzy–cztery działające rzeczy w zupełności wystarczą.
Na co uważać: Pokusa „pracy nad systemem zamiast nad pracą” — jak dawniej z Notionem czy Roam. Nie rób z rzeczy pobocznej rzeczy głównej. Wchodź w narzędzie z ciekawości, nie z FOMO.
3.Zamień skrzynkę i inne źródła w feedy z kartami i „najlepszą kolejną akcją”
Na czym polega: Aplikacja Dana „Tend” codziennie przechodzi przez nieprzeczytane maile, robi z każdego kartę ze streszczeniem i gotowym szkicem odpowiedzi. Ten sam wzorzec działa na Slacku, notatkach ze spotkań itd.
Jak stosować: Możesz odtworzyć to, wrzucając ten film do Codeksa z poleceniem „zrób coś takiego”. Ustaw przypięte wątki dla różnych obszarów życia (firma, skrzynka, projekt), żeby każdy zbierał odpowiednie źródła.
Na co uważać: System uczy się twoich preferencji z czasem (co archiwizujesz, na co odpowiadasz) — na początku będzie mniej trafny. Zawsze przeglądaj szkice przed wysłaniem, choć 5.6 robi mniej ryzykownych błędów niż wcześniejsze modele.
4.Dobierz model do zadania: 5.6 do codziennej pracy, Claude/Fable do designu i najtrudniejszych bugów
Na czym polega: GPT 5.6 to według Dana „klasa A” — szybki, konkretny, dobry do pracy umysłowej i kodowania. Fable to „klasa S+” — potężniejszy, ale wolny, drogi i wymagający umiejętności. Do designu Dan wciąż woli modele Claude (Opus, Fable).
Jak stosować: Używaj 5.6 jako domyślnego konia roboczego. Do dopracowania wyglądu produktu przenoś pracę do Claude’a i portuj z powrotem. Fable rezerwuj na naprawdę duże problemy (ML, orkiestracja flot agentów).
Na co uważać: 5.6 nie opróżni backlogu błędów sam — nadal trzeba myśleć przy trudniejszych naprawach (Dan szacuje „60–70%” możliwości Fable). Nie przepłacaj Fable za zadania, których nie potrzebuje.
5.Wykorzystaj „goal” i pętle typu LFG do długich, autonomicznych zadań
Na czym polega: „Goal” pozwala dać modelowi wysokopoziomowy cel z weryfikowalnymi kryteriami, do którego dąży godzinami. LFG (z wtyczki compound engineering) zapętla cykl: planuj → wykonaj → przejrzyj → skompiluj wnioski → powtórz.
Jak stosować: Formułuj cel wraz z jasnymi, weryfikowalnymi kryteriami ukończenia. Uruchamiaj długie zadania (Dan miał takie po 20 godzin) i zajmuj się czymś innym.
Na co uważać: Łatwo uzależnić się od oglądania strumienia na żywo zamiast zajmować się swoją pracą. Bez dobrych kryteriów ukończenia model może „obchodzić” trudny problem — Dan sam przyznał, że przy „Turnaround” powinien był mocniej go docisnąć.
6.Podłącz Codeksa do adresu e-mail przez routery i heartbeaty
Na czym polega: „Mailroom” nadaje Codeksowi własny adres (przez format z plusem w Gmailu, np. dan+codex@…), a wątek-router co kilka minut sprawdza tę skrzynkę i kieruje wiadomości do właściwych miejsc.
Jak stosować: Utwórz alias z losowym ciągiem znaków, żeby nie dało się go łatwo odgadnąć. Rozdaj go zaufanym agentom/narzędziom (np. agentowi w Slacku), żeby zlecały zadania Codeksowi zamiast tobie — ty widzisz przebieg, ale nie musisz działać ręcznie.
Na co uważać: Adres z plusem jest przewidywalny bez losowego dopisku — bez niego ktoś mógłby go zasypać spamem. Router musi mieć jasne reguły, dokąd routować, żeby nie tworzyć bałaganu.
7.Buduj i kupuj oprogramowanie „agent-native”, ale nie porzucaj SaaS-u
Na czym polega: Największa wartość to software zaprojektowany do wspólnej pracy człowieka i agenta na jednej powierzchni (jak przeglądarka dla programistów), a nie tylko CLI do delegowania. Jednocześnie ludzie płacą za utrzymanie, więc gotowy SaaS wciąż wygrywa z wiecznym vibe-kodowaniem.
Jak stosować: Do rzeczy, których nie chcesz utrzymywać (CRM), wybieraj dostawców z CLI/integracją agentową. Jeśli budujesz produkt, celuj w kategorię codex-native i pozycjonuj się pod używanie wewnątrz Codeksa, zanim stanie się to głównym nurtem.
Na co uważać: Własny vibe-kodowany CRM „szybko robi się bałaganem”. Dystrybucja to otwarte pytanie — Dan spekuluje o przyszłych sklepach z aplikacjami OpenAI/Anthropic, ale to prognoza, nie pewnik.
8.Poznaj swój typ twórcy: pirat czy architekt — i dobierz sobie parę
Na czym polega: Pirat szybko dowozi do 70%, żeby sprawdzić wartość pomysłu. Architekt bierze uformowaną rzecz i zamienia ją w dopracowaną, dobrze działającą maszynę. Obie role są kluczowe, a „techniczny współzałożyciel” nie jest już potrzebny, skoro każdy potrafi kodować.
Jak stosować: Rozpoznaj, którym typem jesteś, i świadomie sparuj się z kimś o dopełniających cechach. Przejście od 70% do 100% to często po prostu polecenie „zrób pełną wersję V1” plus praca architekta.
Na co uważać: Sam prototyp na 70% wygląda gotowo, ale brakuje mu implementacji (u „Turnaround” — realnego podpięcia pod GitHub/Linear) i przemyślanego designu. Nie myl działającego demo z dowiezionym produktem.
9.Rozważ fine-tuning własnego modelu na swoich danych — nowa granica
Na czym polega: Gdy skill nie wystarcza, kolejnym krokiem jest fine-tuning modelu. 5.6 na tyle ułatwia budowę pipeline’u ML (dane, dane syntetyczne, eksperymenty), że mogą to robić także osoby bez wykształcenia w ML. Dan trenuje model do korekty tekstu na swoich danych z lat.
Jak stosować: Zidentyfikuj powtarzalne zadanie, w którym masz dużo własnych danych historycznych (np. dziesiątki tysięcy korekt), i zamień je w wytrenowany model — potencjalnie także jako produkt na sprzedaż.
Na co uważać: Fine-tuning wymaga modeli open source, bo główne firmy (OpenAI, Anthropic) właściwie już go nie oferują. To wciąż wschodzący obszar — modele bazowe nadal nie robią korekty na poziomie zawodowego korektora.
10.Przełącz nastawienie: zarządzasz systemem, który robi pracę, a nie robisz każdego zadania
Na czym polega: Kluczowa zmiana to przejście od „obsługuję ten mail” do „projektuję i zarządzam systemem, który obsługuje moją pocztę”. To ta sama zmiana, którą przechodzą menedżerowie i założyciele zatrudniający ludzi.
Jak stosować: Zapisz swoje SOP-y (standardowe procedury: „jeśli zdarzy się X, reaguj tak”) i włóż je do Codeksa/Claude Code, żeby wykonywał nudne, powtarzalne zadania na wysokim poziomie. Wypróbuj wtyczkę „record and replay”, która nagra twoje działanie i zamieni je w skilla.
Na co uważać: Ta zmiana nastawienia to osobna umiejętność ery AI i dotyczy tylko części pracy — nie wszystkiego. Funkcje typu Chronicle (lokalne zrzuty ekranu dla kontekstu) niektórzy uznają za niepokojące; są opcjonalne (research preview) i można je wyłączyć.