Prawdziwym wąskim gardłem w Claude Code jest Twoja uwaga

O czym jest ten film

Punktem wyjścia jest wpis Andreja Karpathy’ego: im lepsze modele, tym więcej żmudnej roboty odwalają samodzielnie, a praca inżyniera przesuwa się wyżej — ku nadzorowi i rozumieniu.
Podobnie brzmią relacje z samego Anthropic: jeden z inżynierów opisał swoją pracę jako „stawianie czoła armii Claude’ów, z których każda dopomina się o moją uwagę”. Wąskim gardłem przestał być kod, stała się nim uwaga człowieka.
Hasło przewodnie autora: kod jest tani, uwaga nie. Tokeny kosztują grosze na tle ludzkiego czasu, a wygrywa ten, kto lepiej rozdysponuje uwagę, gdy agenci pracują całą dobę.
Argument z historii: przypowieść o Williamie Playfairze, który w 1786 roku zamienił tabelę liczb w wykres — pierwszą grafikę danych. Wniosek: właściwa forma przedstawienia danych pozwala myśleć inaczej i decydować lepiej.
Kod pisany przez agentów to właśnie owa „tabela liczb” — trzeba ją świadomie zamieniać w czytelne formy: tekst, diagramy, HTML i wideo (lista Karpathy’ego).
W pracy z tekstem najprzydatniejszy trik: „tego nie czytałem — przeprowadź mnie przez to krok po kroku”. Bez tego zastrzeżenia model zakłada, że znasz całość i tylko się gubisz.
Diagramy Mermaid służą do szybkiej orientacji w systemie; pomagają też umiejętność „Show Me” oraz darmowy mod wyświetlający panel z podsumowaniem całej sesji Claude’a.
HTML w nauce: interaktywne wykłady Feynmana z ożywionymi diagramami (np. ruchy Browna), budowane w obieg weryfikacyjny z podagentów — budowniczy plus dwóch recenzentów.
HTML w produkcji: przy 3–4 tysiącach scalanych miesięcznie pull requestów agent sam zgłasza się po decyzję przez artefakt na Slacku, gdy zmiana dotyka autoryzacji, płatności, SDK, kwestii prawnych.
Filmy wyjaśniające to format, w który Karpathy „wierzy najbardziej”: od trójwymiarowego objaśnienia zasad gry Tokyo Highway po czterominutowe streszczenie open-source’owego Rebalancera. Autor ogląda takie materiały około godzinę dziennie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Optymalizuj uwagę, nie czas pisania kodu

Na czym polega: gdy agenty piszą kod za Ciebie, koszt wytworzenia rozwiązania spada, a limitującym zasobem staje się to, ile decyzji zdołasz świadomie rozpatrzyć w ciągu dnia.

Jak stosować: przejrzyj swój dzień pod kątem momentów, w których „ogarniasz” to, co zwrócili agenci. Każdy taki moment potraktuj jako kandydata do zamiany na lepszą formę przedstawienia: diagram, stronę HTML, krótkie wideo.

Na co uważać: liczba scalonych pull requestów opisuje skalę fabryki, nie jakość Twoich decyzji — sam autor odżegnuje się od traktowania jej jako miary sukcesu.

2.Zamieniaj „tabele liczb” na właściwą reprezentację

Na czym polega: lekcja Playfaira i Breta Victora — ta sama treść w innej formie pozwala zobaczyć rzeczy, których w surowej postaci nie widać. Kod agentów to surowiec; decyzje podejmujesz dopiero na jego czytelnej wizualizacji.

Jak stosować: przy każdym obszernym wyniku pracy agenta zadaj sobie pytanie: „jaka forma najlepiej pokaże sedno — tekst, diagram, klikalna strona, wideo?” i poproś agenta o tę właśnie formę.

Na co uważać: zła reprezentacja potrafi wprowadzać w błąd skuteczniej niż tabela — pierwsze wersje interaktywnych dem u autora wychodziły błędne i mylące, zanim doszło weryfikacji.

3.Zaczynaj od „tego nie czytałem”

Na czym polega: gdy model zwraca długi wynik, którego nie masz siły czytać w całości, powiedz to wprost i poproś o oprowadzenie krok po kroku. To jedno zdanie zmienia sposób, w jaki model tłumaczy.

Jak stosować: rozpoczynaj prompt od słów „tego nie czytałem, przeprowadź mnie przez to po kolei” — dostaniesz opis zamiast zalewu szczegółów.

Na co uważać: jeśli pominiesz to zastrzeżenie, model założy, że znasz cały materiał i będziesz dostawał odpowiedzi zakładające kontekst, którego realnie nie masz.

4.Diagramy Mermaid jako mapa systemu

Na czym polega: prosty diagram zależności pozwala błyskawicznie zrozumieć fragment systemu albo objąć wzrokiem dużą zmianę, zanim ją zaakceptujesz.

Jak stosować: proszenie Claude Code o diagram Mermaid dla interesującego Cię podsystemu (u autora — SDK jego usługi); pomocne są też umiejętności typu „Show Me” od Human Layer, które zapisują logikę jako pseudokod lub drzewo wywołań, oraz mod z panelem pokazującym cały przebieg sesji — nieoceniony przy wracaniu do przerwanej pracy.

Na co uważać: diagram to tylko przedstawienie kodu, nie jego zastępstwo — przy szybko zmieniającej się bazie upewnij się, że opisuje stan aktualny, a nie sprzed kilku zmian.

5.Interaktywny HTML do nauki i „ożywiania” wiedzy

Na czym polega: statyczny rysunek z podręcznika można zamienić w klikalną symulację — autor odtworzył styl rysunków Feynmana i zrobił z nich interaktywne demonstracje, np. ruchy Browna z regulacją temperatury.

Jak stosować: przekaż Claude’owi materiał źródłowy (rozdział wykładu, dokumentację) i poproś o interaktywny diagram wyjaśniający ideę; jeśli studiujesz lub masz dzieci na studiach, rozważ subskrypcję Claude Code lub Codex właśnie w tym celu.

Na co uważać: pierwsze wersje często bywają błędne — zbuduj obieg weryfikacyjny z podagentów: budowniczy tworzy, potem recenzent sprawdza zrozumiałość, a meritoryczny recenzent pilnuje zgodności z dziedziną (u autora: z fizyką).

6.Artefakt HTML jako briefing do decyzji

Na czym polega: agent pracujący w tle sam zgłasza się po decyzję — wysyła na Slacku stronę HTML, która w kilka chwil przybliża sytuację: makieta, przebieg testów, lista pytań. Ty tylko decydujesz.

Jak stosować: zdefiniuj obszary, w których decyzje należą do człowieka (u autora: SDK, uwierzytelnianie, płatności, kwestie prawne, wydzielone domeny aplikacji), zakaz agentom rozstrzygania ich samodzielnie i każ im przygotowywać artefakt wraz z pytaniem.

Na co uważać: artefakt ma skracać drogę do zrozumienia, nie ją wydłużać — jeśli robi się z niego coroczny raport, traci sens.

7.Dopasuj formę artefaktu do sytuacji

Na czym polega: autor celowo nie ma jednego szablonu — artefakt dla zmiany interfejsu pokazuje makietę i treść komunikatów, artefakt dla bramki weryfikacyjnej dowód uruchomienia i zrzuty ekranu.

Jak stosować: każ agentowi projektować układ materiału pod konkretną decyzję, a nie wklejać dane w stały formularz.

Na co uważać: sztywny szablon lubi ukryć to, co w danym wypadku faktycznie istotne — i odwrotnie, przemęczyć rzeczami nieistotnymi.

8.Klikalne plany HTML: decyzja przez wybór opcji

Na czym polega: zespół Claude Code buduje umiejętność generującą interaktywne plany: przeklikujesz kolejne makiety, odpowiadasz na pytania otwarte, podglądasz stany, które zobaczy użytkownik, a na końcu jednym kliknięciem kopiujesz odpowiedź z powrotem do Claude’a.

Jak stosować: sięgaj po ten format przy decyzjach o kształcie rozwiązania, gdy do wyboru jest kilka wariantów — wybór sprowadza się do klikania, nie do pisania elaboratów.

Na co uważać: to narzędzie do podejmowania wyborów, nie do weryfikacji technicznej — tę lepiej zostawić testom i bramkom.

9.Wideo wyjaśniające do oswajania nowych technologii

Na czym polega: przed lekturą gęstego posta inżynierskiego autor wrzuca linka (tweeta) agentowi, a ten w kilka minut produkuje film z diagramami i przykładami. Dzięki temu lektura szczegółów nabiera sensu — wiadomo, jak elementy składają się w całość.

Jak stosować: traktuj takie wideo jako wstęp do dokumentacji, nowego projektu czy biblioteki; prompt autora był zwięzły: „zrób film wyjaśniający zasady: ElevenLabs CLI, animacje 3D, dużo diagramów, bez tekstu”.

Na co uważać: wideo daje obraz całości, ale nie zastępuje lektury źródła — to orientacja przed wejściem w szczegóły, nie ich Ersatz.

10.Wpuść wyjaśnienia od AI do codziennej diety informacyjnej

Na czym polega: autor ogląda około godziny dziennie materiałów wyjaśniających generowanych przez AI — o wszystkim, co go interesuje — i rozważa poranne wideo z przeglądem zmian, które zaszły nocą w zespołach i projektach.

Jak stosować: zbuduj sobie codzienny przegląd tematów, które śledzisz, w formie krótkich filmów od agenta; w zespole pomyśl o porannym podsumowaniu zmian z ostatniej doby.

Na co uważać: automat teamowy dopiero jest testowany — autor sam dopiero szuka właściwej formy, więc najpierw pilotaż na małym zakresie, nie wdrożenie od góry.

Redakcyjne tłumaczenie

Armia Claude’ów dopomina się o Twoją uwagę

Dwa tygodnie temu Andrej Karpathy opublikował wpis, który dla wielu inżynierów okazał się niezwykle trafny — i chcę się mu przyjrzeć, bo z niego wynikają konkretne pomysły na porządkowanie własnych praktyk inżynierskich. Na końcu wpisu Karpathy pisze, że w miarę jak modele językowe będą coraz sprawniejsze, będą też coraz więcej żmudnej roboty odprawiać samodzielnie, a coraz większa część naszej pracy przesunie się wyżej, na poziom abstrakcji — ku nadzorowaniu i rozumieniu.

(Informacja dodatkowa: Andrej Karpathy — współzałożyciel OpenAI i były dyrektor ds. AI w Tesli, obecnie jeden z najważniejszych praktyków i komentatorów uczenia maszynowego.)

Sprawa jest o tyle poważna, że bardzo podobne wnioski płyną z samego Anthropic. W niedawnym artykule o tym, jak zmienia się praca w tej firmie, jeden z inżynierów opisał swoje zajęcie słowami: „moja praca to stawianie czoła armii Claude’ów, z których każda dopomina się o moją uwagę”. Coraz częściej widać to samo: wąskim gardłem przestaje być pisanie kodu, a staje się nim uwaga. Jeśli armia Claude’ów pracuje dla Ciebie całą dobę, to więcej i lepiej odrobią ci zadania ci, którzy potrafią lepiej rozdysponować własną uwagę.

Lubię to ujmować hasłem, które przewija się także w moim nadchodzącym kursie: kod jest tani, ale Twoja uwaga — nie. W ostatnich miesiącach ograniczenie wyraźnie przesunęło się z pisania kodu na rozumienie tego, co wróciło. Czas inżyniera to zasób rzadki; tokeni kosztują przy nim grosze. A jeśli spojrzeć na całość z lotu ptaka, nasza robota sprowadza się do jednego: tworzenia coraz bogatszych przedstawień danych, które pozwalają lepiej decydować na podstawie tego, co mamy pod ręką.

Dlatego wpis Karpathy’ego jest tak ważny — w praktyce uczy nas, jak tę uwagę rozdzielać. Chcę przejść przez całą serię przykładów na ekranie, bo znam to z autopsji: czytasz taki wpis, kiwasz głową, „fajne” — i nic się w Twojej pracy nie zmienia. Dopiero zobaczenie, jak ktoś stosuje dane rozwiązanie u siebie, sprawia, że przenosi się je do własnych nawyków.

Lekcja z 1786 roku: reprezentacja, która pozwala myśleć inaczej

Cała ta idea przypomina mi jeden z najlepszych wykładów, jakie widziałem — Breta Victora, niegdyś projektanta w Apple. Polecam obejrzeć go w całości. Victor opowiada w nim historię Williama Playfaira z 1786 roku. Playfair wpadł na pomysł: co jeśli zamiast czytać tabelę liczb — dokładnie taką jak ta na ekranie — odczytamy te same liczby jak mapę, korzystając z naszych wrodzonych umiejętności czytania map? Skoro na mapie góra, dół, lewo i prawo oznaczają kierunki świata, to co jeśli lewo i prawo staną się czasem, a góra i dół — pieniędzmi? Wyszło z tego coś w rodzaju tego wykresu. I tak powstała pierwsza w dziejach grafika danych.

Gdy Playfair przedstawił te same liczby — tę samą tabelę — w formie zbliżonej do mapy, wszyscy od razu zobaczyli, że to potężny sposób rozumienia danych. Pomogło im to myśleć inaczej i podejmować decyzje, których na podstawie samej tabeli nigdy by nie podjęli. Współczesna nauka bez dorobku Playfaira byłaby nie do pomyślenia. Najbardziej utkwił mi w pamięci wniosek, który wyprowadza z tej historii Victor: każda forma ujęcia danych pozwala nam myśleć to, czego wcześniej pomyśleć nie potrafiliśmy.

I właśnie tak patrzę na kod pisany przez agentów: to w istocie owa tabela liczb. Naszym zadaniem jest przemienienie jej we właściwe przedstawienie — takie, przy którym decyzję podejmuje się błyskawicznie, a agentom można pozwolić pracować dłużej i zdążać więcej. Stąd lista Karpathy’ego: pismo, diagramy, strony internetowe i filmy wyjaśniające. Ta część interesuje mnie najbardziej. Jeśli takie artefakty — takie reprezentacje — pozwalają nam myśleć inaczej i inaczej patrzeć na nasze dane i kod, to możemy decydować lepiej. A ponieważ nasze życie i nasz produkt to suma drobnych decyzji, które musieliśmy podjąć, możemy mieć i lepsze życie, i lepszy produkt. Wymyślnych form przedstawienia dałoby się pewnie wskazać wiele więcej, ale zostanę przy tych od Karpathy’ego: piśmie, diagramach i obrazach, HTML-u oraz filmach.

Tekst: „tego nie czytałem — przeprowadź mnie krok po kroku”

W części o piśmie Karpathy radzi, by kazać modelowi pisać w standardzie ASD-STE100, czyli uproszczonym angielskim technicznym. Wspominałem o tym dwa miesiące temu przy okazji filmu o Opus 5, ale dziś prawie z tego nie korzystam — Opus 5.5 domyślnie pisze po prostu znacznie lepiej.

(Informacja dodatkowa: ASD-STE100 to znormalizowany, celowo okrojony słownik i gramatyka angielskiego, pierwotnie stworzone dla dokumentacji lotniczej — mają maksymalnie ułatwiać jednoznaczne zrozumienie tekstu.)

Za to jeden nawyk jest dla mnie na wagę złota. Gdy model zwraca wynik zbyt obszerny, by objąć go jednym spojrzeniem, mówię mu wprost: „tego nie czytałem, przeprowadź mnie przez to krok po kroku”. To zdanie na początku ma kluczowe znaczenie. Jeśli go zabraknie, model przyjmie, że przeczytałeś całość i że po prostu się w czymś gubisz — i odpowie zupełnie inaczej, niż potrzebujesz.

Diagramy: Mermaid, „Show Me” i panel bieżącej sesji

Kolejny poziom to proszenie Claude Code o diagramy. Najczęściej chodzi o diagram Mermaid pomagający zrozumieć konkretny fragment systemu — u mnie na przykład o taki, który pokazuje, jak pod maską działa SDK mojej usługi sandboxingu, Impello.ai. Gdy w systemie zachodzi duża zmiana, w kilka chwil mogę ją sobie zwizualizować. Diagramów można oczywiście budować różne rodzaje, ale Mermaid sprawdza się bardzo dobrze. Mam gotową umiejętność (w Claude Code: tzw. skill) do tworzenia dobrych diagramów Mermaid; poza tym przydaje się „Show Me” od Human Layer — zapisuje zmiany i logikę w postaci pseudokodu albo drzewa wywołań i dorzuca do tego mini-diagramy.

Warto też wspomnieć o mojej modyfikacji (modzie) do Claude Code — panelu diagramów. Pokazuje on po prawej stronie wszystko, co Claude narobił podczas sesji. To nieocenione, gdy wracasz do dawnej sesji albo przełączasz się między zadaniami: w dwóch minutach wiesz, gdzie obecnie jesteśmy i co już zrobiliśmy. Moda udostępniam za darmo, razem z resztą moich darmowych modyfikacji, z których korzysta już sporo doświadczonych inżynierów.

HTML: wykłady Feynmana z ożywionymi diagramami

Karpathy twierdzi, że jeszcze lepiej jest poprosić o wynik w HTML-u. Trafiłem na znakomity przykład: ktoś opisywał, że czyta wykłady Feynmana tak, jak Feynman sobie to wymarzył — każdemu rozdziałowi towarzyszą generowane przez AI interaktywne demonstracje. Sam studiowałem fizykę i w trakcie studiów przeczytałem całe wykłady Feynmana, więc naturalnie zastanowiłem się: co jeśli poproszę Claude’a o coś podobnego? Wyszło naprawdę ładnie.

(Informacja dodatkowa: „The Feynman Lectures on Physics” — klasyczny, trzytomowy kurs fizyki oparty na wykładach Richarda Feynmana w Caltechu, uważany za jedną z najlepiej napisanych książek dydaktycznych w historii nauki.)

Po kliknięciu w „Wykłady Feynmana” po prawej stronie otwiera się rozdział pierwszy. Claude przeanalizował rysunki Feynmana i ich opisy, odtworzył styl jego szkiców — a potem go ożywił. Mogę obejrzeć ruchy Browna w akcji, zatrzymać obraz w dowolnym momencie i zobaczyć, że właśnie ta cząstka wyparowała i oderwała się od reszty. A co się stanie, gdy podkręcę temperaturę? Paruje i odrywa się ich coraz więcej — dokładnie tak, jak widać na ekranie. Szczerze żałuję, że na studiach nie prowadziłem notatek w ten sposób. Gdybym kazał robić interaktywne diagramy wyjaśniające kolejne idee, moja znajomość fizyki byłaby dziś głębsza i mocniejsza. Chyba poproszę Claude’a o opracowanie całego cyklu, bo na razie zrobił tylko kilka rozdziałów.

Jestem przekonany, że właśnie w fizyce ten format działa wybitnie, bo każdy statyczny diagram z podręcznika dało się „ożyć”. A jeśli sam studiujesz albo masz dzieci na studiach — gorąco polecam wykupić im Claude Code albo Codex. Tworząc takie interaktywne materiały HTML, będą w stanie nauczyć się danego przedmiotu głębiej niż jakiekolwiek pokolenie przed nimi, które przerabiało ten sam kurs.

Nie obeszło się bez potknięć: przy pierwszym podejściu część diagramów i demonstracji wyszła błędnie i zamiast pomagać, mieszała w głowie. Ustawiłem więc Claude’owi obieg z podagentami: dla każdego rozdziału pracował budowniczy, potem recenzent odpowiedzialny za zrozumiałość, a na końcu recenzent od fizyki, który pilnował, by prawa fizyki nie zostały wypaczone.

HTML na co dzień: fabryka oprogramowania na Slacku

W codziennej pracy artefakty HTML służą mi przede wszystkim do prowadzenia moich fabryk oprogramowania. W moich repozytoriach scala się miesięcznie około 3–4 tysięcy pull requestów. Nie lubię tej liczby traktować jako miary czegokolwiek, ale daje wyobrażenie o skali, z którą mam do czynienia. Większość zmian jest niewielka lub średnia i scala się automatycznie. Część jednak wymaga mojej decyzji, bo dotyka na przykład SDK, uwierzytelniania, płatności, kwestii prawnych albo wydzielonych przeze mnie domen aplikacji. Fabryka działa na Slacku całą dobę — i gdy pojawia się rozstrzygnięcie, którego agent nie może dokonać sam (bo takie decyzje kazałem sobie zostawiać), dostaję na kanale wiadomość z artefaktem, który błyskawicznie przybliża sytuację. Wiem od razu, na co patrzę, jakie sprawdzenia przeszły i jakie pytania agent jeszcze do mnie ma.

Jeden z pierwszych przykładów był trochę zagmatwiony, więc pokażę prostszy: fabryka wdrażała logowanie przez GitHub. Zmiana przeszła przez całą baterię weryfikacji, a artefakt pokazał mi makietę widoku, który zobaczą członkowie na stronie, wyjaśnił, gdzie nowy ekran wpisuje się w szerszą całość, wymienił rzeczy, których agent nie mógł załatwić bez mnie, i przytoczył treść krótkiego komunikatu (tzw. toast). Dalej: zwięzły przegląd działania systemu, lista wykonanych testów, informacja, że przetestowano dwa przepływy użytkownika i że w pierwszej rundzie przeglądu nie znaleziono ani jednego błędu. Ponieważ zmiana dotyka uwierzytelniania — a to strefa podwyższonego ryzyka — agent poprosił o zgodę na scalenie pull requesta. Klikam „scal”, robot wraca do sesji, w której padło pytanie, i dopina zmianę.

Każdy artefakt HTML wygląda u mnie trochę inaczej. Nie trzymam jednego szablonu, bo chcę, by forma materiału odpowiadała sytuacji, a nie odgórnie przyjętemu schematowi. Osobny artefakt mam na przykład dla bramek: pokazuje dowód, że bramka faktycznie zadziałała, zrzuty ekranu z działającej aplikacji i pomocnicze wizualizacje. Patrzę, stwierdzam, że wygląda dobrze — i scalam.

Krótko mówiąc: artefakty HTML służą mi do błyskawicznego nadrabiania kontekstu. Gdy któryś z agentów pracujących w tle, całą dobę, ma pytanie — zadaje je tutaj, ja w chwilę orientuję się w sytuacji i podejmuję decyzję ze świadomością faktów. Owszem, oznacza to, że każda decyzja w fabryce wiąże się z przygotowaniem artefaktu do przejrzenia. Ale moja uwaga jest drogim zasobem, a tokeny kosztują przy niej grosze — więc w ogóle nie przeszkadza mi, że agent zużywa trochę mocy obliczeniowej na przygotowanie materiału. Wąskim gardłem jest uwaga, nie budżet na tokeny.

Szerszym kontekstem — projektowaniem bazy kodu, pętlami weryfikacyjnymi, modelami System 1, rojami agentów i wreszcie całą fabryką — zajmuję się na kursie „Software Factory Engineer”, którego nowa edycja rusza lada dzień; do tego dochodzą żywe konsultacje i gwarancja zwrotu pieniędzy przez 30 dni. Zapisy zamykają się wkrótce; w poprzedniej edycji nikt z gwarancji nie skorzystał, bo każdy znalazł w kursie wartość — wśród uczestników było wielu inżynierów z największych firm świata.

(Informacja dodatkowa: „System 1” to nawiązanie do podziału z „Myślenia szybkiego i wolnego” Daniela Kahnemana — szybkie, intuicyjne przetwarzanie; w kontekście agentów oznacza tanie, sprawne modele zlecanie do zadań rutynowych.)

Interaktywne plany od zespołu Claude Code

Inżynier z zespołu Claude Code opowiadał z kolei o tworzonej właśnie umiejętności do budowania lepszych planów w HTML-u. Wygląda to tak: możesz przeklikać kilka proponowanych makiet i wybrać tę, która Ci pasuje; po lewej stronie widnieje lista pytań otwartych, na które odpowiadasz, przechodząc między wariantami. Możesz też poklikać po interfejsie i obejrzeć stany, które zobaczyłby użytkownik. Na samym końcu, po wybraniu wszystkich opcji, naciskasz „skopiuj odpowiedź”, wklejasz ją z powrotem do Claude’a — i ten bierze się za wdrożenie. Rozwiązanie udostępniono jako wtyczkę do pobrania. Bardzo podoba mi się ten sposób myślenia: interaktywne artefakty HTML spisują się także przy samym podejmowaniu decyzji.

Wideo wyjaśniające: format z największą przyszłością

Ostatni format wymieniony przez Karpathy’ego — i ten, w który, jak sam mówi, wierzy najbardziej — to w pełni autorskie filmy wyjaśniające. Wiadomo już, że Opus 5.5 znakomicie radzi sobie z teledyskami, zwłaszcza takimi jak ten, który wymagał mnóstwa animacji. To mój ulubiony teledysk dotąd: obejrzałem go z uczuciem „wow”, bo trójwymiarowe możliwości modelu robią wrażenie. Postanowiłem więc świadomie na nich polegać.

Jeden z filmów wyjaśniających, które Claude zrobił dla mnie, a które najbardziej mi się podobały, powstał jakieś dwa tygodnie temu. Wybrałem się z przyjacielem do kawiarni planszówkowej, gdzie graliśmy w „Tokyo Highway”. I pomyślałem: co jeśli przekażę Claude’owi zasady — zrobi mi film tłumaczący całą grę? I zrobił to znakomicie: wideo 3D z piękną pracą kamery, pokazujące, które posunięcia są w grze dozwolone, a których nie. Po około siedmiu minutach rozumiałem zasady praktycznie w całości. Sam prompt był przy tym krótki: „zrób film wyjaśniający, jak się gra: ElevenLabs CLI, animacje 3D, dużo diagramów, bez tekstu”.

(Informacja dodatkowa: „Tokyo Highway” — planszówka, w której gracze budują z podpór i belek kolejne odcinki tokijskich estakad i ustawiają na nich samochodziki.)

(Informacja dodatkowa: ElevenLabs — firma znana głównie z syntezy mowy; jej interfejs wiersza poleceń autor używa do produkcji materiałów wideo.)

Takich trójwymiarowych filmów nie zamawiam codziennie. Codzienna aplikacja jest inna: szybkie oswajanie nowych technologii. Meta niedawno udostępniła na licencji open source projekt Rebalancer; zabrałem się za lekturę ich posta inżynierskiego i pomyślałem, że najpierw przydałby mi się rzut oka na całość. W Slacku wrzuciłem tweeta mojemu agentowi, a ten w jakieś cztery minuty wyprodukował film wyjaśniający, jak Rebalancer działa od środka — z masą diagramów i przykładów. Dzięki temu, gdy sięgnąłem po szczegóły, miałem już w głowie obraz całości i widziałem, jak wszystkie elementy się składają.

Planuję teraz wpleść to w moją fabrykę oprogramowania: wyobrażam sobie, że każdego ranka będę oglądał krótkie wideo z przeglądem wszystkiego, co zmieniło się nocą w zespołach i projektach. Jeszcze nad tym pracuję. Ale najbardziej podoba mi się w tym wszystkim co innego: codziennie oglądam około godziny filmów wyjaśniających generowanych przez AI — o wszystkich tematach, które mnie interesują. Jestem niemal pewien, że Karpathy robi pod spodem coś bardzo podobnego, bo przecież sam przyznał, że filmy wyjaśniające to format, w który wierzy najbardziej. Nad pomysłem wciąż eksperymentuję; wszystko, czego się przy okazji nauczę, będę publikował w newsletterze oraz na kursie „Software Factory Engineer”.