Jak zdjąć z Claude wszelkie limity

O czym jest ten film

Theo otwarcie przyznaje, że Claude Opus 5.5 wciągnął go w tryb „pieca tokenowego”: projekty, w których jedna wiadomość uruchamia agentów na tygodnie i pali setki dolarów.
Trzy sztandarowe wyczyny: TS Rust (TypeScript przepisany w Ruście, 4–10× szybszy), Lust (kompilator podzbioru Rusta ok. 100× szybszy niż cargo) i Skate 3 Bench — kompletna gra o skateboardingu zbudowana przez Claude od zera.
Sam Skate 3 Bench kosztował równowartość blisko 5 tys. dolarów inferencji, ponad 12 mld tokenów i tylko 25 promptów Theo — z czego większość to słowo „kontynuuj”.
Sedno metody: zadanie musi przypominać to, na czym modele są trenowane (RLVR) — mieć jasny, sprawdzalny warunek sukcesu i porażki. Wtedy model potrafi „wspinać się” po zadaniu godzinami.
Gdy nie da się weryfikować testami, działa panel sędziów LLM porównujących zrzuty ekranu z oryginałem — słaba, ale wystarczająca miara, by pętla kręciła się cztery dni.
Recepta w krokach: żmudny cel → weryfikacja bez człowieka w pętli → narzędzia i moc obliczeniowa → pytanie agentów, co je blokuje. Kroki trzeci i czwarty to pętla, nie jednorazowa konfiguracja.
Ekonomia: równowartość ok. 40 tys. dolarów użycia API przy TS Rust wyszła za 500–800 dolarów abonamentów Claude (200 dol./mies.) — abonamenty są mocno subsydiowane.
Prawdziwym wąskim gardłem nie są tokeny, tylko moc obliczeniowa: odciążenie buildów skróciło kolejkę z 12 godzin do 1,2, a sandboxy na żądanie (Boat) zbiły czas weryfikacji zmiany z 70 minut do 6.
Wąskie gardło samo może stać się projektem — tak narodził się Lust (17 minut kompilacji → 12 sekund), który istnieje wyłącznie po to, by odblokować TS Rust.
Theo wprost odradza powtarzanie tych wyczynów: to materiał „do oglądania chaosu”, a jego efektem ubocznym jest to, że zamiast budować aplikacje, buduje kompilatory i system operacyjny.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Cel, który da się sprawdzić maszynowo, jest paliwem długiego biegu

Na czym polega: Modele trenuje się na zadaniach z weryfikowalną nagrodą — sukces albo porażkę trzeba dało się stwierdzić programowo. Im bardziej Twoje polecenie przypomina ten format, tym dłużej i pewniej agent pracuje. TS Rust zaczął działać w dzień, bo dostał twardy warunek: identyczne wyniki kompilacji na zestawie prawdziwych projektów.

Jak stosować: Zanim odpalisz agenta, zapisz w formie testu, co znaczy „gotowe”: identyczny output, zielone testy, konkretna lista błędów. Dopiero potem dokładaj cele kolejne („teraz 2× szybciej i wszystkie testy dalej przechodzą”).

Na co uważać: Weryfikowalny, ale nietrafiony cel prowadzi do optymalizacji pod miernik, nie pod intencję — Theo podejrzewa, że model wydał 800 dolarów tokenów, wyłącznie dopracowując niebo w grze.

2.Żmudność to atut, nie wada

Na czym polega: Inżynierowie omijają żmudne prace — i to czyni nas skutecznymi. Agentowi jest wszystko jedno. Przepisanie kodu o ponad 100 tys. plików na Rust to męka dla człowieka i idealny materiał na wielodniową pętlę agentową.

Jak stosować: Wybieraj zadania, których nie chcesz robić ręcznie ze względu na skalę i monotonię (porty, migracje, generowanie zasobów), i celowo zostawiaj je w „żmudnej” postaci — dają agentowi setki małych, sprawdzalnych kroków.

Na co uważać: Żmudność bez weryfikacji to tygodnie spalonego budżetu. Każdy etap musi mieć własny warunek zaliczenia.

3.Weryfikacja nie może wymagać człowieka w pętli

Na czym polega: Jeśli sukces musi potwierdzić człowiek, cała maszyna zwalnia do tempa Twojej dostępności. TS Rust wygenerował ok. 1800 rewizji i 7 884 commity — przy ręcznej ocenie niemożliwe.

Jak stosować: Buduj automatyczny werdykt pass/fail (testy, porównanie wyjść, diff). W ostateczności — drugi agent oglądający wyniki i wydający opinię.

Na co uważać: Automatyczny sędzia musi być zgodny z Twoim celem. Inaczej agent zaliczy warunki formalne, a efekt będzie bezużyteczny.

4.Gdy brak testów — sędziowie LLM jako miara jakości

Na czym polega: Dla grafiki i gier nie ma testów jednostkowych, więc Theo kazał modelowi robić zrzuty ekranu w określonych stanach, porównywać je z materiałem z oryginału i poddawać ocenie panelu LLM-ów z konkretnym feedbackiem. Wystarczyło jako „coś, co da się sprawdzić”, by iteracja trwała cztery dni.

Jak stosować: Zamień jakościowy cel na porównywalny artefakt (zrzut, nagranie, wygenerowany plik) i dodaj sędziego oceniającego pod jawnymi kryteriami. Model sam potrafi organizować sobie tę pętlę.

Na co uważać: Sam Theo mówi wprost, że ta metoda „nie jest nawet w porządku”. Sędzia łatwo zadowala się powierzchnią — ładniejszym niebem, jaśniejszym obrazem — zamiast sedna rozgrywki.

5.Płać abonamentem, nie przez API

Na czym polega: Subskrypcje Claude (200 dol. miesięcznie) są mocno subsydiowane — Theo szacuje kilkunastokrotną różnicę. Port o równowartości ok. 40 tys. dolarów API wyszedł mu za 500–800 dolarów abonamentów.

Jak stosować: Jeśli planujesz wielotygodniowe pętle, liczony koszt przeliczaj na abonamenty i świadomie wykorzystuj je w całości; API zostaw do zastosowań produkcyjnych.

Na co uważać: To ekonomia na granicy regulaminu — Theo pali sześć–siedem kont naraz i przewiduje konsekwencje. Do tego dochodzą koszty poza tokenami (u niego ponad 2 tys. dol. na Blacksmith i kolejne na Boat), więc „tani” projekt robi się poważnym rachunkiem.

6.Wąskim gardłem jest moc obliczeniowa, nie tokeny

Na czym polega: Agent czekający do 12 godzin w kolejce na kompilację nie robi postępu, choćby model był genialny. Po przeniesieniu buildów do chmury czas oczekiwania spadł do 1,2 godziny i kod zaczął lądować lawinowo.

Jak stosować: Mierz czas, który agent spędza czekając na zasoby, i traktuj go jako priorytetowy wskaźnik. Szybka, przewidywalna weryfikacja zmiany to fundament długich pętli.

Na co uważać: Same dodatkowe maszyny nie wystarczą, jeśli pojedyncze zadanie trwa 20–40 minut. Potem atakujesz długość samej weryfikacji — u Theo doprowadziło to do budowy własnego kompilatora.

7.Maszyny efemeryczne zamiast stałego parku sprzętu

Na czym polega: Sandboxy stawiane na żądanie (Boat) skróciły czas pełnej weryfikacji zmiany z 40–70 minut do 353 sekund, a dzienną przepustowość podniosły blisko trzykrotnie. Zasada: nie kupuj mocy pod szczytowy zapotrzebowanie, jeśli da się falować.

Jak stosować: Daj agentom proste komendy „postaw maszynę / wejdź / skasuj” oraz snapshoty gotowych środowisk — repozytorium buduje się raz, a każdy kolejny agent startuje od gotowej kopii.

Na co uważać: Sandboxy nie zastępują serwerów produkcyjnych ani GPU. Sprawdź limity równoległości i startów, zanim włączysz takie narzędzie w codzienną pętlę.

8.Pytaj agentów, co je blokuje

Na czym polega: W TS Rust agent sam zbudował kolejkę kompilacji, żeby maszyna nie umierała od nadmiaru równoległych zadań. Na pytanie o problemy odpowiedział: „potrzebuję więcej mocy” — i to była prawda.

Jak stosować: Prowadź obok głównego wątku osobny „kontrolny”, który czyta historię i raportuje wąskie gardła. Decyzje — dodanie maszyn, zmiana procesu — podejmujesz Ty.

Na co uważać: Agent raportuje objawy z własnej perspektywy. Zweryfikuj to w danych (czasy kolejek, logi), zanim kupisz sprzęt.

9.To pętla menedżerska, nie jednorazowa konfiguracja

Na czym polega: Kroki „dostarcz narzędzia” i „zapytaj o blokady” wracają w kółko. Skutek uboczny: im lepiej dopracowane środowisko, tym szybciej palą się abonamenty — u Theo z 1–2 tygodniowo do wszystkich naraz.

Jak stosować: Po każdym istotnym postępie wracaj do pytania o blokady i uaktualniaj otoczenie agenta. Rolą człowieka jest stawianie warunków do sukcesu, nie recenzowanie każdej linii kodu.

Na co uważać: Praca „menedżera agentów” potrafi pochłonąć cały Twój czas. Theo opisuje to wprost jako piekło, które każe mu budować kompilatory zamiast aplikacji.

10.Wąskie gardło może stać się następnym projektem

Na czym polega: Cierpienie na wolny kompilator Rusta zrodziło Lust — zamiennik cargo celujący w 100× szybsze buildy (17 minut → 12 sekund) przy twardej barierze: wynikowa binarka może być najwyżej o 20% wolniejsza.

Jak stosować: Gdy coś systematycznie hamuje Twoje pętle, rozpisz to jako osobne, weryfikowalne zadanie. Problemy infrastrukturalne często dają się „wspinać” łatwiej niż problemy produktowe.

Na co uważać: Narzędzia zbudowane pod jedno wąskie gardło rzadko się uogólniają — Theo sam przyznaje, że Lust ledwo działa nawet dla TS Rust.

Redakcyjne tłumaczenie

Zwrot akcji, który mnie zmiótł

Jeśli nie wywnioskowaliście tego po chaosie na mojej głowie, fatalnym rytmie snu i wszystkich szalonych rzeczach, które ostatnio buduję — to najnowszy zwrot akcji dopadł mnie znienacka i po prostu zmiótł. Opus 5.5 to dziwna mieszanka możliwości, skupienia i ceny: coś, co okazało się dla mnie zbyt przyjemne, na granicy uzależniającego. Z natury starałem się, żeby porady na tym kanale dotyczyły świata rzeczywistych, praktycznych spraw, a nie wariactw w stylu „pieca na tokeny” — bo, szczerze mówiąc, to wciąż większość tego, co robię. Ale nie całość. I tym razem chcę sobie pozwolić na odrobinę szaleństwa.

Ten film weźmie wszystko, co mówiłem w odcinku o maksymalizacji tokenów, i pójdzie o krok dalej. To nie będzie materiał z praktycznymi radami, jak wycisnąć z Claude jak najwięcej. Wręcz przeciwnie.

Trzy projekty, które nie powinny działać

Wszystkie moje dotychczasowe porady dotyczyły realnych projektów — takich jak T3 Code czy T3 OS. (Tak, wiem, robienie systemu operacyjnego brzmi jak obłęd, ale obiecuję: kiedy to ujrzy światło dzienne, wszystko zaskoczy.) W tych projektach średni koszt pojedynczego polecenia to okolice ośmiu dolarów albo mniej, czasem nawet dwa dolce. Dziś mówię o zupełnie innej lidze: o projektach, w których każda wysłana wiadomość podpala setki dolarów. Które po mojej wiadomości nie działają godzinę — działają tygodniami. Które kosztowały mnie więcej mocy obliczeniowej niż tokenów, przy czym obie kwoty są kompletnie absurdalne. Które stają się viralem na Twitterze i psują mi życie, a czasem — bardzo rzadko, ale jednak — wychodzi z nich coś faktycznie użytecznego.

Prawdopodobnie słyszeliście o TS Rust: przepisałem TypeScript w Ruście, żeby kompilacja i budowanie były od czterech do dziesięciu razy szybsze, zależnie od zastosowania. Czego mogliście jeszcze nie znać, to Lust — mój nowy kompilator Rusta, wtykowy zamiennik cargo, który buduje podzbiór języka sto razy szybciej albo i więcej.

Ten film jest o projektach, które nie powinny działać, a jakoś działają. A przede wszystkim — o strategiach, dzięki którym pozwalam Claude biec w nieskończoność w nadziei, że dowiezie coś, co jeszcze kilka tygodni temu wydawało się niemożliwe. Bo to właśnie było niemożliwe.

Nie róbcie tego w domu

Od razu zaznaczę: to nie jest instrukcja do powielania moich workflowów, bo moim zdaniem nikt nie powinien tego robić — łącznie ze mną. Chodzi o pokazanie potwornych rzeczy, którymi opróżniam moje siedem kont Claude. (Wiem, że na ekranie widać sześć — jedno akurat pożyczam Juliusowi. Zaraz zrozumiecie dlaczego.) Nagrywam to głównie z frustracji: te rzeczy nie powinny działać, a działają — i po prostu muszę się wyżalić. Jeśli jesteś poważnym programistą szukającym poważnych rad, to nie ten materiał.

Sekcja sponsorowana: Browserbase

Zanim ruszymy, jedna uwaga. Może zauważyliście, że osobiste agenty radzą sobie ostatnio wyraźnie lepiej. Mam na to mocną tezę: to nie zasługa tańszych ani inteligentniejszych modeli, tylko narzędzi, do których agenci mają dostęp. Okazuje się, że gdy dasz wystarczająco rozgarniętemu modelowi porządne narzędzia — choćby do przeglądania sieci i podejmowania decyzji w imieniu użytkownika — wiedza modelu zaczyna mieć mniejsze znaczenie niż umiejętność posługiwania się tymi narzędziami. A więc agenci powinni mieć dobry dostęp do internetu.

Tu wchodzi Browserbase. To rozwiązanie, dzięki któremu wasi agenci dostają cały web: wyszukiwanie danych, pobieranie stron niedostępnych po zwykłym zapytaniu — w formatach, które model potrafi wykorzystać: HTML, JSON, a nawet Markdown — oraz nawigowanie po prawdziwych stronach. Możecie pomyśleć: „Theo, ja sam umiem postawić Puppeteera”. Ja też kiedyś to robiłem, często. Przestałem, bo problemów było za dużo: źle dobrane moce robiące z tych maszyn złoto, limity adresów IP, przez których strony po prostu się nie ładowały, dziwne bugi, na które natrafiali agenci. Browserbase załatwia też wszystkie denerwujące zakamarki: captche, wysyłanie i pobieranie plików, formularze i API, których nie obsłużysz przez curl. Agenci działają znacznie lepiej, gdy mają dostęp do sieci taki jak ty i ja. Dajcie im go: soyv.link/browserbase.

Skate 3 Bench: gra stworzona od zera za pięć tysięcy dolarów

Projekty, o których mówię, przegotowały Claude łącznie prawie cztery tysiące godzin na wszystkich moich agentach. Chcę wytłumaczyć, dlaczego, jak i co z tego wyszło. I zacznę od miejsca, którego się nie spodziewacie: nie od TS Rust, nie od Lusta, od Skate 3 Bench.

(Informacja dodatkowa: skate. i Skate 3 to gry EA o skateboardingu; znakiem rozpoznawczym serii jest sterowanie trików prawą gałką analogową zamiast przycisków — tzw. flick-it.)

Może to mylące, bo skatebench już znacie: prosty benchmark, w którym opisuję trik na deskorolce i sprawdzam, czy model potrafi go nazwać. Mam dwie wersje: oryginalną, na której większość modeli osiągnęła sufit, oraz tzw. prywatną — w praktyce wersję drugą, z zadaniami, które nigdy nie były publiczne. Bo tak, naprawdę to wychwyciłem: niektóre laboratoria używały mojego benchmarku jako danych treningowych, zdobywały komplet punktów na pytaniach, które w nim były, i odpadały na wszystkich pozostałych. Musiałem więc benchmark zamknąć, żeby modele nie mogły „kuć” go podczas treningu. Chciałem jednak pójść dalej i stworzyć coś innego — zwłaszcza że Gemini 4 Argan, choć to raczej model-pokazówka, zdobył maksimum na mojej prywatnej wersji. Uznałem, że czas na coś zupełnie nowego.

To jest Skate 3 Bench. Wątek, w którym to wystartowało, kręcił się cztery dni praktycznie bez mojego udziału. Ale co to właściwie jest? Co zrobiłem ze skateboardami, że zajęło to ponad cztery dni i pochłonęło tysiące dolarów na inferencji? Według moich rachunków sam koszt inferencji to blisko pięć tysięcy dolarów. Ponad dwanaście miliardów tokenów. I tylko dwadzieścia pięć moich poleceń — z czego większość, nawiasem mówiąc, to słowo „kontynuuj”, kiedy trzeba było zrestartować maszyny.

Żeby to pokazać, potrzebuję pada od Xboxa. Bo Skate 3 Bench to nie benchmark nazywający triki. To nawet nie port gry. To nowa gra i nowy silnik, stworzone od zera przez Claude, mające odtwarzać klimat starych gier o skateboardingu. Model pobrał, o ile pamiętam, jakiś zgrubny model człowieka ze sklepu z zasobami do Blendera i przerobił go tak, żeby trochę przypominał mnie. Dałem mu przykłady sterowania ze skate i kazałem odtworzyć je najlepiej, jak potrafi; powiedziałem, co ma być, a czego nie ma być, żeby powstał mały skatepark i zagrało to, co najważniejsze — rozgrywka.

I to jest naprawdę grywalny klon EA skate, co brzmi trywialniej, niż jest w istocie, bo sterowanie w skate to spore wyzwanie. Nie skaczecie przyciskiem: wszystko opiera się na systemie flick-it — o trikach decyduje sposób, w jaki poruszacie prawą gałką. Całość działa w mojej przeglądarce, na silniku opartym na three.js, zbudowanym przez Claude, a fizyka jest zaskakująco przyzwoita. Nie idealna, ale lepsza niż w większości klonów skate, jakie gram w życiu — a grałem ich mnóstwo. (Jakaś niedawna zmiana zepsuła animację inward heelflipa; kiedyś była znacznie lepsza.) Mogłbym tak siedzieć i robić głupie triki cały dzień — taka mam słabość po latach grania w te gry. To, że wyszło coś tak znośnego, jest po prostu obłędne.

Ale gdybyście po prostu kazali Claude: „zrób mi klon skate, nie popełniaj błędów”, nie wyszłoby nic podobnego. Co więc zrobiłem?

Zaznaczę od razu: nie jestem jedynym, kto dziś robi z skate fajne rzeczy. Istnieje projekt Skate 3 Rust Engine — próba przepisania Skate 3 linijka po linijce z dekompilacji, by odtworzyć całą fizykę w Bevy. Tego typu przedsięwzięcia wspina się stosunkowo łatwo — niewiele różni się to od tego, jak ustawiłem TS Rust. Ja zrobiłem coś innego: nie przechodzę po istniejącym projekcie i nie odtwarzam możliwości jednej po drugiej. Próbuję stworzyć coś, co nie istniało, w sposób, który nie istniał. Odtwarzanie istniejących rzeczy to banalnie łatwa wspinaczka — zaraz pokażę przykłady. Ale samo pojęcie wspinaczki jest kluczem do zrozumienia całości.

Czym jest wspinaczka i dlaczego modele są w niej dobre

Skoro tak, musimy na chwilę o niej pogadać. Modele trenuje się przez mechanizmy nagrody. Najprostszy obraz, jaki potrafię podać, to kółko i krzyżyk. Wyobraźcie sobie, że trenujecie model, żeby był najlepszy na świecie w tej grze. Dawacie mu planszę w konkretnym stanie — powiedzmy, że jest oczywiste, wygrywające pole. Pokazujecie modelowi bieżącą sytuację i pytacie, gdzie postawić kolejny znak. Wskaże zły Schlag — zaliczył porażkę. Wskaże właściwy — dostanie nagrodę. To najbardziej prymitywny przykład, ale chodzi o ideę: model ma coś, co można sprawdzić jako sukces albo porażkę, a po zakończeniu przebiegu jest korygowany tak, by częściej robił to, co zadziałało, a rzadziej to, co nie.

Modele mają w gruncie rzeczy dwie składowe: wiedzę i zachowanie. Wiedza pochodzi z danych, na których model jest trenowany — fakty i informacje z etapu wstępnego treningu. Zachowanie w dużej mierze rodzi się z uczenia ze wzmocnieniem: model uczy się, że zamiast po prostu odpowiadać na pytanie, najpierw wywoła narzędzie, żeby zdobyć potrzebne informacje; albo sprawdzi hipotezę, napisze kod na jej dowód, a gdy się nie uda — spróbuje czegoś innego. Domyślnie model po prostu odpowie na wasze pytanie. Nie będzie testował teorii ani niczego próbował — odpowie na podstawie wiedzy. Dlatego przeprowadza się takie treningi: żeby model pracował dłużej, rozwiązywał problemy, robił to, czego od niego oczekujemy.

Prostszy wariant przykładu: test jednostkowy. Zadanie brzmi: weź plik x.ts, wygeneruj x.js i wypisz trzy konkretne błędy. Jeśli mam tak skonstruowany przypadek — konkretny plik TypeScript, oczekiwaną postać JavaScriptu po kompilacji oraz listę błędów, które wypisałby kompilator — to mogę kazać modelowi napisać narzędzie. Uruchamiam jego kod: wychodzą właściwe rzeczy — sukces; wychodzi coś innego — porażka. Termin na to to RLVR: uczenie ze wzmocnieniem z weryfikowalnymi nagrodami. Model trenuje się przeciwko narzędziom, które programowo rozstrzygają: udało się czy nie. Podczas treningu model widzi głównie takie zadania: „mam plik A, napisz kod zamieniający go w plik B i wypisujący te błędy; masz pięć przykładów na widoku i pięćset, których ci nie pokażę; zalicz wszystkie, a powiem ci, czy wyszło”. I tak, krok po kroku, model jest formowany w zachowania, które chcemy mieć.

Od RLVR do praktyki: dlaczego TS Rust zadziałał tak szybko

Co to ma wspólnego z bardzo długimi zadaniami? Część odpowiedzi już padła. TypeScript to znakomity przykład materiału, który da się tak wykorzystać. Skoro ma mnóstwo weryfikowalnych wyników, można wziąć dowolny istniejący projekt, skompilować go oficjalnym kompilatorem i dostać zbiór wyników oraz finalne pliki. Jeśli do tych projektów celowo wstawić losowe błędy i przepuścić je przez TypeScript, zobaczymy dokładnie, gdzie są. A jeśli przepuścimy je przez nasz port i błędów nie zobaczymy — wiemy, że nasz kod nie działa. To bardzo bliskie środowiskom, w których modele są trenowane: model potrafi pisać kod zamieniający wartość A w wartość B, byle dało się to osiągać powtarzalnie.

Przy TS Rust było więc łatwo. Kazałem modelowi: weź ten zestaw prawdziwych projektów, odpal z przypiętą wersją TypeScriptu, ustal dokładnie, jakie są wyniki — i gonić. Nie skończysz, dopóki na wszystkich tych projektach nie dostaniemy z naszym pakietem TS Rust dokładnie tych samych wyników co ze zwykłym TypeScriptem. Zdziwilibyście się, jak dobre są modele, gdy dostają tak jasny cel. Dlatego TS Rust zaczął działać w dzień, a naprawdę dobrze zrobił się w kilka tygodni. Bo gdy już coś działa i ma weryfikowalne wejścia i wyjścia, można zejść poziom głębiej: zamiast „dopilnuj, żeby błędy się zgadzały”, mówisz „bądź dwa razy szybszy od oficjalnej wersji i nie zepsuj żadnej istniejącej walidacji ani testu”. Pierwsza działająca wersja TS Rust była wolniejsza od tsgo — oficjalnego, natywnego kompilatora TypeScriptu. (Informacja dodatkowa: tsgo to rozwijany przez Microsoft natywny port kompilatora TypeScript, znany jako TypeScript 7 Native.) Kazałem: „nie przerywaj, aż będziesz dwa razy szybszy”. I szedł, aż był dwa razy szybszy — bo wie, jak sprawdzić, czy działa, i wie, jak sprawdzić, czy jest szybki. Im bardziej wasze zadanie przypomina to, jak model był trenowany, tym lepiej sobie z nim poradzi.

Jak zweryfikować grę, której nie da się przetestować

A jak zrobić to dla rzeczy, których tak łatwo nie zweryfikować? Bo, szczerze, choć historia z TypeScriptem jest szalona, jej weryfikacja jest prosta: wynik ma być identyczny, a wyniki to zwykły tekst. Jak to zrobić dla gry? Miałem złożony pomysł, który chcę wypróbować w przyszłości, ale w pierwszej wersji wybrałem metodę dużo prostszą.

Dużo krytykowałem komendę /goal. (Informacja dodatkowa: /goal to funkcja Claude Code pozwalająca zadać agentowi długoterminowy cel, nad którym pracuje w pętli bez nadzoru.) Wciąż uważam, że nie powinniście jej używać — to narzędzie, które strzela w stopę tego, kto je trzyma. Ale jeśli akurat macie ochotę się postrzelić, jest całkiem zabawne.

Więc: /goal — „Stwórz przekonującą grę webową, która odtwarza fizykę i sterowanie EA Skate 3. Gra ma działać z padem; w razie potrzeby symuluj wejście. Rdzeniem doświadczenia jest jazda po niewielkim skateparku. Najważniejsze jest sterowanie i fizyka. (Ten tekst dyktowałem głosowo, więc sporo rzeczy się przy okazji posypało.) Mechanika EA skate nie używa przycisków do trików — używa prawej gałki, odtwarzającej ruchy prawdziwych skaterów. Te mechaniki pojawiły się już w innych grach; dopilnuj, żeby u ciebie były zrobione dobrze.” Dorzuciłem detale o ustawieniu kamery i pełną listę podstawowych flip-tricków. I tu zrobiłem z tego zadanie, po którym da się wspinać: „Gra ma dobrze wyglądać. Powinno dać się zrobić zrzut ekranu, porównać go z oryginałem i uczciwie powiedzieć, że jakość grafiki jest zbliżona. Masz dostęp do Blendera — używaj go do modeli tam, gdzie to ma sens. Najpierw doprowadź rozgrywkę do działania, z modelami, które czują się jak skateboard, i czytelnym wypisywaniem nazw trików, które wykonuję. Wszystkie animacje musisz zrobić sam. Kontynuuj, dopóki nie powstanie gra, która czuje się jak oryginalny skate.”

W pewnym momencie zaktualizowałem cel. Nie chce mi się przewijać do dokładnego miejsca, ale w efekcie kazałem modelowi, żeby przy każdej wersji, z której jest zadowolony, robił serię zrzutów ekranu w określonych stanach, porównywał je z prawdziwym materiałem z gier i zwoływał panel sędziów oceniających, czy moja wersja jest wystarczająco dobra. I widać było, jak model się wspinał: łapał zrzuty z losowych momentów oryginału, zrzuty z analogicznych momentów u siebie i oddawał wszystko innemu LLM-owi (albo kilku) do oceny z informacją zwrotną, czy jego wersja wygląda lepiej.

Chcę być jednoznaczny: nie uważam, że to jest dobre. Uważam, że to nie jest nawet w porządku. Jest szczerze zaskoczony, że zadziałało. Oryginalny plan był intensywniejszy — miałem zagrać w pierwszego skate., nagrać swoje wejścia pada i oddać je jako powtórkę, którą agenci mogliby odtwarzać, żeby „zdawać egzamin” z gry, którą tworzą, i porównywać jej zachowanie na losowych klatkach z oryginałem. Ale byłem leniwy. Wystarczyło kazać porównywać zrzuty ekranu. To dało modelowi coś, za czym może gonić. Dopóki ma coś, co potrafi sprawdzić i rozstrzygnąć, czy wystarczy — a jeśli nie, iść dalej — będzie biegł długo. I dopóki to, co sprawdza, jest wystarczająco zgodne z waszym celem, skończycie z czymś, co przynajmniej trochę przypomina to, o co prosiliście.

Będą dziwne problemy. Jestem przekonany, że wydał co najmniej osiemset dolarów tokenów, dopracowując samo niebo (skybox), żeby wyglądało bardziej jak w skate. Ciągle też rozjaśniał grę, bo początkowo porównywałem ze Skate 3 — a grafika Skate 3 jest moim zdaniem obrzydliwa. Zresetowałem i powiedziałem: „nie, punktem odniesienia jest jedynka — jej wygląd lubię znacznie bardziej”. W skrócie: zastraszanie modelu, żeby robił zrzuty, ustawił panel porównujący z oryginałem, mówił, co jest lepsze i gorsze — i tak w kółko.

Recepta Theo: od kroku zero do kroku czwartego

Skoro macie już podstawy, rozłóżmy, jak ustawiam taką wspinaczkę z Claude u siebie.

Krok zero, o którym prawie zapomniałem: zaopatrz się w abonamenty Claude, których nie żałujesz. Gdyby liczyć wartość w dolarach, to — teraz, gdy o tym myślę — nic z tego nie było jej warte. Poza TS Rust: trzydzieści osiem tysięcy dolarów to przy nim uczciwa cena, zważywszy ile godzin kompilacji oszczędzi nam w realnej pracy. Reszta to bezsens. Ale w każdym razie: nie płaćcie cen API. Wszystkie kwoty, które podałem, to rachunki w cenach API. My płacimy ceny subskrypcyjne. Gdy dostałem pierwszy działający build TS Rust, dwukrotnie szybszy, było to odpowiednik pięciuset dolarów użytkowania abonamentowego. Nie róbcie tego po cenach API — róbcie na abonamentach za dwieście dolarów, które można eksploatować, bo coś tak szalonego jak TS Rust da się zbudować za jakieś dziesięć tygodni takiego użytkowania. A jeśli nie jesteście gotowi spalić kupy abonamentów do cna — oglądajcie to z ciekawości, nie w zamiarze powielania.

Krok pierwszy: wymyśl coś, czego chcesz. Im bardziej żmudne, tym lepiej. Wszyscy jesteśmy inżynierami i optymalizujemy pod omijanie żmudnych czynności — i to nas czyni skutecznymi. Potrafimy godzinę pisać kod, żeby oszczędzić trzydzieści sekund raz w tygodniu. Ale mamy próg, poza którym coś jest po prostu za żmudne. Kiedyś wszyscy lubiliśmy przepisywać używane narzędzia na ulubiony język — ale niekoniecznie lubimy przenosić stary kod z języka, którego nie cierpimy, do innego, którego też nie cierpimy. Taka praca wykańcza. Musiałem tu mocno przeprogramować własną głowę: całe życie robiłem wszystko, żeby żmudności unikać, a teraz mam w nie inwestować. Im bardziej żmudne zadanie wymyślę, tym większa szansa, że model zrobi z nim coś szalonego. Przepisanie kodu o ponad stu tysiącach plików na Rust byłoby dla człowieka męką — agentowi nie przeszkadza. Znajdźcie coś, czego żałujecie, że nie istnieje, czego chcecie albo o czym jesteście ciekawi — i spróbujcie zrobić to maksymalnie żmudnym sposobem.

Krok drugi, najważniejszy: znajdź sposób weryfikacji. Coś, co wy albo agent zrobicie bez wysiłku — spojrzeć na efekt i stwierdzić, czy to już sukces. Tu zaczyna błyszczeć spryt. Są rzeczy łatwe: przy TS Rust trywialne było „weź te projekty, upewnij się, że działają, potem zacznij losowo wstawiać błędy i sprawdź, że one też działają”. Weryfikacje, które wymyśliłem dla Skate 3 Bench, są dziwniejsze i sprytniejsze — i jestem na nie dumny. Idealnie nie powinny wymagać człowieka, bo jeśli potrzeba osoby, która patrzy i mówi „dobre albo złe, a oto dlaczego”, postęp będzie mizerny, a sami ugrzęźniecie w czekaniu. TS Rust miał około tysiąca ośmiuset rewizji; w pętlach napłynęło 7 884 commity. Potrzebujecie programowego rozstrzygnięcia pass/fail — albo, w ostateczności, sposobu, w którym inny agent ogląda wyniki i decyduje, czy działa.

Krok trzeci: przygotuj agentów na sukces. Wiedzą już, co robić, wiedzą, jak mniej więcej wygląda sukces i porażka — teraz potrzebują narzędzi. Gdybyście poprosili ChatGPT o cokolwiek z tego, co pokazałem, by poległ, bo nie ma odpowiednich zasobów. Do Skate 3 Bench potrzeba komputera z GPU i graficznym interfejsem, żeby odpalać Blendera, generować modele, przenosić je do przeglądarki i sprawdzać, czy wyszły dobrze. Musicie ustalić, czego wasi agenci potrzebują — i pamiętać, że te potrzeby zmieniają się w czasie, zwłaszcza gdy wchodzicie w ciężką równoległość. Mam tu zabawną historię i kilka wskazówek, w tym rzeczy, które fundamentalnie zmieniły sposób, w jaki buduję z agentami — które dosłownie rozbiły mi głowę. Dostałem niedawno zgodę, żeby o nich opowiedzieć, więc bardzo się cieszę.

Blacksmith, czyli gdy kolejki zjadają tydzień pracy

Żeby wyjaśnić nową, tajną sztuczkę odblokowującą agentów, muszę więcej powiedzieć o TS Rust i wąskich gardłach. Cały port kosztował równowartość około czterdziestu tysięcy dolarów w cenach API. Na abonamentach — według moich wyliczeń — pięćset, może osiemset dolarów użytkowania, bo subskrypcje są mocno subsydiowane: za plan za dwieście dolarów dostajecie jakieś dwanaście tysięcy użycia. Ale teraz pytanie: ile myślicie, że wydałem na moc obliczeniową?

Pytam, bo w trakcie projektu drastycznie zabrakło mi sprzętu. Wyciągałem komputery z magazynu i instalowałem na nich T3 OS. Zarekwirowałem na czas stos miniatur Minisforum, które zamierzałem oddać znajomym założycielom — tylko po to, żeby robić buildy. Widać było, ile czasu agenci spędzają w kolejce, zanim w ogóle mogli odpalić kompilację i przetestować zmiany. Miałem osiem maszyn w sieci lokalnej plus dwa serwery VPS, na które agenci wchodzili po SSH.

I teraz muszę być jasny: kocham Blacksmith. To nasz sponsor — i nie przez przypadek. Używamy ich do całego naszego CI. To niesamowicie tania platforma do uruchamiania CI, buildów i agentów. Zbudowali ją pod zadania zdefiniowane w repozytorium, typu GitHub Actions — nie pod to, żeby agent wchodził po SSH i działał po swojemu. Blacksmith obsługuje całe CI T3 Code i oszczędził nam kupę czasu i pieniędzy — to wręcz śmieszne. Dlatego musicie rozumieć, że poniższa liczba nie jest atakiem na Blacksmith. Wręcz przeciwnie.

Wydałem ponad dwa tysiące dolarów mocy obliczeniowej na Blacksmith na wszystkie testy TS Rust. To nie rachunek za CI — ten wyniósł kilkanaście, może dwadzieścia parę dolarów. Po prostu skończyła mi się moc w sieci lokalnej, i widać było cały ten czas czekania. To oznaczało, że jeśli model miał zadanie na dziesięć minut, to do godziny tkwił w kolejce, zanim w ogóle zaczął je wykonywać. Bo choć sam Rust jest szybki, jego kompilator jest niewiarygodnie wolny — i powody tego zaskoczyły mnie samego: wbrew intuicji to nie borrow checker, tylko mnóstwo innych rzeczy. Do tego Blacksmith, jak mówiłem, nie jest zbudowany pod taki styl pracy. Ale dało się to poskładać: agenci sami się odblokowywali, tworząc zadania w chmurze. Czas czekania na moc spadł na podłogę, gdy tylko to ustawiłem. Wcześniej agenci na jeden przebieg czekali na dostępne zasoby nawet dwanaście godzin; ta zmiana zbiła to do 1,2 godziny. Różnicę zobaczyłem od razu: kod zaczął lądować znacznie szybciej. Ale same zadania wciąż trwały za długo — dwadzieścia, czterdzieści minut na build, żeby tylko sprawdzić, czy zadziałało. I to zrodziło mój kolejny projekt na żywioł. Właśnie dlatego istnieje Lust — nie chciałem, żeby TS Rust kompilował się tak potwornie długo.

Boat: maszyny, o które nie trzeba dbać

Obiecałem wam sekret — rzecz, która odblokowała moje chaotyczne budowanie. I choć kocham Blacksmith, to nie on. Blacksmith jest dla poważnych projektów z poważną weryfikacją, CI, wydaniami — tam rachunki są rozsądne, a wgląd świetny. Osobiście nie kazałbym agentom używać Blacksmith w lokalnej pętli developerskiej poza sprawdzaniem istniejącego CI.

A teraz modlę się, żeby mi się to nie odbiło. Musimy porozmawiać o Boat — konkretnie boat.dev. Boat to jedna z najfajniejszych rzeczy, jakich użyłem od lat. Wiecie o tym, bo gdy tylko o nim wspominam, Maria wpada na czacie w panikę: „Theo, przestań to saturować!”. Dałem zespołowi znać i boję się, że ta publikacja zaszkodzi. Przerażają się, bo Boat to jedna z tych rzeczy zbyt dobrych, żeby były prawdziwe. To bardzo — wręcz absurdalnie — wygodny sposób, by wasi agenci mogli stawiać maszyny wirtualne dokładnie wtedy, kiedy ich potrzebują. Mógłbym opisać, co robi, ale mogę też zacytować samego siebie z ich strony internetowej — to ja im wysłałem ten cytat i poleciłem go umieścić: „Od dawna żadna nowa firma tak mi się nie podobała. Boat odblokował mi agentów tak mocno, że palę konta Claude cztery razy szybciej. Nie mogę być szczęśliwszy”. Właśnie dlatego musiałem przejść z sześciu kont na siedem.

Co to jest Boat? Bardzo prosty sposób stawiania maszyn wirtualnych, o które nie musicie dbać. Pokażę, jak to proste. Instaluję. (Mają tu drobny błąd w interfejsie — powinno pokazywać jedno podpięcie GitHuba; kazałem agentowi to zaraportować.) Mam panel i narzędzie wiersza poleceń. Wpisuję boat — widzę wszystkie dostępne komendy. Wpisuję boat limits — widzę limity na planie za pięćset dolarów miesięcznie. Tak, płacę abonament za moc obliczeniową. Tak to skonstruowali: macie limit równoległych sandboxów, limity uruchomień na minutę, godzinę i dzień, a osobno koszt faktycznego użycia działających maszyn. Zacząłem od planu za dwadzieścia dolarów, podskoczyłem do stu, potem do pięciuset — i szczerze mówiąc coraz bardziej kusi mnie dwutysięczny, bo aż tak bardzo mi to odblokowało agentów.

Magia Boat tkwi w łatwości stawiania maszyn na zawołanie. Boat new — mam własny sandbox. Boat ssh — jestem w środku. Mogę doinstalować btop albo cokolwiek chcę (tak się przyzwyczaiłem, że btop jest u mnie domyślnie). Gdyby potrzebny był interfejs graficzny — boat desktop — i mam prawdziwy pulpit linuksowy z przeglądarkami i terminalami. Nie ma tam chyba GPU i raczej nie liczyć na akcelerację sprzętową, ale używać się da. Co ważniejsze — agenci też mogą, bo wszystko dzieje się przez terminal. Mogę wypisać listę swoich maszyn i zabić dowolną: boat stop plus identyfikator — i po niej. Widzicie te wszystkie maszyny „lust-gate”: to one wstają, kiedy któryś z podagentów potrzebuje mocy.

W Boat jest mnóstwo małych rzeczy, które czynią go świetnym do tego zastosowania — zwłaszcza snapshoty. Agent raz klonuje repozytorium, zaciąga wszystko, buduje, ustawia szybkie przeładowywanie, robi migawkę — i każdy kolejny, zamiast ściągać cały wszechświat, odpala tę migawkę i dokłada tylko testowane zmiany. Zanim ustawiłem Boat, agenci korzystali z czterech współdzielonych slotów na jednym VPS-ie, na którym robię większość pracy agentowej. Czas pełnego przepchnięcia zmiany przez kompilację i weryfikację wynosił pod obciążeniem czterdzieści–siedemdziesiąt minut, czasem więcej. Lądowałem więc jakieś siedemdziesiąt zmian dziennie, a na pojedynczy pakiet po dwie. Po wdrożeniu Boat mogę — to znaczy: moi agenci mogą — w każdej chwili postawić wiele maszyn, i czas spadł z siedemdziesięciu minut do trzystu pięćdziesięciu trzech sekund. Sześciu minut. Ilość lądowanego kodu dziennie więcej niż się podwoiła — właściwie bliżej potrojenia — i projekt nagle ruszył znacznie szybciej. Wydałem na Boat kwotę dość absurdalną, ale gdy zobaczycie, jak to śmiesznie tanie — bardzo dobra platforma. Bardzo polecam. Podobało mi się na tyle, że zainwestowałem. Zmusiłem ich wprost do przyjęcia czeka.

Chcę też podkreślić, po co coś takiego jak Boat. Nie po to, żeby stawiać serwery, na które kierujecie użytkowników. Po to, gdy potrzebujecie mnóstwa doraźnych maszyn do doraźnej pracy, bo zapotrzebowanie na moc faluje. Bo gdy przyjmiecie nową rolę — dostarczyciela tego, czego agenci potrzebują — szybko zauważycie, że ich potrzeby są elastyczne. Jeśli wyposażacie biuro, potrzebujecie biurka i monitora dla każdej osoby. Ale gdyby każdy pracował osiem godzin, a kolejna osoba siadała dopiero wtedy, gdy poprzednia wstaje, moglibyście skroić liczbę biurek o dwie trzecie. Tyle że tak się nie da: chcecie, żeby wszyscy pracowali naraz, więc kupujecie pod szczyt, nie pod średnią. Jeśli kupicie tyle mocy, żeby agenci mogły zrobić wszystko, co tylko zapragną — przepłacicie, bo zwykle nie potrzebują tyle. Jeśli za mało — będą ciągle zablokowane. Dlatego tak lubię Boat: banalnie łatwo skaluje się w górę i w dół zależnie od tego, nad czym akurat agent pracują.

Pytaj agentów, co je blokuje

I wreszcie krok najważniejszy, czwarty: pytajcie agentów, co jest największą przeszkodą. Prowadziłem dla TS Rust dwa wątki. Jeden to nieskończony cel, nieustannie próbujący przyspieszyć budowanie TypeScriptu w Ruście. Drugi służył mi do okresowych odpraw: kazałem mu przeczytać historię i dać raport. W pewnym momencie zauważyłem, że postęp zwalnia, więc zapytałem w drugim wątku: co teraz hamuje pracę, jakie są największe problemy? I dowiedziałem się, że Claude musiał zbudować kolejkę ustalającą, który przebieg ma prawo uruchomić kompilację, zanim komputer padnie — bo na początku odpalał za dużo naraz i maszyna umierała. Zapytałem, jak to naprawić — zrobił kolejkę. Zapytałem, jak przyspieszyć — odparł, że potrzebuje więcej mocy. Więc podłączyłem wszystkie maszyny, jakie miałem, dałem dostęp po SSH i pozwoliłem dzielić pracę między nie. Pomogło. Przeszedłem na Blacksmith, bo chciałem odzyskać własny sprzęt — pomogło jeszcze bardziej. A potem, jak wiecie, oszalałem z Lustem.

Chcę, żeby to do was dotarło: kroki trzeci i czwarty to nie czynności jednorazowe. To pętla. Gdy macie już środowisko z zadaniem i weryfikacją, wciąż czeka was praca — ale nie polega ona na czytaniu każdej linijki kodu. Polega na współpracy z agentem: dostarczaniu mu tego, czego potrzebuje, i ciągłym pytaniu: co cię spowalnia? co blokuje? co mogę dla ciebie zrobić? Z czasem agent zacznie się poruszać znacznie szybciej. A przy okazji przyjdzie wam dokupować abonamenty Claude, bo jeśli staniecie się w tym naprawdę dobrzy, palicie je znacznie szybciej: gdy TS Rust działał na jednym komputerze, zużywałem jeden–dwa abonamenty tygodniowo; po odseparowaniu całej mocy obliczeniowej spaliłem wszystkie siedem w okamgnieniu. Kiedy ludzie mówią, że prowadzenie agentów przypomina bycie menedżerem, właśnie o tym mówią. Twoim zadaniem nie jest sprawdzanie każdej porcji pracy pracownika. Twoim zadaniem jest stawianie go na nogi, pytanie, co go hamuje, i budowanie najlepszego możliwego środowiska.

Pętla, która wraca do początku — narodziny Lusta

A teraz najlepsze. Powiedziałem, że ta pętla zawraca was do kroku zero, czyli do kupowania kolejnych abonamentów. Ale zawraca was też do kroku pierwszego. Bo gdy dostrzegacie rzeczy, które blokują lub spowalniają agentów, okazuje się, że niektóre z nich same nadają się na wspinaczkę. Na przykład przepisując TypeScript na Rust zaczynacie dostrzegać, jak wolny i ciężki jest kompilator Rusta. I jeśli odrobinę się nad tym zastanowicie, widzicie okazję, żeby zejść jeszcze głębiej — i tak właśnie skończyliśmy z Lustlang. I dlatego istnieje ten pull request: cały sens Lusta polegał na odblokowaniu TS Rust. Czy ten kompilator zadziała w innych aplikacjach? Niemal na pewno nie. Ledwo działa dla samego TS Rust. Trzeba było wymyślić od nowa tyle funkcji Rusta, cargo, a nawet LLVM, żeby to w ogóle zbudować. Ale teraz build, który z cargo trwał siedemnaście minut, robi się w dwanaście sekund.

Ten wciąż biegnie, bo dałem mu dwa bardzo śmiałe cele. Pierwszy: wszystkie buildy i całe CI mają być sto razy szybsze niż cargo. Drugi: wynikowy plik binarny ma mieścić się w dwudziestoprocentowym marginesie wydajności. Bo kompilator Rusta robi rozmaite sztuczki i nie weryfikuję, że binarka jest identyczna jak z cargo — tak jak robiłem to przy porcie TypeScriptu. To będą różne pliki, więc muszę mieć pewność, że oba działają i oba są wydajne. I oto widzimy, jak model z pełnym przekonaniem oznajmia, że cel osiągnięty. Liczby schodzą się blisko wartości 1,2–2 razy, bo dokładnie taką postawiłem mu poprzeczkę. I ten całkowicie obłąkany projekt — coś, co jeszcze niedawno wydawało się zgubione, gonieniem za nierealnym marzeniem — po prostu działa. To szaleństwo.

Wszystko jest dziś uginane i przebudowywane

A gdy zaczniecie tak myśleć i będziecie gotowi tak palić tokeny, zobaczycie takich rzeczy więcej. Budując te pętle, zobaczycie kolejne okazje do budowania następnych. I dotrze do was, że wszystko, nad czym pracujemy, wszystko, czego używamy i na czym polegamy co dzień, jest dziś uginane. Możemy w tym wszystkim grzebać. Wszystko da się zmieniać i przebudowywać. Nie jest tanio — potrzeba mnóstwa abonamentów — ale się da. I pamiętajcie: koszt inteligencji spada obecnie cztery–pięć razy w skali miesiąca. Czyli mniej więcej za rok pętle takie jak te będą zupełnie przystępne cenowo — poza mocą obliczeniową, na której biegną. Jeśli więc zbudujecie te umiejętności już dziś, będą z czasem coraz bardziej użyteczne. Bo jako branża odchodzimy od modelu „zinżynieruj rozwiązanie problemu i je wyślij” — i przechodzimy do czegoś znacznie bardziej podobnego do „inżynierowania rozwiązań wokół pracy agentów, żeby mogły robić rzeczy szalone”.

Czy powinniście tak budować? Nie.

Czy myślę, że powinniście budować w ten sposób już dziś? Absolutnie nie. Serio — nie róbcie tego. To było piekło. Natrafiłem na tyle dziur w tylu rzeczach. A teraz wszystko, na co mam ochotę, to budowanie nowych narzędzi open source i kompilatorów, bo wpatruję się w rzeczy spowalniające moich agentów i chcę je zniszczyć. Wszystkie po kolei. Chcę odblokować agentów, żeby wreszcie wrócić do klepania głupich małych aplikacji webowych.

A takCLR serio — to niesamowite, że można po prostu popatrzeć, gdzie agenci tracą czas, wspiąć się na te miejsca i schodzić coraz głębiej. Cała ta królicza nora zaczęła się od tego, że chciałem odpalić pełne środowisko TypeScript w izolacie V8 na Cloudflare. A teraz przepisuję samego Rusta i buduję własny system operacyjny. Zariabiam? Pewnie tak. Ale powiem szczerze: to także po prostu wspaniała zabawa. Nie czerpałem z budowania i technicznego myślenia takiej radości — może nigdy w karierze. Uczę się więcej z każdym dniem. Wchodzę w rzeczy, na które nigdy nie miałem odwagi spojrzeć, nie mówiąc o rozumieniu ich. I wszystko wydaje się teraz osiągalne. Wszystko, na co spojrzę i czego nie lubię, da się naprawić — byle nie miało logo Apple. Mógłbym urządzić tiradę o tym, że na tym etapie życia nie ufam niczemu, co nie jest open source, ale zostawię ją na inny film.

Wydaje mi się, że powiedziałem już wszystko. Idę palić więcej Claude. Mam nadzieję, że wy też — a może jednak nie; użyjcie własnego osądu. Nie ponoszę odpowiedzialności za nic, na czym użyjecie tych technik, ani za nic, co przy okazji zniszczycie. To była chaotyczna podróż i bardzo się cieszę, że mogę was w nią zabrać — zobaczycie, dlaczego ostatnio tak często siedzę do szóstej rano. To jest zbyt fajne. Jeśli was nie stać, rozumiem. Jeśli sądzicie, że to was doprowadzi do szaleństwa — też rozumiem. Ale mam nadzieję, że będziecie z przyjemnością przyglądać się temu chaosowi, dopóki ludzie tacy jak ja będą robić te wszystkie rzeczy.