O czym jest ten film
- Autor buduje w Claude Code agenta, który uczy w stylu Andreja Karpathy’ego — to nie klon głosu ani parodia, lecz odtworzenie sposobu, w jaki ten człowiek tłumaczy zagadnienia.
- Kontekst postaci: Karpathy był w gronie założycieli OpenAI (2015), pięć lat kierował zespołem wizji komputerowej w Tesli przy Autopilocie, założył Eureka Labs, a od maja 2026 r. pracuje w zespole pre-trainingu Anthropic.
- Motywacja: prośba do Claude o wyjaśnienie często kończy się przegadaniem tematu i zmyślaniem faktów; Karpathy sam publicznie narzekał, że Claude Code „chce pisać kod, a nie wyjaśniać”.
- Główna teza: o jakości tego, co zbudujesz z AI, decyduje wiedza ekspercka wpisana w system — a taką wiedzę można zebrać, uporządkować i podłączyć do własnych przepływów pracy.
- Krok 1: równoległe, automatyczne pobranie publicznych wypowiedzi Karpathy’ego (blog, napisy z YouTube, GitHub, posty na X) — ponad 700 tys. słów w 45–60 minut.
- Krok 2: kompilacja surowych materiałów w wiki według metody, którą Karpathy sam opisał — strony, indeks, dziennik i wzajemne powiązania; warstwa wizualna w Obsidian.
- Krok 3: wyciągnięcie siedmiu reguł dydaktycznych, każda z dokładnym cytatem i odnośnikiem do źródła; bez źródła agent musi przyznać, że wnioskuje.
- Krok 4: reguły trafiają do podagenta i polecenia
/karpathy-teachz listą kontrolną oceny; dochodzi „bramka uruchomienia”, blokująca odpowiedzi oparte na nieprzetestowanym kodzie. - Testy: tokenizer BPE zbudowany i wytłumaczony kawałek po kawałku oraz recenzja skryptu, który „działał” tylko w jednym środowisku (awaria na emoji w konsoli Windows).
- System uczy się dalej: polecenie ingest z nowym linkiem samo dopisuje źródło i odświeża powiązane strony; puenta brzmi: „myślenie możesz zlecić, zrozumienia nie”.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wpisana w system wiedza eksperta decyduje o jakości pracy z AI
Na czym polega: Autor nie jest badaczem uczenia maszynowego, ale zbudował agenta, który dysponuje całością publicznej wiedzy człowieka, który jest. Rozmawia z tą bazą, aż coś zrozumie, a potem wpienia zdobytą wiedzę we własne umiejętności i przepływy.
Jak stosować: Zamiast walczyć o ekspertyzę we wszystkim, wybierz jedną osobę, której myślenie chcesz mieć pod ręką, i przenieś jej publiczne materiały do swojego projektu. Odpytuj, dopóki temat nie zrobi się jasny.
Na co uważać: To przyspieszacz nauki, nie zamiennik własnego rozumienia — bez niego szybko oddasz klientowi kod, którego nie potrafisz obronić.
2.Surowa masa tekstów to za mało — skompiluj ją w wiki
Na czym polega: 700 tys. słów w jednym folderze to stog siana: model nie potrafi sensownie przez to przebrnąć. Karpathy opisał metodę, w której model porządkuje surowce w wiki — strony, indeks, dziennik i relacje między pojęciami — nie ruszając oryginalnych plików.
Jak stosować: Po każdym pobraniu nowych materiałów przepuść je przez taki proces kompilacji. Surowy katalog zostaw nietknięty jako źródło prawdy, a wiki traktuj jako warstwę pochodną, którą można w każdej chwili przebudować.
Na co uważać: Wiki żyje tylko wtedy, gdy wrzucasz do niej kolejne materiały — przy jednym starym zbiorze szybko zrobi się z niej martwy notatnik.
3.Pobieraj źródła równolegle: jeden agent na jedno źródło
Na czym polega: Napisy z YouTube autor pobrał darmowymi pakietami YouTube Transcript API i yt-dlp, a posty z X przez płatne API twitterapi.io — każdy post Karpathy’ego od 2023 r. za około dolara. Osobny agent na każde źródło skrócił całość do 45–60 minut.
Jak stosować: W prompcie wskaż źródło, narzędzie i zasadę „jeden agent na źródło”, a na końcu każ zapisać raport z tego, co faktycznie pobrano.
Na co uważać: Część treści bywa za paywallem lub za ścianą techniczną — bez raportu łatwo nie zauważyć, że połowa materiałów w ogóle nie dotarła do folderu.
4.Reguła bez cytatu to zgadywanie — żądaj ścieżki do źródła
Na czym polega: Każda reguła wyciągnięta z wiki musi być poparta dokładnym cytatem i miejscem, z którego pochodzi. Kliknięcie cytatu otwiera stronę źródłową ze znacznikiem czasu lub odnośnikiem, a gdy źródła nie ma, agent ma obowiązek wprost przyznać, że wnioskuje.
Jak stosować: Przy budowie własnych zestawów reguł zablokuj przyjmowanie reguły „z powietrza” — bez odnośnika do konkretnej wypowiedzi reguła nie wchodzi do systemu.
Na co uważać: Modele chętnie uogólniają i przypisują ekspertowi wnioski, których ten nigdy nie sformułował; bez wymuszonego cytowania basen „reguł” zapełni się zmyśleniami.
5.Siedem reguł Karpathy’ego sprawdza się jako checklista oceny
Na czym polega: Z materiałów wypłynęło siedem reguł: zbuduj to, inaczej nie rozumiesz; najpierw najważniejszy element, potem dokładnie jedna rzecz naraz; przewiduj, uruchom, porównaj; pokaż wersję błędną; dowodź zamiast deklarować; mów wprost o założeniach; prościej znaczy lepiej.
Jak stosować: Wklej tę listę jako rubrykę oceny odpowiedzi agenta — po jednej linijce na regułę — i wymagaj, by przy każdym kroku wskazywał, którą regułą się kierował.
Na co uważać: Reguła oparta na jednym źródle jest krucha; gdy dopłyną nowe materiały, sprawdź, czy dana zasada się utrzymuje, czy była tylko jednorazową uwagą.
6.Wiedzę ekspercką zamykaj w podagencie, nie w bieżącej rozmowie
Na czym polega: Podagent to osobna instancja Claude z własnymi instrukcjami, pamięcią i oknem kontekstowym — zadanie przekazane podagentowi nie ciągnie za sobą całej dotychczasowej rozmowy. W pliku mieszczą się reguły, styl wypowiedzi i pętla wykonywana przy każdym zleceniu.
Jak stosować: Stwórz plik podagenta dla każdej domeny wiedzy i wywołuj go do konkretnych zadań, zamiast wklejać całą wiedzę do każdego czatu.
Na co uważać: Osobny kontekst to osobne ograniczenia — wszystko, co podagent ma wiedzieć, musi znaleźć się w jego instrukcji, bo historia waszej rozmowy do niego nie trafi.
7.Zrób z tego polecenie, które samo ocenia swoją odpowiedź
Na czym polega: Drugi plik to umiejętność (tzw. skill): wpisanie /karpathy-teach plus temat, na którym się utknęło, kieruje zlecenie do agenta z regułami, a odpowiedź jest oceniana na tle listy kontrolnej — po jednej linijce na regułę — z widocznym wynikiem.
Jak stosować: Ten sam schemat zbuduj dla dowolnej dziedziny: nauczyciel sprzedaży, autor podręcznika, coach — wszędzie lista reguł plus automatyczna samoocena.
Na co uważać: Checklista weryfikuje zgodność z regułami, a nie prawdziwość merytoryczną — efekty nadal warto skonfrontować z rzeczywistością.
8.Blokuj odpowiedzi oparte na nieuruchomionym kodzie
Na czym polega: Do agenta doczepiono hook — niewielki skrypt odpalany w momencie, gdy agent chce zakończyć turę. Jeśli napisał kod i go nie uruchomił, odpowiedź zostaje zablokowana i wraca z komunikatem: „uruchom to, zanim powiesz, że działa”. To wbudowana pętla weryfikacji, wpisująca się w regułę Karpathy’ego o nieoddawaniu nieprzetestowanego kodu.
Jak stosować: W Claude Code nie piszesz takiego haka sam — wystarczy poprosić o niego promptem, a agent doda go do konfiguracji.
Na co uważać: Bramka wykrywa brak uruchomienia, a nie wszystkie błędy — kod może „działać” w wąskim zestawie warunków i przez bramkę przejść.
9.Przed oddaniem klientowi patrz „oczami klienta” i testuj w realnych warunkjach
Na czym polega: Jedno pytanie — „czy klient by to przyjął i co kazałby skasować?” — wystarczy, by uruchomić recenzję. W przykładzie ze skryptem pobierającym komentarze z YouTube agent przewidział awarię na emoji w zwykłym terminalu Windows, uruchomił kod właśnie tam, pokazał padnięcie, potem skrócił skrut do tego, co coś wnosi, i udowodnił równoważność obu wersji, uruchamiając je obok siebie.
Jak stosować: Włącz taką recenzję jako obowiązkowy etap przed wysyłką i zawsze wymagaj dowodu w postaci porównawczego uruchomienia, a nie zapewnienia.
Na co uważać: „U mnie działało” to nie wynik testu, tylko anegdota — pytaj zawsze, w jakim środowisku i na jakich danych kod sprawdzano.
10.Zaplanuj wzrost: nowe źródło ma samo aktualizować całą wiki
Na czym polega: Polecenie ingest z linkiem dopisuje stronę źródłową, odświeża wszystkie dotknięte strony, indeks i dziennik. W filmie jeden nowy post wzmocnił regułę szóstą o dopytywanie przy niedoprecyzowanych zleceniach — a reguła „siedząca na ławce” z jednym źródłem zyskała drugie i stała się pełnoprawną zasadą.
Jak stosować: Nawiązując do lipcowej metody Karpathy’ego — dziesięć minut swobodnego mówienia do modelu, który potem porządkuje tekst — regularnie wrzucaj nowe materiały i pozwól systemowi samemu przesycać powiązania.
Na co uważać: Automatyczne łączenie bywa zbyt gorliwe i tworzy relacje, których nie ma — co jakiś czas przejrzyj nowo dodane odsyłacze.
Redakcyjne tłumaczenie
To nie jest Claude, którego znasz
Właśnie zamieniłem jednego z najważniejszych umysłów dzisiejszej AI w agenta opartego na Claude. Andrej Karpathy — czołowy inżynier Anthropic, współzałożyciel OpenAI i człowiek, o którym mówi się, że nikt żyjący nie wyjaśnia AI lepiej niż on. Dziś pokażę cztery kroki, dzięki którym jego sposób myślenia trafi do waszego własnego agenta.
Szybkie przypomnienie, kim jest ta postać. Karpathy znalazł się w gronie założycieli OpenAI w 2015 roku. Potem przez blisko pięć lat odpowiadał za AI w Tesli, stojąc na czele zespołu wizji komputerowej pracującego nad Autopilotem. Następnie odszedł, by zająć się edukacją na pełny etat, i założył Eureka Labs. Od maja tego roku pracuje w Anthropic w zespole pre-trainingu — czyli w grupie, która trenuje modele Claude jeszcze przed ich udostępnieniem publiczności. (Informacja dodatkowa: „pre-training” to wstępny etap uczenia modelu na ogromnym zbiorze tekstów, zanim trafi on do dalszego doszlifowania.) Przy okazji nagrywa mnóstwo filmów i kursów o budowaniu z AI.
Nie klon człowieka, lecz klon sposobu myślenia
Dzisiejsza konstrukcja nie jest klonem głosu Karpathy’ego ani jego parodią. To agent, który kryje w sobie sposób, w jaki — zdaniem powszechnym — najlepszy nauczyciel AI tłumaczy zagadnienia, i uczy was dokładnie tak samo. Trzyma się siedmiu reguł wywodzących się wprost z jego tekstów, blogów i wykładów: zbuduj najpierw najmniejszą wersję, przewiduj, co się stanie, zanim uruchomisz kod, pokaż wersję błędną i nigdy nie oddawaj kodu, którego sam nie uruchomiłeś. Nie chodzi o kopiowanie człowieka, tylko o skopiowanie sposobu, w jaki pracuje jego głowa.
Dlaczego w ogóle to budować
Zastanówcie się, co się dzieje, gdy poprosicie Claude o wyjaśnienie czegoś, czego nie rozumiecie. Zwykle jedna z dwóch rzeczy: albo przegaduje temat, albo po drodze coś zmyśli. Efekt i tak ten sam — wychodzicie z poczuciem, że nie zrozumieliście nic, a zamęt tylko się pogłębił. A jeśli budujecie coś dla klienta, właśnie tak trafia do niego kod, którego nie potraficie naprawić ani wytłumaczyć, gdy się wysypie.
Karpathy wpadł na dokładnie ten sam problem. W sierpniu zeszłego roku napisał publicznie, że próbował zmusić Claude Code, żeby uczył go w trakcie pisania kodu. W jego własnych słowach: nie działało to wcale, bo model o wiele bardziej chce pisać kod niż cokolwiek wyjaśniać po drodze.
Agent zbudowany w ten sposób prostuje najgorszy nawyk sztucznej inteligencji: robienie wrażenia, że ma rację, zamiast faktycznego jej posiadania.
Jest też powód ważniejszy. O jakości tego, co zbudujecie z pomocą AI, decyduje wiedza ekspercka wpisana w system — a ekspertem od wszystkiego nikt z nas nie będzie. Ja nie jestem badaczem uczenia maszynowego. Mogę natomiast kazać agentom zebrać wszystko, co powiedział prawdziwy ekspert, ułożyć z tego coś, z czym Claude potrafi pracować, a potem rozmawiać z tym, aż zrozumiem. Gdy już rozumiem lepiej, cała ta wiedza leży w moim projekcie i mogę wpiąć ją we własne umiejętności, agentów i przepływy pracy. Dokładnie to robimy dziś z Karpathym. A kiedy zrobicie to raz z nim, zrobicie z praktycznie każdym: z ulubionym trenerem sprzedaży, autorem, którego cenicie, czy coachem, któremu już teraz płacicie. Zawsze są to te same cztery kroki — tak właśnie buduje się swego rodzaju „drugi mózg”.
Na marginesie: przygotowałem dla was całkowicie darmowy zestaw AI OS kit do budowania i skalowania systemów operacyjnych opartych na AI. Połączenie czegoś takiego z „mózgiem” Karpathy’ego daje ogromny przeskok — właśnie dlatego nadążam z tyloma projektami. Link znajdziecie w opisie. Ale wracajmy do dzieła.
Krok 1: wessać do projektu wszystko, co Karpathy kiedykolwiek powiedział
Całość zbuduję w Claude Code. Do przejścia jest sześć promptów — wszystkie pokażę na ekranie, więc wystarczy zrzut ekranu i wklejenie do własnego środowiska.
Po pierwsze Claude potrzebuje wszystkiego, co siedzi w głowie Karpathy’ego: blogów, transkrypcji wykładów, repozytoriów na GitHubie, postów na X. Wszystko to jest publiczne i zasadniczo darmowe. Problem w tym, że Claude Code nie zawsze poradzi sobie z pobraniem — część treści może siedzieć za paywallem albo za ścianą techniczną. Napisy z YouTube kazałem ciągnąć dwoma darmowymi pakietami Pythona: YouTube Transcript API i yt-dlp. Z serwisu X korzystam z API twitterapi.io — płatnym, ale pobrałem nim praktycznie każdy post Karpathy’ego od 2023 roku i kosztowało to około dolara. To naprawdę tania usługa.
Prompt do automatycznego pobierania mówi modelowi, skąd brać materiały i jakiego narzędzia użyć dla każdego źródła. Każę też uruchomić osobnego agenta na każde źródło, żeby wszystko szło równolegle i nie trwało wiekami. Do tego model ma zapisać, co dokładnie pobrał, żeby dało się to sprawdzić. Całość zajęła mi od 45 minut do godziny. Efekt? Jeden surowy katalog z podfolderem na każde źródło — i ponad 700 000 słów wprost od Andreja Karpathy’ego.
Krok 2: wiki — surowce porządkuje model według przepisu samego Karpathy’ego
Moglibyśmy tu przestać i po prostu wskazać Claude’owi ten folder, ale taka chaotyczna masa słów nie układa się modelowi w głowie w nic, przez co potrafi sensownie przerzucić. To za duży bałagan — szukanie igły w stogu siana.
Dlatego zrobimy to, do czego Karpathy nawoływał wszystkich w kwietniu. Opisał wtedy, jak sam każe modelowi językowemu kompilować surowe źródła w wiki: pierwotne pliki pozostają nietknięte, a model czyta je wszystkie, scala w strony, prowadzi indeks i dziennik. Dzięki temu można sensownie odpytywać taką strukturę, bo między elementami istnieją relacje. Cały pomysł spakował w gista. (Informacja dodatkowa: „gist” to krótki, publicznie dostępny fragment tekstu lub kodu udostępniony w serwisie GitHub.) Link jest w opisie filmu — to właśnie wkleimy agentowi.
Jest w tym sporo ironii: mózg Karpathy’ego będziemy przechowywać w systemie pamięci wiki opartym na modelach językowych, który Karpathy sam wymyślił. Jeśli śledzicie mnie od dłuższego czasu, wiecie, że nagrałem o tym sporo materiałów i mam w swoim „systemie operacyjnym AI” kilka takich wiki.
Drugi prompt ustawia wiki: wklejacie gista i każecie Claude’owi zastosować go na surowym katalogu, czyli na wszystkim, co przed chwilą pobrał. Na wyjściu dostajemy wiki wyświetlaną w Obsidianie. (Informacja dodatkowa: Obsidian to darmowy edytor notatek zapisywanych jako pliki Markdown, który dobrze pokazuje powiązania między stronami.) Obsidian to tylko warstwa wizualna — nie jest potrzebny, ale jeśli chcecie obejrzeć wiki oczami, się sprawdza.
Widzimy tu źródła, po jednej stronie na każdą rzecz, którą Karpathy napisał albo powiedział. Widzimy tematy, którymi się zajmuje, zasady, reguły i metody, a także to, jak wyjaśnia i jak debuguje. Słowem: to, jak działa jego głowa. Fioletowe odsyłacze łączą stronę ze stroną i metodę z metodą. Każda reguła odsyła do źródła lub źródeł, z których pochodzi, a każde źródło — do reguł, które podpiera. Zamiast zwału notatek z poprzedniego kroku mamy powiązaną sieć, mapę relacji. I za każdym razem, gdy wrzucamy coś nowego — kolejny blog czy pomysł — model ponownie to wchłania i podpina do innych pojęć.
Krok 3: siedem reguł, które myślą jak on
Właśnie ten krok sprawia, że agent myśli jak Karpathy, a nie tylko wie, co Karpathy kiedyś powiedział. Trzeci prompt wyciąga z wiki reguły, przy czym każda musi iść w parze z dokładnym cytatem i miejscem pochodzenia — nie chcemy, żeby Claude cokolwiek dopowiadał od siebie.
Wyszło siedem reguł:
- Zbuduj to, inaczej nie rozumiesz.
- Najpierw najważniejszy element. Znajdź tę jedną część, która naprawdę się liczy, pokaż, że działa, i potem dodawaj dokładnie po jednej rzeczy. Na tej zasadzie zbudowany jest praktycznie cały jego kurs.
- Przewiduj, potem uruchom, potem porównaj. Przed uruchomieniem komórki podaje na głos wartość, jakiej się spodziewa — bo, jak sam mówi, w większości przypadków kod wytrenuje się bez błędu, ale będzie po cichu działał odrobinę gorzej.
- Najpierw pokaż wersję błędną. Własne błędy zostawia w nagraniach celowo.
- Udowodnij, zamiast deklarować.
- Powiedz wprost, co przyjąłeś założenie. Jego główna pretensja do Claude Code: modele formułują błędne założenia w waszym imieniu, a potem się nimi kierują, niczego nie sprawdzając.
- Prościej znaczy lepiej.
Piękne jest to, że każdą regułę można skonfrontować z oryginałem. Klikacie cytat i otwiera się strona, z której pochodzi — ze znacznikiem czasu albo dokładnym odnośnikiem. A jeśli źródła nie ma, agent ma obowiązek wprost przyznać, że wnioskuje na podstawie rzeczy, które Karpathy powiedział gdzie indziej.
Krok 4: podagent i polecenie „naucz mnie”
Reguły muszą mieszkać tam, gdzie agent faktycznie je odczyta. Czwarty prompt każe Claude’owi zamienić je w dwa pliki.
Pierwszy to podagent (sub-agent). Dla przypomnienia: to osobna instancja Claude z własnymi instrukcjami, własną pamięcią i własnym oknem kontekstowym — gdy przekazujecie jej zadanie, nie ciągnie za sobą całej waszej rozmowy. W pliku widać siedem reguł, widać, jak podagent mówi, i widać pętlę, którą wykonuje przy każdym zleceniu. To w praktyce miniagent-Karpathy.
Drugi plik to umiejętność, tzw. skill. Gdy wpisuję /karpathy-teach i temat, na którym utknąłem, zlecenie trafia do agenta z regułami, odpowiedź jest oceniana na tle listy kontrolnej — po jednej linijce na regułę — a ja widzę całość. Mamy więc dwa elementy: agenta Karpathy’ego i polecenie Karpathy’ego.
Krok 5: bramka, która nie odda kodu bez uruchomienia
Jest jeszcze jedna rzecz, kluczowa przy takiej konstrukcji: agent ma uruchamiać swój kod, zanim odpowie. Budowa w Claude Code sprzyja temu z natury, bo środowisko samo pisze i uruchamia kod. Trzeba tylko zablokować możliwość pominięcia tego kroku — co zresztą wpisuje się w reguły samego Karpathy’ego.
Piąty prompt dodaje „bramkę uruchomienia”. To hook — niewielki skrypt odpalany dokładnie w momencie, gdy agent próbuje zakończyć swoją turę. Jeśli napisał kod i go nie uruchomił, bramka blokuje odpowiedź i odsyła ją z jedną wiadomością: „uruchom to, zanim powiesz, że działa”. W ten sposób wbudowujemy pętlę weryfikacji. Oczywiście tego skryptu nie piszecie sami — po prostu prosicie o niego promptem. Od tej pory agent uruchamia, testuje, poprawia i dopiero po wszystkim pokazuje finalny efekt.
Test pierwszy: tokenizer, który uczy
Ostatni krok to oczycznie sprawdzenie całości w boju. Pierwsze z poleceń brzmiało: „zbuduj coś realnego i naucz mnie, jak to działa”. Wybrałem tokenizer typu byte pair encoding — czyli mechanizm, który zamienia tekst na liczby, nim tekst w ogóle trafi do dużego modelu językowego.
Zobaczcie, co robi. Najpierw zapisuje, co znaczy „gotowe”, zanim tknie jakikolwiek kod. Potem buduje najmniejszą wersję, która działa na maleńkim wejściu, i przed uruchomieniem mówi, czego się spodziewa. Uruchamia i pokazuje prawdziwy wynik. Następnie pokazuje wersję, która się wysypuje — i dlaczego — a potem ją naprawia. Na końcu wypisuje wszystko, co uruchomił, co z tego wyszło, co zmienił i przy której regule. Zamiast bloku kodu i zapewnienia „to działa” dostałem spacer przez program kawałek po kawałku — i naprawdę lepiej rozumiem, co się właśnie wydarzyło.
Test drugi: recenzent przed wysyłką do klienta
Można też przetestować jego rolę recenzenta. Zanim coś pójdzie do klienta, zadaję jedno pytanie: „Czy klient by to przyjął — i co kazałby skasować?”. Posłużę się skryptem, który Claude napisał dla mnie na przykład: pobiera komentarze z YouTube i u Claude przechodził bez zarzutu. Agent czyta go i przewiduje, że wysypie się na emoji w zwykłym terminalu Windows. Uruchamia go właśnie w tym środowisku — i skrypt pada, nie zdążywszy zapisać żadnego pliku. Okazuje się więc, że „działało” było prawdą tylko w jednym konkretnym ustawieniu.
Potem agent przechodzi przez kod i wycina wszystko, co nic nie wnosi. Dostaję analizę, jak to naprawić, posprzątać i zrecenzować przed oddaniem. A na koniec udowadnia, że skrócona wersja łapie te same dane — uruchamiając obie wersje obok siebie i pokazując wynik.
Mózg, który sam się dokształca
Ta konstrukcja będzie się też po prostu dalej uczyć. W lipcu Karpathy opisał, jak przez dziesięć minut gada do modelu głosem, a potem każe mu uporządkować ten tekst. U mnie działa to tak: uruchamiam /karpathy-ingest z dowolnym linkiem. Agent sprawdza surowy katalog, tworzy stronę źródłową dla nowego materiału i aktualizuje każdą stronę, której ten materiał dotyczy. Właśnie tak doszło do zmiany reguły szóstej: agent wie już, że przy zbyt ogólnikowym zleceniu powinien dopytać, a nie zgadywać. Reguła, która dotąd siedziała na ławce z jednym źródłem, zyskała drugie i stała się pełnoprawną zasadą. A skoro agent rozumie mechanikę wiki, sam odświeża też indeks, stronę bieżącą i dziennik. Mózg się poprawił dzięki dodaniu jednego linku — a ja ani razu nie ruszałem wiki ręcznie ani nie definiowałem powiązań. Co zresztą było w duchu jego reguły numer dwa.
Cztery kroki i jedna myśl na koniec
Spięcie całości. Daliśmy Claude’owi wszystko, co siedzi w głowie wybranej osoby — tu Karpathy’ego — i skompilowaliśmy w wiki. Zamieniliśmy to w reguły z cytatem przy każdej. Zmusiliśmy agenta, żeby uruchamiał kod, zanim się odezwie. I każemy mu testować na rzeczach prawdziwych.
Na koniec zdanie, które chcę wam zostawić — jedno z moich ulubionych, wypowiedziane przez niego samego w tym roku: myślenie możecie zlecić komuś innemu, ale zrozumienia już nie. Nie będziecie ekspertami od wszystkiego — i to jest w porządku. Możecie natomiast zaprosić eksperta do środka i budować na nim.