O czym jest ten film
- Jak delegować na agenta długotrwałe, wielogodzinne zadania programistyczne, które wykonuje samodzielnie przez całą noc.
- Teza przewodnia: wyniki zależą od jasnych, weryfikowalnych kryteriów, po których agent sam potwierdzi spełnienie warunków celu.
- Przykład: konwersja pakietu ekonometrycznego (diff-in-diff z imputacją) z Pythona i Staty na R.
- Metoda: istniejące wersje w Pythonie i Stata służą za specyfikację zachowań, które pakiet R musi odwzorować.
- Przygotowanie: klonowanie repozytoriów referencyjnych i środowisko testowe — Stata na zdalnej maszynie, R lokalnie, Python w wirtualnym środowisku.
- Przed startem celu autor wyczerpująco wypisuje wszystko, co trzeba zweryfikować pod kątem zgodności wyników.
- „Oracle review”: zanim cel ruszy, plan trafia do recenzji w ChatGPT Pro, która szuka m.in. luk pozwalających testom fałszywie przejść.
- Cały proces żyje w gicie: pull requesty, recenzje wykonywane przez Claude Code, każdy nowy cel na osobnej gałęzi.
- Nocny przebieg trwał 14 godzin 41 minut, po czym agent sam zaproponował kolejny cel „utwardzający” pakiet.
- Na końcu porządki (czyste repozytorium bez skryptów lokalnych) i decyzje wydawnicze: paczka pod CRAN, ale z testami parzystości tylko na GitHubie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Bez policzalnych warunków sukcesu cel to loteria
Na czym polega: Agent wykonuje długotrwałe zadanie bez twojego nadzoru, więc musi mieć możliwość samodzielnego stwierdzenia „zrobione”. Warunkiem jest cel zapisany jako zestaw konkretnych, sprawdzalnych kryteriów, a nie jako ogólnikowe polecenie.
Jak stosować: Zanim wystartujesz cel, zadaj sobie pytanie: po czym agent bez mojego udziału pozna, że warunki są spełnione? Każde kryterium zapisz tak, żeby dało się je potwierdzić testem, pomiarem albo porównaniem z referencją.
Na co uważać: Kryteria typu „pakiet ma być dobrej jakości” albo „działa poprawnie” nie są weryfikowalne — agent uzna je za spełnione zbyt szybko i zakończy pracę przedwcześnie.
2.Istniejące implementacje to gotowa specyfikacja
Na czym polega: Zachowanie wymagane od nowego kodu najlepiej wywieść z czegoś, co już działa. W demo pakiety w Pythonie i Stata jednoznacznie definiowały, jak pakiet R ma się zachowywać — włącznie z wynikami liczbowymi.
Jak stosować: Jeśli zadanie ma swojego „wzorca” (inna implementacja, starsza wersja, konkurencyjne narzędzie), sklonuj go lokalnie i potraktuj jako materiał odniesienia. Formułuj kryteria celu bezpośrednio z jego zachowań.
Na co uważać: Referencja musi być kanoniczna i aktualna. Warto sprawdzić, kto jest autorem wzorca i czy nie istnieją rozbieżne wersje — w filmie okazało się, że kwestia autorstwa pakietu wymagała doprecyzowania.
3.Środowisko testowe buduj przed startem celu, nie w jego trakcie
Na czym polega: Weryfikacja wymaga narzędzi, które nie zawsze są pod ręką — w demo Stata stała na zdalnej maszynie z wieczystą licencją, R lokalnie, a Python w osobnym środowisku wirtualnym. Wszystko to zostało przygotowane, zanim ruszył nocny bieg.
Jak stosować: Zrób listę wszystkich zależności potrzebnych do testów i dopilnuj ich instalacji na etapie planowania. Dopiero wtedy wystawiaj cel, żeby agent nie utknął w pół nocy na brakującym pakiecie.
Na co uważać: Licencje bywają powiązane z konkretną maszyną (jak ta Stata), więc testy muszą być zaprojektowane tak, żeby dało się je odpalić w takim, a nie innym układzie sprzętowo-licencyjnym.
4.Wypisz wyczerpująco wszystko, co podlega weryfikacji
Na czym polega: Przed sformułowaniem celu autor przeprowadza osobny przebieg badawczy: przeczytanie wątków, sklonowanie repozytoriów, a następnie stworzenie pełnej listy zgodności (parzystości), jaką nowy pakiet musi osiągnąć.
Jak stosować: Traktuj tę listę jak kontrakt między tobą a agentem — to ona staje się treścią instrukcji celu. Im pełniejsza, tym mniej miejsca na dowolną interpretację po drugiej stronie.
Na co uważać: Ten etap łatwo skrócić pod presją czasu, a to najgorsze oszczędności — luki w liście objawią się dopiero po wielu godzinach pracy agenta, gdy poprawki będą najdroższe.
5.Plan poddaj recenzji mocniejszego modelu — „wyroczni”
Na czym polega: Zanim cel zostanie uaktywniony, autor wysyła całą dokumentację planistyczną do ChatGPT Pro (nazywa to „oracle review”), prosząc o audyt kontraktów akceptacyjnych.
Jak stosować: Osobny, mocniejszy model w roli recenzenta to tani sposób wyłapania ślepych plamek własnego planu. Proś wprost o krytykę konkretnych elementów: warunków akceptacji, dowodów, aspektów licencyjnych i wydajnościowych.
Na co uważać: Recenzja potrafi być przytłaczająco długa. Warto każdorazowo decydować, które uwagi włączyć do celu — a nie wklejać wszystkiego bez wyboru.
6.Poluj na „fałszywe zielone” w testach
Na czym polega: W recenzji planu autor każe wyroczni zacząć od luk, przez które test może zostać zaliczony, mimo że kod jest zły — dopiero potem sprawdzać braki w dowodach oraz kwestie licencji i wydajności.
Jak stosować: Przy każdym kryterium zapytaj: jak ten warunek mógłby zostać spełniony pozornie? Pomyśl o testach, które sprawdzają za mało, są zbyt pobłażliwe albo dają się obejść.
Na co uważać: Test, który nigdy nie potrafi paść, jest bezwartościowy — zielony wynik nabiera znaczenia dopiero wtedy, gdy wiemy, że czerwony byłby możliwy.
7.Cały proces trzymaj w gicie
Na czym polega: Praca przed celem i same cele lądują w repozytorium: pull requesty, recenzje wykonywane przez Claude Code jako druga para oczu, scalanie zmian i każdy kolejny cel na osobnej gałęzi.
Jak stosować: Nawet gdy „tylko” układasz instrukcje dla agenta, rób to przez PR z recenzją. Reviewerem może być inny agent — to tani, powtarzalny mechanizm kontroli własnej roboty.
Na co uważać: Recenzja maszynowa nie zastępuje twojej decyzji — to ty wybierasz, co scalasz i czy sugestie recenzenta w ogóle trafiają do celu.
8.Pozwól celowi pracować długo i przyjmuj jego propozycje kolejnych kroków
Na czym polega: Nocny bieg trwał 14 godzin 41 minut, a na końcu agent sam zaproponował dodatkowy cel: utwardzenie pakietu po osiągnięciu gotowości wydaniowej (tzw. hardening po kandydacie do wydania).
Jak stosować: Przy dobrze zdefiniowanym celu nie przerywaj pracy po pierwszych rezultatach — daj agentowi długi budżet i rozważ wykonanie jego własnych sugestii następnych kroków jako odrębnego celu.
Na co uważać: Długi bieg zużywa limity usługi. Warto znać swój budżet i resety — autor świadomie wykorzystywał kończące się reset zanim przepadły.
9.Po agencie sprzątasz samodzielnie: czyste repozytorium
Na czym polega: Repo robocze zawierało skrypty osobiste (np. do sprawdzania Staty na dedykowanym serwerze), których nie wolno publikować. Autor zleca zbudowanie czystego pakietu R bez tego balastu, a stare repo kasuje.
Jak stosować: Oddziel środowisko robocze od artefaktu publicznego. Publikuj wyłącznie to, co ma zobaczyć świat — z dokumentacją dopasowaną do konwencji danego ekosystemu, a nie do twoich prywatnych notatek.
Na co uważać: Sprawdzaj różnice między wersją roboczą a publikowaną; automatyczne czyszczenie może przypadkiem wyrzucić coś istotnego albo zostawić coś wrażliwego.
10.Decyzje wydawnicze podejmuj sam — z feedbackiem społeczności przed formalnym wydaniem
Na czym polega: Agent dopytywał o szczegóły publikacji: czy pakiet ma być zgodny z CRAN, co zrobić z testami parzystości, których standard pakietów R nie przewiduje. Autor zdecydował: fixtury zostają na GitHubie, ale nie wchodzą do paczki wysyłanej na CRAN; samo zgłoszenie na CRAN wstrzymał do czasu reakcji ludzi z X.
Jak stosować: Traktuj pytania agenta jako checklistę decyzji, które i tak musisz podjąć — i odpowiadaj na nie świadomie. Przy publikacji do wymagającego repozytorium warto najpierw zdobyć opinię społeczności.
Na co uważać: Zgodność z wymogami CRAN to dodatkowa praca (struktura, dokumentacja, zawartość paczki) — trzeba ją zaplanować, a nie dokleić na końcu.
Redakcyjne tłumaczenie
Zanim wystartujesz cel: policzalne warunki sukcesu
Jak użyć celu w Codex albo Claude Code, żeby agent napisał dla ciebie użyteczne oprogramowanie w długim, samodzielnym procesie trwającym całą noc? Pokażę mój dokładny sposób robienia tego. Klucz do dobrych wyników: stworzyć jasne, weryfikowalne kryteria, po których Claude Code lub Codex będzie w stanie sam potwierdzić, że spełnił warunki celu.
(Informacja dodatkowa: „cel”, ang. goal, to funkcja zlecania agentowi długotrwałego zadania, które wykonuje on samodzielnie przez wiele godzin, bez bieżącego nadzoru użytkownika.)
Mój pokaz zrobię na przykładzie konwersji pakietu ekonometryczno-statystycznego, który już częściowo istnieje w dwóch językach — Pythonie i Stata — na trzeci, bardzo popularny w ekonometrii i statystyce: R. Pakiety w Pythonie i Stata precyzyjnie określają, jak wersja w R ma się zachowywać. Dlatego duża część mojej pracy wstępnej to ułożenie kryteriów, które cel dla Codex musi spełnić — na podstawie zachowań istniejących wersji. Sądzę, że oglądanie tego procesu przyda wam się niezależnie od kontekstu, w którym będziecie używać celów: chodzi o samo rzemiosło budowania kryteriów weryfikacji, które przekłada się na lepsze rezultaty. Zaczynajmy.
Punkt wyjścia: prośba ekonometryka z Berkeley
Kirill, ekonomista z Berkeley, wydał nowy pakiet w Pythonie do diff-in-diff metodą imputacji — o składni podobnej do poleceń did_imputation i wykresów zdarzeniowych w Stata. I dopisał prośbę: „Jeśli ktoś chciałby przenieść to do R — dajcie znać. Byłby to świetny publiczny użytek”.
(Informacja dodatkowa: Kirill pochodzi z wydziału ekonomiki rolnictwa i zasobów UC Berkeley; „diff-in-diff” — różnica różnic — to standardowa metoda oceny efektów interwencji w ekonomii, a wariant z imputacją polega na odtwarzaniu nieobserwowanych wyników jednostek objętych oddziaływaniem.)
Moja pierwsza intuicja — mam nadzieję, że również wszystkich, którzy znają moje materiały — była taka, że to klasyczne zadanie do oddelegowania Codexowi. Okazało się, że dokładnie to samo zapytał Jonathan. Kirill: „Niestety, nie mam na to ani czasu, ani dużego grantu, żeby kogoś zatrudnić”. Jiang dorzucił: „Czy nie istnieje już pakiet w R autorstwa Kyle’a Buttsa?” Kirill: „Tak, ale bardzo podstawowy”.
Uznałem, że sprawa jest prosta — coś, co powinno udać się niemal jednym strzałem w Codex. Pokażę, jak bym się za to zabrał.
Pierwsze ruchy w Codexie: projekt i referencje
Otwieram Codex, nowy czat, nowy projekt na istniejącym folderze. Pierwsze polecenie: interesuje mnie konwersja tego pakietu na R — niech agent przeczyta cały wątek na X (mam do tego osobny skill), łącznie z wzmianką Jiang o pakiecie K. Buttsa i odpowiedzią Kirilla, że istniejący pakiet jest „podstawowy”.
Od razu dobra praktyka: sklonuj lokalnie oba repozytoria — i Kyle’a Buttsa, i Kirilla — jako materiał odniesienia, choćby w katalogu tymczasowym. Docelowo ma powstać kompletny, w pełni zweryfikowany pakiet R. Ale bez gonienia konia: najpierw klonujemy oba repo i robimy bardzo szczegółowe studium, potem wyczerpująco wypisujemy wszystko, co trzeba zweryfikować — i dopiero wtedy ruszamy z celem.
Agent odbył przebieg badawczy: przeczytał wątki, zapisał artefakty, sklonował wersje w Pythonie, R i Stata. Po drodze doprecyzowała się jedna rzecz: pakiet R nie jest autorstwa samego Kirilla albo powstaje we wspólnym projekcie.
Warsztat testowy: Stata zdalnie, R lokalnie, Python w wirtualnym środowisku
Chcę przygotować wszystko tak, żeby efekt dało się w pełnietestować — to przecież sedno całej metody. Bez możliwości weryfikacji cel traci sens.
Zakładam wstępne repozytorium gita. Upewniam się, że wszystkie zależności potrzebne do Staty są dostępne na maszynie, na której będziemy sprawdzać wyniki, i że jest wszystko, czego trzeba w Pythonie; do testów względem pakietu Kyle’a Buttsa przyda się też R.
Efekt: Stata stoi na zdalnej maszynie, na której mam wieczystą licencję Stata 14, R jest zainstalowany lokalnie, a Python pracuje w osobnym środowisku wirtualnym. Po co ten cały parking narzędzi? Chcę używać pozostałych pakietów jako wyroczni zachowań: sprawdzać wyniki względem pakietu Stata Kirilla i wskazanego przez niego pakietu w Pythonie.
Lista wszystkiego, co trzeba zweryfikować
Kolejny krok to najważniejsze ćwiczenie przed wystawieniem celu: wyczerpująco wypisać wszystko, co będziemy chcieli zweryfikować pod kątem zgodności wyników. Chodzi o to, żeby na końcu powstały dobre instrukcje — takie, które przekażemy celowi. Wszystkie zachowania, wszystkie równoważności — żeby mieć najpełniejszy, najpiękniejszy, najwspanialszy pakiet R na świecie. Najlepszy pakiet R w historii. — Przepraszam, nadarzyła się okazja do parodii Trumpa.
Zakładam nowy, prywatny repozytorium gita dla tego przedsięwzięcia.
Wyrocznia: recenzja planu w ChatGPT Pro
Zanim uaktywnię cel, chcę dostać recenzję od „wyroczni”. Oracle review to moje skrótowe określenie jednej rzeczy: wysłania planu do GPT Pro. (Informacja dodatkowa: mowa o płatnym wariancie ChatGPT z rozbudowanym trybem rozumowania, przeznaczonym m.in. do długich zadań analitycznych.) Mechanizm sam składa prompt z pełnym kontekstem tego, co próbujemy zbudować w R, i wysyła go do ChatGPT Pro. Proszę wyrocznię, żeby potraktowała dokumentację jak kontrakty akceptacyjne i zaczęła od luk, przez które test może zostać zaliczony fałszywie, a potem sprawdziła braki w dowodach oraz skrypty licencyjne i wydajnościowe.
Sam prompt brzmi mniej więcej tak: „Zrecenzuj to repozytorium planistyczne, zanim aktywujemy cel wdrożeniowy. Chcemy zbudować kompletny, wysokiej jakości pakiet R — z pełną zgodnością względem kanonicznej wersji w Stata”. W repozytorium jest już sporo kodu, jego opisów i pomysłów na elementy do zweryfikowania. GPT Pro powinno wnieść dobre uwagi — zobaczmy.
Recenzja przyszła i jest bardzo dobra. Pytam agenta, czy rozumie, jak zmodyfikować cel względem sugestii wyroczni. Rozumie — choć efekt wygląda na potwornie długi. Cóż, czuję się czasem jak małpa wklejająca fragmenty, ale robię to.
Gałęzie, pull requesty i druga para oczu od Claude’a
Mamy więc pewien zasób pracy przed celem: zamrożone kontrakty akceptacyjne, gotową treść celu. Zanim go wystartuję, otwieram pull requesta dla tej gałęzi, każę Claude Code zrecenzować PR, scalam zmiany — i dopiero nowy cel wystawiam na świeżej gałęzi. Lubię w ten sposób sprawdzać własną robotę.
Na nowej gałęzi mamy już cały zestaw wymaganych równoważności i warunków testowych do spełnienia. Włączamy tryb żywiołu, ustawiamy wysiłek na maksimum — i patrzymy, co z tego wyjdzie.
Nocny bieg: 14 godzin i 41 minut
Jest następny dzień. Zadanie pracowało przez całą noc — 14 godzin 41 minut — a na koniec samo zaproponowało kolejny krok: osobny cel do „utwardzenia” pakietu R po osiągnięciu gotowości wydaniowej. Wygląda na zakończone.
Utwardzenie i porządki
Została ostatnia rzecz: czysty pakiet R. W repo roboczym zostały rzeczy takie jak moje skrypty do sprawdzania Staty na serwerze dedykowanym — tego nie chcę publikować. Zlecę zbudowanie czystego repozytorium, a stare skasujemy. A ocenę, jak dobry jest efekt, zostawiam wam, znacznie lepszym ode mnie ekonometrykom.
Włączam Claude Code — lubię używać go do takich porządków — i wybieram opcję pierwszy. Chodzi o to, żeby na podstawie obecnego repozytorium powstał właściwy pakiet R. Obecny plik README to raczej wyczerpująca — i bardzo osobista — analiza warunków gotowości do wydania oraz opis referencji, a nie typowa dokumentacja pakietu. Teraz chcę z tego zrobić regularny pakiet R.
Czysty pakiet R i decyzje o CRAN
To ciekawy eksperyment. Prawdopodobnie istnieje szansa, żeby po prostu ujednolicić pakiety ekonometryczne: wystarczy ułożyć odpowiednią pętlę i pozwolić jej działać w nieskończoność.
(Informacja dodatkowa: CRAN to oficjalne, wymagające technicznie repozytorium pakietów języka R — publikacja wiąże się z szeregiem norm dotyczących struktury, dokumentacji i zawartości paczki.)
Sprawdzam budżet: zostało mi 64 procent limitu do 24. dnia, ale — co ważniejsze — dwa resety. Chciałbym je wykorzystać, zanim przepadną.
Agent pyta, czy pakiet ma być zgodny z CRAN. A czemu nie? Ile dodatkowej pracy to wymaga? Brzmi rozsownie — skłaniałbym się ku opcji trzeciej… jednak wybieram pierwszą. Kolejne pytanie dotyczy testów parzystości z Pythonem i Statą, które powstały w pakiecie: standard pakietów R nie przewiduje takich testów i plików pomocniczych w tej postaci. Decyzja: fixtury zostają na GitHubie, ale nie wchodzą do paczki tarball wysyłanej na CRAN. Brzmi dobrze.
Burza mózgów zakończona. Czas na plan — do planowania lubię używać pakietu Compound Engineering, a przez Claude Code działa ono u mnie znacznie lepiej, więc po prostu zlecam to Claude’owi. Plan utworzenia nowego repozytorium gotowy — realizujemy. Otwieram nowy cel do wykonania planu.
Publikacja i co dalej
Gotowe. Co teraz? Możemy wypchnąć efekt do publicznego repozytorium GitHub — i co dalej w stronę CRAN? Podsumowując ten etap: zadanie uruchomiło wszystkie wcześniejsze testy i posprzątało po sobie, więc nic specyficznego dla mojego komputera nie trafiło do wersji publicznej. Publikujemy. Przed samym CRAN agent proponuje jeszcze jeden skupiony przebieg utwardzający — listę rzeczy do naprawienia, zanim paczka trafi pod recenzyjny młyn. Zgadzam się na całość, ale zgłoszenia na CRAN nie robię teraz. Wolałbym najpierw poznać zdanie ludzi z X.
I to koniec. Oto wynik: pliki dokumentacji i pomocy w R oraz komplet testów i kryteriów weryfikacji. Wrzucam to do sieci. Był to ciekawy mały projekt — zobaczymy teraz, jak sprawdza się w praktyce.