O czym jest ten film
- Gościem ostatniego w semestrze seminarium „Ekonomia a AI” na USC jest Aniket Panjwani — ekonomista (doktorat na Northwestern), były inżynier uczenia maszynowego w fintechu, który przeszkolił z agentowego AI już około 500 ekonomistów.
- Punktem wyjścia jest pojęcie „skilla”: pakietu instrukcji rozszerzającego możliwości agenta kodującego — w wyobraźni to schowek z gotowymi poleceniami, które jednym ruchem wkleja się do prompta.
- Przykłady z praktyki: skill zbierający transkrypty spotkań (Fathom), skill „przesłuchanie” wymuszający nieustępliwą sesję pytań, standardy różnicy w różnicach (DiD), sterowanie przeglądarką, naśladownictwo stylu pisarskiego czy cotygodniowa „pamięć projektowa” Chrisa Blattmana.
- Kluczowe rozróżnienie: agents.md (zawsze obecny w kontekście projektu) kontra skille (dociągane na żądanie) — oba mechanizmy sterują tym, co agent „widzi”.
- Błędy 1–3 dotyczą tworzenia: nie robić własnych skilli, robić ich za mało („zasada trzech powtórzeń”) oraz robić niepotrzebne — skille są tylko dla zadań powtarzalnych, nie dla jednorazowego kodu.
- Błędy 4–5 to higiena pracy: transkrypty własnych sesji to kopalnia pomysłów na nowe skille, a stare skille się dezaktualizują — trzeba je przeglądać, zwłaszcza gdy zmienia się model.
- Mechanika techniczna: skill to folder z plikiem zawierającym obowiązkowo nazwę i opis; w oknie kontekstu stale lądują tylko te drobne metadane, reszta dołączana jest dopiero na potrzeby („progresywne ujawnianie”).
- Błąd 6: brak skilli do zarządzania projektami — podłączenie skrzynki e-mail i transkryptów rozmów (Fathom, Granola) do agenta, z bezwzględnym rygorem akceptacji przed wysłaniem czegokolwiek.
- Błąd 7: niekomponowanie skilli — skille mogą wywoływać inne skille jak funkcje; przykładowy pipeline tworzenia slajdów oraz darmowy zestaw „Compound” wydawnictwa Every (brainstorm, plan, implement, przeglądy).
- Na deser: generowanie „person recenzenckich” (np. skilla w stylu Gary’ego Beckera) do krytyki własnych prac oraz ledwie wspomniany błąd ósmy — brak wersjonowania skilli w Gicie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zasada trzech powtórzeń
Na czym polega: Próg tworzenia skilla jest prosty: gdy zauważysz, że robisz w gruncie rzeczy to samo po raz trzeci, pora rozważyć skilla. Większość badaczy ma ich nie za dużo, lecz dramatycznie za mało.
Jak stosować: Przez kilka dni po każdej sesji z agentem zadawaj sobie pytanie: „czy coś z tego będę robił ponownie?”. Jeśli tak — prosto o skilla (patrz wniosek 2).
Na co uważać: Heurystyka bywa agresywna; powtarzalność to warunek konieczny, nie wystarczający — sprawdź najpierw, czy problem w ogóle „ma kształt skilla” (wniosek 3).
2.Własny skill zrobisz bez żadnej wiedzy technicznej
Na czym polega: Do tworzenia skilli służy… skill. W Codexie wywołujesz $skill creator, w Claude Code wtyczkę /skill creator, opisujesz, czego chcesz, i kreator prowadzi cię za rękę.
Jak stosować: Pierwszą próbę zrób na pierwszym powtarzalnym zadaniu, np. na pobieraniu napisów z YouTube przez yt-dlp. Możesz też po prostu zapytać agenta w trakcie sesji: „czy to odpowiedni moment, by zrobić skilla? Jeśli tak — zrób go albo zaproponuj, jaki”.
Na co uważać: Największym błędem jest żywienie się wyłącznie cudzymi skillami. Przepływy pracy ekonomisty są zbyt specyficzne — cudze zestawy traktuj jako inspirację, nie rozwiązanie.
3.Odróżniaj problemy „o kształcie skilla” od zwykłych zadań
Na czym polega: Skille służą zadaniom, które się powtarzają, wraz z twoimi standardami ich wykonywania. Jednorazowy kod — np. czyszczenie danych pod konkretny artykuł — skilla nie wymaga.
Jak stosować: Test na przykładzie branży płatków śniadaniowych: pobranie cen rynkowych — zwykły kod; wyciągnięcie danych producentów z dziesiątek tysięcy PDF-ów — też nie skilla (kod ekstrahujący tekst plus proste odpytanie modelu o strukturę); dopiero ocena przydatności 120 prac wg twoich kryteriów, uruchamiana równolegle przez podagenty — to skilla.
Na co uważać: Samo pytanie do agenta „czy to na skilla?” to odpowiedź częściowa — w złożonych sytuacjach wyczucie nabiera się dopiero praktyką. Zwróć też uwagę na zadania pośrednie: standardowy przegląd kodu czyszczącego dane (raport o wszystkich istotnych decyzjach próbkowych) już zasługuje na skilla.
4.Kop w transkryptach własnych sesji
Na czym polega: Claude Code i Codex domyślnie zapisują na dysku pełne transkrypty sesji (katalog domowy, pliki z timestampami). To najbardziej osobiste i niedoceniane źródło pomysłów na skille — oraz pamięć, co i kiedy robiłeś.
Jak stosować: Powiedz agentowi: „przejrzyj moje sesje z ostatnich tygodni, w tym projekcie i poza nim, i wskaż powtarzalne przepływy, które nadają się na skille”. Działa też archeologia: „dwa tygodnie temu rozmawialiśmy o jakimś zbiorze — znajdź, gdzie on leżał”.
Na co uważać: Claude Code kasuje transkrypty po około 30 dniach (Codex trzyma dłużej) — warto zbudować automat zrzucający je do bazy. I pracuj w interfejsie „code”, nie w czacie: ten drugi jest bardziej ograniczony i gorzej się do tego nadaje.
5.Zrozum koszt kontekstowy skilli i mechanizm „progresywnego ujawniania”
Na czym polega: W każdym oknie kontekstu skille są obecne tylko nazwą i opisem (po ok. 100 tokenów). Pełna treść — np. kolejne 5 tys. tokenów — dołączana jest dopiero, gdy agent uzna skilla za istotny dla twojej wiadomości lub wywołasz go jawnie.
Jak stosować: Sto skilli to w nagłówku ok. 10 tys. tokenów z 258 tys. — to akceptowalny koszt za setki wyspecjalizowanych zachowań. Pisz nazwy i opisy tak, by się wzajemnie nie dublowały.
Na co uważać: Redundancyjne skille potrafią się „gryźć” i agent uruchamia zły. Ratunek: oznaczenie w nagłówku, że skill wolno wywoływać wyłącznie jawnie — choć tracisz wtedy wygodę swobodnej pracy, np. z telefonu na spacerze.
6.Sprzątaj skille po każdej istotnej zmianie modelu
Na czym polega: Skille mają datę ważności: zmienia się projekt (pliki już nieistniejące), pakiety, API — a nade wszystko modele. Instrukcje niezbędne rok temu (np. tłumaczenie agentowi, czym jest Stata) dziś tylko zawadzają.
Jak stosować: Gdy laboratorium publikuje wytyczne do nowego modelu, wrzuć je agentowi z poleceniem: „przejrzyj moje skille w świetle tych wskazówek i zaproponuj zmiany”. Z testów osób, którym prelegent ufa, wynika zysk rzędu 30–40% wydajności.
Na co uważać: Nie każda stara instrukcja to balast. Przy modelach lokalnych i mniejszych (np. przy danych objętych restrykcjami) „podręcznikowe” skille mogą wrócić do łask — przetestuj hipotezę, zanim coś skasujesz.
7.Podłącz e-mail i transkrypty rozmów — z zabezpieczeniami
Na czym polega: Według prelegenta dwa najcenniejsze skille to te obsługujące pocztę i przeszukiwanie transkryptów rozmów. Dają kontekt dla wszystkich projektów, pozwalają od razu po spotkaniu działać na ustaleniach (także pisać do współautora na WhatsAppie) i zlecać agentowi formalności typu rozliczenia.
Jak stosować: Fathom do wideorozmów (darmowy plan, API, zachowuje audio) plus Granola (ok. 10 USD miesięcznie za API, do spotkań bez kamery); transkrypty automatycznie zrzucaj do centralnego katalogu. Wtyczki e-mail łączą jedną skrzynkę — więcej kont koordynuje się narzędziem typu gogcli.
Na co uważać: Do umieść w skillu pocztowym bezwzględną klauzulę: „najpierw szkic, nigdy nie wysyłaj bez mojej akceptacji”. Kwestia prywatności to indywidualna decyzja — alternatywą bywają modele lokalne.
8.Komponuj skille jak funkcje
Na czym polega: Skille mogą wywoływać inne skille — dokładnie jak funkcje w kodzie. Zamiast jednego gigantycznego promptu powstaje pipeline etapów przekazujących sobie pałeczkę.
Jak stosować: Przykład ze slajdów: „zrób deck z tego artykułu” kończy się śmietnikiem, więc proces się dzieli — najpierw sama treść w punktach w pliku tekstowym (pomaga minutna „paplanina” i skill dzielący ją na slajdy), potem osobny etap decyzji wizualnych: wykres, figura, obrazek.
Na co uważać: Modele słabo radzą sobie z niektórymi aspektami komunikacji i smaku — o kształcie i kompozycji przepływu wciąż decyduje człowiek, nie agent.
9.Wykorzystaj gotowy, skomponowany zestaw „Compound” od Every
Na czym polega: Wydawnictwo Every udostępnia (przy prenumeracie ok. 100 USD rocznie) darmowe skille jako wtyczkę do Claude Code i Codexa: brainstorm, plan, implement, POV, przeglądy dokumentów i kodu.
Jak stosować: Dla doktoranta na świeżym projekcie duet brainstorm (co robić) i plan (w jakiej kolejności) jest wyjątkowo użyteczny; implement to standardowy sposób, w jaki ma powstawać kod.
Na co uważać: Skill do przeglądu kodu często rzuca się na bezpieczeństwo i wstrzyknięcia SQL — ekonomiście zwykle zbędne. POV prelegent poleca z zastrzeżeniami.
10.Zbuduj własną „izbę recenzentów” i trzymaj skille w Gicie
Na czym polega: Słynni ekonomiści są głęboko „osadzeni w wagach” modeli granicznych — agent potrafi z własnej wiedzy stworzyć skilla-krytyka, który przyjrzy się twojemu manuskryptowi oczami Gary’ego Beckera czy Larsa Petera Hansena, a kilka takich person może działać równolegle.
Jak stosować: Poproś agenta o stworzenie persony recenzenckiej z twojej dziedziny, włącz ją jako skill do przeglądu dokumentów i uruchamiaj na kolejnych wersjach tekstu.
Na co uważać: To wsparcie krytyczne, nie recenzja naukowa. I ostatnia przestroga prelegenta: skille traktuj jak kod — wersjonuj je w Gicie (błąd ósmy, na który zabrakło czasu).
Redakcyjne tłumaczenie
Wprowadzenie: rok rewolucji AI w ekonomii
Prowadzący (David): To nasze ostatnie w tym semestrze seminarium z cyklu „Ekonomia a sztuczna inteligencja”. Bardzo mi miło gościć Aniketa Panjwaniego, który wyrobił sobie markę jako „ekonomista AI”. Pierwotnie miał mówić o weryfikacji, ale przeszedł na skille — a sądzę, że to nawet ciekawszy temat. Wszyscy musimy umieć weryfikować, ale najpierw trzeba zdobyć odpowiednie… umiejętności. Czekam na wystąpienie.
(Informacja dodatkowa: USC — Uniwersytet Południowej Kalifornii.)
Aniket Panjwani: Dziękuję, Davidie, dziękuję za gościnę. Będę mówić o skillach. Mam wrażenie, że rewolucja AI w ekonomii trwa od mniej więcej roku. Dla mnie wszystko wybuchło zeszłą zimą, gdy niemal wszyscy w trakcie ferii postanowili wypróbować Claude Code — i mniej więcej wtedy wielu ludziom zmieniły się sposoby pracy.
Sądzę, że większość ekonomistów już próbowała Claude Code albo Codexa — może nie na co dzień, ale próbowała. Wciąż jednak widzę powtarzające się klasy błędów. Dziś skupię się na tych, które dotyczą właśnie skilli.
Krótko o mnie: z wykształcenia jestem ekonomistą — doktorat zrobiłem na Northwestern — a potem przez kilka lat pracowałem jako data scientist i inżynier uczenia maszynowego w fintechu. W połowie 2024 roku, obok etatu, dorabiałem dla startupu, którego dyrektor techniczny rzucił: „spróbuj Cursora”. Spróbowałem — i wciągnąłem się bez reszty. Od razu zrozumiałem, że to przyszłość, i od tamtej pory korzystam z tych narzędzi codziennie.
W 2025 roku kończyłem jeszcze projekty badawcze i czasem robiłem „wspólne researchowanie” ze znajomymi: ja prowadziłem interfejs kodowania, a kolega patrzył z otwartymi ustami. Wtedy dotarło do mnie, że to musi mieć wartość dla ekonomistów. Zadzwoniłem do znajomych: „musicie siąść do tego Cursora, a teraz Claude Code”. — „Nie zawracaj mi głowy, walczę o tenure”. Po jakimś czasie napisałem jeszcze raz: „naprawdę musisz zacząć używać Claude Code”. — „No dobrze… wow”. I poszło lawinowo. Dziś przepracowałem chyba z pięciuset ekonomistami — indywidualnie i na warsztatach. Chciałbym się podzielić tym, czego się od nich nauczyłem.
(Informacja dodatkowa: Claude Code i Codex to „agentowe” narzędzia Anthropic i OpenAI — działają w terminalu użytkownika i wykonują samodzielnie całe zadania: piszą kod, czytają pliki, przeglądają sieć. „Skille” to wprowadzona w obu narzędziach mechanika rozszerzania ich zachowań.)
Czym jest skill — definicja i pierwsze przykłady
Zacznę od zdefiniowania, czym jest skill, bo niekoniecznie wszyscy to pojęcie znają — najpierw intuicyjnie, w połowie wystąpienia przyjdzie wersja formalna. I od razu: nie znam miejscowych zwyczajów seminaryjnych, więc pytajcie śmiało, od razu i w trakcie.
Najogólniej: skill to coś, co rozszerza możliwości agenta kodującego. To zestaw instrukcji, który mówi narzędziu: „kiedy natrafisz na taką sytuację, zachowaj się tak a tak”. Wygodny model w głowie: schowek z podręcznymi instrukcjami, które jednym ruchem wklejasz do prompta wysyłanego agentowi.
Fathom Research. Pierwszy przykład — skill, którego używam bardzo często. Fathom to narzędzie transkrybujące większość moich spotkań: rozmowa ze współautorem, rozmowa z klientem — transkryptor pracuje w tle. Znam te AI-owe notatniki. Różnica w moim podejściu jest taka, że domykam obieg informacji: dbam, by notatki regularnie trafiały do jednego centralnego katalogu, skąd mogę je odpytywać w każdej chwili. Korzyść? Jeśli dwa miesiące temu rozmawiałem ze współautorem o czymś, co dziś wraca — agent odnajdzie tamten kontekst i pomoże mi działać na ustaleniach sprzed czasu.
Ten skill jest długi i pełen technicznych szczegółów. Inny, który zaraz pokażę, ma raptem trzy–cztery zdania. To skill „przesłuchanie” (grilling) — również używam go często. Pozwala wejść w rodzaj… nie chciałbym powiedzieć „konfrontacyjnej”, ale nieustępliwej sesji pytań i odpowiedzi z AI. Uruchamiam go wtedy, gdy pracuję nad czymś, powstał dokument, ale czuję, że nie rozumiem go na tyle, by iść dalej bez podniesienia poziomu zrozumienia. Wpisuję $grilling — i sesja się zaczyna. Może i wy mieliście kiedyś taki pomysł. Ale samo to, że sesję zaczyna jedno polecenie, sprawia, że robi się to znacznie częściej — a więc i rozumie się własne materiały głębiej. To spora część zysku, jaki dają skille.
Pytania z sali: gdzie kończy się „z pudełka”, a zaczyna skill
David (prowadzący): Wiele funkcji agent ma od razu, po instalacji. Można przecież po prostu opisać potrzebę w rozmowie i zrobi coś zbliżonego — może nie aż tak precyzyjnie jak w twoim skrypcie, ale jednak. Gdzie więc przebiega granica między tym, co dostępne od razu, a tym, co warto przenieść do skilla?
Aniket Panjwani: Wrócę do tego za kilka slajdów, ale odpowiem już teraz. Próg, którym się kieruję: gdy coś robię po raz trzeci, robię skilla. Zresztą większość ekonomistów, z którymi rozmawiam, cierpi na niedobór skilli, a nie nadmiar — a drobne „podpychnięcia” dopasowane do mnie, doszlifowane z czasem, radykalnie poprawiają komfort pracy z narzędziem.
Głos z sali: Pytanie pokrewne. Przygotowuję dokument opisujący cały projekt — strukturę, zasady, reguły decyzyjne — i trzymam go w agents.md. To nie jest skill, rozumiem?
Aniket Panjwani: Prawdopodobnie nie — to po prostu dokument opisujący, co zamierzacie w projekcie zrobić. Ale jest blisko spokrewniony: oba mechanizmy służą sterowaniu tym, co trafia do kontekstu AI. agents.md jest tam zawsze, gdy pracujesz w danym projekcie; skille są „na żądanie”. Sesji przesłuchania nie chcesz włączać za każdym razem, ale szczegóły projektu agent znać powinien bez względu na wszystko. To jest różnica.
Przykład z branży: Pedro Santana, ekonometryk z Emory, złożył skilla opisującego jego standardy robienia rozłożonej w czasie różnicy w różnicach (difference-in-differences) oraz event study — w językach, których woli, z pakietami, które woli. Na tle pozostałych jest potężny, wręcz ogromny; sam go nie czytałem, ale daje wyobrażenie, co wszystko da się w skillu zakodować.
Głos z sali: Gdzie te skille fizycznie są?
Aniket Panjwani: Na twoim komputerze. Za chwilę opowiem, skąd się biorą i jak się je robi — własne i cudze.
Głos z sali: A czy autorzy klepią to wszystko ręcznie, czy proszą AI: „chcę to i to, napisz mi skilla”?
Aniket Panjwani: I to się zaraz okaże — przygotowałem się na te pytania.
Dalsze przykłady. Skille do sterowania przeglądarką Chrome: być może nie wiecie, że Claude Code i Codex potrafią zaskakująco łatwo operować waszą przeglądarką, a więc i całym komputerem. Chcesz podmontować animowany filmik do swojego job market paper? Proszę bardzo — Codex zmontuje wideo.
(Informacja dodatkowa: job market paper — praca, z którą doktor ekonomii startuje na akademickim rynku pracy.)
Skill „mój styl pisania” — nakłada mój głos na różne rodzaje tekstów. Krótko o tym, jak się sprawdza: najlepiej przy mailach, i to jest główne zastosowanie. Czasem przy pojedynczym slajdzie. Przy dłuższych tekstach sukcesów nie mam — wrócę do tematu AI w dłuższym pisaniu.
I przykład od Chrisa Blattmana, ekonomisty rozwoju z Uniwersytetu Chicagowskiego. Już w lutym, wcześnie w rewolucji, opisał w sieci prawdopodobnie drugi najlepszy swój skill — do zarządzania projektami. Co tydzień, dla każdego z około dziesięciu projektów badawczych, skill zbiera i integruje transkrypty wszystkich spotkań, wszystkie maile związane z projektem i dyskusje z projektowych grup na WhatsAppie, a potem generuje przegląd całości. Chris ma więc zapisaną każdą ważną decyzję i każdą ważną rozmowę. Dla skali: jeśli porównać funkcję produkcji Chrisa z waszą, on prowadzi znacznie więcej projektów i robi to wyżej — nie siedzi cały dzień w kodzie. A mimo to czerpie z tych narzędzi ogromną wartość i był wczesnym adopterem. Stąd ważna intuicja: jeśli sądzicie, że skille są tylko dla tych, którzy klepią kod po uszy — to się nie potwierdza.
Głos z sali: To się znowu wraca do tamtego skilla DiD — strony i strony przypomnień. Szybciej chyba wejść w Statę i po prostu zrobić.
Aniket Panjwani: Ten skill ustala, jak ma wyglądać DiD, gdy agent dostanie polecenie: „na tych danych napisz kod DiD”. Jedyny koszt to to, że Pedro musiał go kiedyś spisać.
Głos z sali: Ale można by zrobić spójny interfejs: „diff-in-diff stata XYZ” — i AI robi wszystko. Albo zapisuję model po łobuzersku, niedbale.
Aniket Panjwani: Zgoda. A jeśli chcesz takiego zunifikowanego interfejsu pod siebie — zrób z niego skilla.
Głos z sali: Kilka miesięcy temu zainstalowałem z sieci paczkę skilli — i o nich zapomniałem. Pamiętam o tym do pisania, ale stojąc przed konkretnym problemem nie wiem, które ze stu skilli pasują. Czasem agent sam coś wywoła i nie rozumiem, kiedy i dlaczego. Jak z tego korzystać, nie gubiąc tego, co się ma?
Aniket Panjwani: Skille mogą być przypisane do pojedynczego projektu albo działać we wszystkich. Jeśli masz sto, a używasz dziesięciu — dobrze, używaj tych dziesięciu. Te dziewięćdziesiąt coś cię kosztuje, zaraz wyjaśnię co, ale to nie jest duży koszt.
Głos z sali: Bardziej martwię się, że niedowykorzystuję dobrego skilla.
Aniket Panjwani: Za jakieś piętnaście minut pokażę dokładnie, jak bym to rozwiązał.
Głos z sali: Da się powiedzieć: „od dziś zawsze, gdy chcę DiD, używaj tego konkretnego skilla”?
Aniket Panjwani: Da się — i za kilka slajdów wyjaśnię, jak takie wywołanie przechodzi.
Błąd 1: nie tworzenie własnych skilli
Ustaliliśmy, że skille wyglądają na użyteczne. Cóż więc ekonomiści robią źle? Pierwszy błąd: nie robią skilli własnych. Na warsztatach często pytają: „gdzie znajdę skille dla siebie? jak dostać od ciebie tego DiD?”. A przecież zrobienie skilla jest za pierwszym razem zdumiewająco proste. Można pożyczać — parę użytecznych zaraz wskażę i pokażę, jak je zdobyć — ale przepływy pracy ekonomisty są bardzo specyficzne. Raczej zacznij od cudzych skilli jako inspiracji, a kiedy okaże się, że nie do końca pasują do twojego sposobu pracy, zrób własne. Pokażę, jak.
Istnieje skill do robienia skilli. W Codexie wpisujesz $skill creator, opisujesz, jakiego skilla chcesz, i kreator ci pomaga. W Claude Code jest wtyczka skill-creator — wpisujesz /skill creator i wywołujesz jej skilla. Slajdy wam zostawię, fotografujcie śmiało. Koniec końców: nie musisz wiedzieć o skillach nic, żeby skille robić. Jeśli w tym momencie uznaliście, że plecię bzdury, i nie chcecie słuchać dalej — możecie wyjść; i tak powinniście umieć pracować ze skillami, mając o nich znikome pojęcie.
Ciekawostką: podniosło rękę około połowy, może sześćdziesiąt procent sali — kto już skilla zrobił. Dobrze. Spróbujcie.
Załóżmy, że pracujecie z agentem interaktywnie, w jednym długim wątku, i podejrzewacie, że część tego, co zrobiliście, chcielibyście powtórzyć. Możecie po prostu zapytać agenta: „czy to obecnie odpowiedni moment albo powód, by zrobić skilla?”. Zaraz pokażę sytuacje, które mylą ludzi — gdy wydaje im się, że trzeba zrobić skilla, a problem wcale takiego kształtu nie ma. A potem: „jeśli tak — zrób go dla mnie albo zaproponuj, jaki”. To całkowicie rozsądny prompt na początek przygody.
Błąd 2: zbyt mało skilli — zasada trzech powtórzeń
Po marży intensywnej (brak własnych skilli) czas na ekstensywną: skilli jest za mało. Sam mam ich setki. Część jest ściśle projektowa, część „użytkownicza” — dostępna we wszystkich moich projektach.
Heurystyka, którą proponuję: gdy zauważysz, że po raz trzeci robisz w gruncie rzeczy to samo, pomyśl o skillu. Może to reguła zbyt agresywna — ale skoro ludzie wokół mają zwykle skilli trzy, spróbujcie stosować ją przez kilka dni i zobaczcie, co wyjdzie.
Przykład: skill yt-dlp. Często trafiam na długie, ciekawe wywiady na YouTube — o AI, o ekonomii, o pokera, poker lubię — a czasu na oglądanie nie mam. Rozwiązaniem jest yt-dlp: darmowe, otwarte narzędzie wiersza poleceń do pobierania wideo, audio i napisów z YouTube i nie tylko. Nawiasem mówiąc: jeśli myślicie o badaniach nad ekonomią mediów — to znakomite źródło danych, tym narzędziem da się zeskrobać YouTube na dużą skalę.
Mój przepływ wyglądał tak: podcast Dwarkesha Patela o AI, chcę zrozumieć sedno, nie mam czasu — więc proszę Codexa, by przez yt-dlp pobrał napisy i streścił mi to, co dla mnie ważne. Instalacja jest prosta: brew install, albo w ogóle proszę agenta, żeby sam to zainstalował. Wcześniej za każdym razem wystukiwałem polecenie, prostowałem agentowi błędnie dobrane argumenty, dopominałem się o podsumowanie. Teraz wpisuję yt-dlp, wklejam link — gotowe. Drobna rzecz, ale wchodzi w krew: wiesz, że masz to zrobione dla siebie, i narzędzie robi się przyjemniejsze. To nie jest skill o znaczeniu przełomowym — zaraz pokażę takie, które uważam za krytyczne — ale wzór samego myślenia: zauważyłem po raz trzeci, robię szybko skilla. Robi się je błyskawicznie.
(Informacja dodatkowa: w tym miejscu nagranie przerywa krótka wbudowana reklama usług szkoleniowych i wdrożeniowych prelegenta — pomijamy ją w tłumaczeniu.)
Błąd 3: skille niepotrzebne, czyli co ma „kształt skilla”
Kolejny błąd to robienie skilli tam, gdzie nie trzeba — czyli niezrozumienie, które problemy naprawdę ich wymagają. Ogólna zasada: skille są dla zadań, które się powtarzają.
Zeskrobanie transkryptów z YouTube i wyciągnięcie streszczenia — to ma być skill. Czyszczenie zbioru danych pod konkretny artykuł — nie. To kod pisany jednorazowo, pod jeden paper. Ale już przegląd kodu czyszczącego dane, prowadzący do raportu o wszystkich istotnych decyzjach przy budowie próby — jak najbardziej może być skill. Przecież masz wiele projektów, w których agent pisze własne, niepowtarzalne skrypty: skrobanie, łączenie, czyszczenie. Może chcesz ustandaryzowanego sposobu, w jaki drugi agent ocenia ten kod i mówi ci: na jakie decyzje uważać, gdzie szukać szczegółów, które dla ciebie mają znaczenie. To jest właśnie ta różnica.
Konkretniej: badasz branżę płatków śniadaniowych. Chcesz zebrać ceny płatków z różnych rynków — po prostu każesz Claude Code lub Codexowi napisać ten kod: powstanie scrape.py, dane zebrane, żadnego skilla nie trzeba. Ekstrahujesz informacje o producentach z dziesiątek tysięcy PDF-ów — wciąż nie skilla. Zrobiłbym to tak: agent pisze kod wyciągający tekst, a skrypt wysyła ten tekst do dużego modelu przez API i prosi o sparsowanie potrzebnej struktury. To nie jest problem „o kształcie skilla”, bo samo zapytanie do modelu jest proste: „zwróć mi listę cen”. Ale gdy masz 120 prac z ekonomii przemysłowej, potencjalnie istotnych dla projektu, i chcesz pierwszego przebiegu — materiału do przejrzenia, jak te prace mogą się przydać — to już wprost problem o kształcie skilla. Podejście: skill zawiera twoje kryteria oceny, czy praca jest relewantna, a potem — podagenty, znana w kodowaniu agentowym metoda równoległości — aplikujesz te kryteria do każdej pracy naraz i dostajesz pisemną ocenę per praca. Ten sam obszar badawczy, ale tylko tutaj skill ma sens.
Głos z sali: A macie skille dotyczące samego pisania kodu, skoro to przecież Claude czy Codex go pisze?
Aniket Panjwani: Do tego dojdę — to będzie ów zestaw „compound engineering”.
Głos z sali: W każdym z tych trzech przypadków i tak trzeba wymyślić odpowiednie polecenia. I to nie jest najprostsza rzecz na świecie.
Aniket Panjwani: I właśnie mógłby istnieć skill, który pomaga ocenić, czy w danym miejscu skill jest w ogóle przydatny. A jeśli robisz coś wieloetapowego — zbierz dane, otwórz takie i takie źródło, przeanalizuj tak, wyniki włóż tam — to opisujesz swoją standardową procedurę operacyjną, i ona ma kształt skilla. Podobnie: jeśli zawsze chcesz, żeby pliki Pythona powstawały w określony sposób, skill może się uruchamiać przy każdej pisaniu kodu przez agenta. Ale same jednostrzałowe zadania ze środka tego przykładu — to zwykły kod, nie skill.
W sytuacjach niepewnych odpowiedzią — częściową — jest znowu zapytanie agenta: „chcę zrobić skilla do X; czy to ma sens?”. Czemu częściową? Bo w bardziej złożonych sytuacjach nie przeprowadzi cię do końca. Wrócę do tego: w jakim stopniu można polegać na Claude Code czy Codexie przy takich decyzjach architektonicznych bez zewnętrznych punktów odniesienia, a w jakim trzeba to wyczucie wyrobić praktyką.
Błąd 4: niewykorzystane transkrypty sesji
Kolejny błąd: niekorzystanie z transkryptów własnych sesji. Wszystkie twoje minione sesje z agentem same w sobie są dobrym źródłem nowych skilli. Claude Code i Codex domyślnie zapisują na twoim komputerze transkrypty lokalnych sesji. To informacje bardzo osobiste, ale i bardzo użyteczne. Domyślne lokalizacje są w twoim katalogu domowym — osobne dla Claude Code i Codexa. Wejdziesz tam, zobaczysz pliki z datami: wszystko, co czytano, wszystkie wiadomości w obie strony. Claude Code — o ile wiem — kasuje je po trzydziestu dniach; transkrypty Codexa zostają dłużej.
Głos z sali: To działa tak samo, gdy używa się Claude z wiersza poleceń i przez aplikację desktopową?
Aniket Panjwani: Dla aplikacji desktopowej i interfejsu wiersza poleceń — na pewno tak. W VS Code może być inaczej.
Głos z sali: I można kazać agentowi przejrzeć to, co się kiedyś zrobiło — te twoje heurystyki, tamte rozmowy?
Aniket Panjwani: Dokładnie. Możesz kazać Claude Code lub Codexowi przeszukać poprzednie sesje — w projekcie albo między projektami — i ocenić, czy są tam powtarzalne przepływy, z których wyszłyby dobre skille. Bardzo się to przydaje. To też świetny sposób, by przypomnieć sobie, o czym się kiedyś myślało. Nawet jeśli nie znasz dokładnej ścieżki, wystarczy powiedzieć: „dwa tygodnie temu rozmawialiśmy o czymś takim, zapomniałem, jaki to był zbiór i gdzie leżał — przejrzyj moje sesje i znajdź”. Powinien znaleźć od razu.
Głos z sali: To dotyczy tylko Claude Code, czy też Claude w czacie? Bo próbowałem kiedyś „wypisz mi transkrypt tej rozmowy” i jedno z tych dwóch po prostu odmówiło.
Aniket Panjwani: W Claude Code na pewno jest dostępne; w czacie nie mam pewności. Ale szczerze: odradzam interfejs czatu. W aplikacji desktopowej jest bąbelkowy czat i tryb kodu — zawsze używajcie trybu kodu, nawet jeśli traktujecie go jak czat. Nie mam teraz kompletnej listy wad, ale część powodów to właśnie to: czat jest interfejsem bardziej ograniczonym, wiceszpiaskownica. Lepiej siedzieć w tym kodowym.
A skoro te sesje znikają po trzydziestu dniach — zrobiłem sobie skilla (tuż obok żartobliwie nazywanego „metaskilla”), który regularnie zrzuca wszystkie sesje do jednej bazy i pozwala ją przeszukiwać w zoptymalizowany sposób. Nie musicie tego robić, ale wspominam, bo to jedno z narzędzi, z których korzystam najczęściej.
Anatomia skilla i mechanizm progresywnego ujawniania
Dobry moment na definicję techniczną: czym skill jest „pod maską” i gdzie leży na dysku. Skill to folder o określonych właściwościach. Spójrzcie na skilla DiD i event study. Pierwszy warunek: nagłówek pliku musi wyglądać właściwie — koniecznie zaczynać od trzech myślników, inaczej Claude Code czy Codex w ogóle nie rozpoznają skilla. Muszą być pola name i description — te dwa są istotne. Potem treść opisująca zawartość — część już widzieliście. Wszystko pozostałe jest opcjonalne, ale folder może opcjonalnie zawierać skrypty, materiały referencyjne, obrazy, dane, szablony — na przykład interfejs, do którego skill się odwołuje, albo checklistę do przejścia przy event study.
Fundamentalną cechą skilli jest tzw. progresywne ujawnianie treści (progressive disclosure) — to w gruncie rzeczy rdzeń tych narzędzi. Zapewne znacie pojęcie okna kontekstu: w Claude Code czy Codexie nie można bez końca dosypywać pytań, jest limit — różny zależnie od narzędzia i modelu. Gdy limit padnie, następuje zdarzenie zwane kompakcją: wszystko dotąd zrobione jest streszczane, a praca biegnie dalej na streszczeniu.
Konkretnie: gdy zaczynasz sesję, część okna jest już zajęta, zanim wyślesz choć jedną wiadomość. Co tam siedzi? Na przykład prompt systemowy — w Claudiu takie „jesteś pomocnym asystentem, nie próbujesz skrzywdzić ludzi” — oraz dostęp do narzędzi, czyli akcji możliwych dla agenta: czytanie plików, pisanie plików, przeglądanie internetu. To razem zajmuje powiedzmy pierwsze 30 tysięcy tokenów.
Skille są w istocie odniesieniami do narzędzi — to w praktyce jest skill. Zanim wyślesz cokolwiek, osiem opisów skilli zajmuje zaledwie 800 tokenów z 258 tysięcy. Co dokładnie? Nazwy i opisy skilli — dla wygody przyjmijmy po 100 tokenów każdy.
Teraz użytkownik pisze: „zaktualizuj schemat tego wykresu”. Nie wskazałem wprost konkretnego skilla — ale spójrzcie: najbardziej trafny semantycznie wygląda skill do aktualizacji wykresów. Te agenty są inteligentne: nawet gdybym nie użył słów „skill”, „aktualizuj”, a jedynie mówił „w kierunku” poprawki figury — bardzo prawdopodobne, że zajdzie dokładnie to samo. Można też skilla wywołać jawnie. W obu przypadkach, gdy agent uzna, że przy tej wiadomości skill ma sens, czytana jest pełna treść — plik SKILL.md, powiedzmy kolejne 5 tysięcy tokenów — a poza tym, opcjonalnie, część załączników: może skrypty, ale niekoniecznie checklista. Sedno jest takie: w przeciwieństwie do agents.md czy claude.md, które siedzą w kontekście zawsze, przy skillach co sesję ładowane są wyłącznie nazwy i opisy, a cała reszta dołączana jest stopniowo, wedle potrzeb. To sposób na oszczędne gospodarowanie cennym oknem kontekstu bez rezygnacji z wielu wyspecjalizowanych zachowań.
Głos z sali: Rozumiem, że są dwa koszty tworzenia nowych skilli… Pierwszy to tokeny?
Aniket Panjwani: Przy stu skillach to 10 tysięcy tokenów. Coś — ale nie koniec świata.
Głos z sali: A ten drugi, subtelniejszy: agent przy wielu skillach sam się domyśla z samego języka, którego użyć…
Aniket Panjwani: Zgadza się. Może się zdarzyć, że mam „DiD advanced study” i „DiD analyze” — bo zapomniałem, co już robiłem — i te redundantne skille się gryzą: czasem odpala się zły. Trzeba na to uważać przy dużych zbiorach. Jest zaś sposób: w nagłówku skilla da się ustawić, by wywoływać go wyłącznie jawnie — i w Codexie, i w Claude Code można tak zmodyfikować nazwę i opis. To rozwiązuje problem, a część ludzi uważa, że wyłącznie tak w ogóle powinno się pracować. Osobiście lubię jednak swobodę: czasem pracuję z telefonu, idę na spacer, coś mówię do urządzenia — i chcę, żeby to po prostu płynęło.
Błąd 5: brak porządków — skille się dezaktualizują
Kolejny błąd — mniejszy, ale wciąż błąd — to nie sprzątanie skilli. Skille mają datę ważności. Skąd się to bierze? Projekt się zmienia: skill projektowy odwołuje się do plików i folderów, których już nie ma — wywołujesz skilla i w transkrypcie widzisz: „szukałem tego pliku, nie ma go”. Skąd to?! Bardzo możliwe, że z nieaktualnego polecenia w jakimś starym skillu. System na komputerze się zmienia: aktualizujesz pakiety, a stary skill celuje w inny. Zewnętrzne systemy się zmieniają: uderzasz w API, które się przebudowało. A najbardziej istotne i najczęstsze: zmienia się model. Albo — powiedzmy wprost — model zmieni się na pewno, jak wszyscy widzieliśmy.
Dobry przykład: Stata. Rok temu agenty kodujące naprawdę kiepsko sobie z nią radziły. Nagrałem wtedy bardzo popularny wśród ekonomistów film na YouTube o używaniu Quarto ze Statą. Dziś ten film jest w zasadzie nieaktualny, bo jawne instrukcje, które tam opisywałem — czym jest Stata, gdzie na systemie leży jej dokumentacja — są zbędne. Albo… czy na pewno? Skille statowe mogą się jeszcze przydać modelom spoza granicy możliwości. Mam grant na badania nad lokalnymi dużymi modelami do pracy z danymi objętymi restrykcjami — takimi, o które nie wolno pytać modeli granicznych. Instytucja musi wtedy kupić GPU i postawić modele lokalnie; pytanie brzmi, czy da się z nimi sensownie pracować. Na szybko, na serwetce, zadawałem różnym modelom serię pytań czysto składniowych — między innymi popularnemu modelowi agentowemu do kodowania o 27 miliardach parametrów, który mieści się na GPU za jakieś 4 tysiące dolarów. Ten, przynajmniej testowany bez żadnego skilla, wypadł słabo. Ciekawe pytanie badawcze: czy dodanie skilla z kontekstem — co to jest Stata, jak się jej używa — polepszy wyniki? Jeśli z jakichś powodów pracujecie na mniejszych modelach, miejcie to z tyłu głowy.
Główna rada przy tym błędzie: wracajcie do skilli, gdy zmienia się model. Przy każdym wydaniu laboratorium publikuje wskazówki, jak pracować z nowym modelem względem poprzedników — tak było choćby z wytycznymi OpenAI przy premierze GPT-6 Astra. Jeśli to ma być twój główny model, powiedz agentowi: przejrzyj ten dokument i moje skille — biorąc pod uwagę to, jak teraz należy myśleć o opisach skilli, agents.md i tak dalej, co powinniśmy zmienić?
Głos z sali: Czemu ten film na YouTube się zdezaktualizował?
Aniket Panjwani: Bo modele same poszły tak daleko, że nie trzeba im już podawać jawnych instrukcji — „to jest Stata, narzędzie ekonomistów, tu leży PDF z dokumentacją”. Model prawie na pewno wie to z treningu.
Głos z sali: Czyli można od razu zaczynać?
Aniket Panjwani: Tak, bez wstępów. Choć hipotezę warto testować — może być fałszywa, a wtedy po prostu rób skilla.
Głos z sali: Luksusowe pytanie z innej beczki, skoro jesteśmy przy Statcie: jak długo jeszcze mówienie agentowi, w jakim języku statystycznym ma pracować, będzie miało znaczenie dla jakości wyników? Mam wrażenie, że niedawno pokazano, iż nie ma różnicy — Stata, MATLAB czy Python, model dojdzie do tych samych wyników.
Aniket Panjwani: Krótko: nie wiem. Dłużej: moim zdaniem w zawodzie ekonomisty brakuje w ogóle ewaluacji — testów różnych modeli w różnych sytuacjach na zadaniach istotnych dla badań ekonomicznych. Właśnie one pozwoliłyby odpowiedzieć konkretnie; dziś to plotka. Z wstępnego przeglądu literatury wynika, że takich ewaluacji nie ma. Chcę je robić w ramach grantu na modele lokalne, ale przydałyby się również dla modeli granicznych.
Głos z sali: A te porządki — robić tylko przy nowych modelach, czy regularnie?
Aniket Panjwani: Zdecydowanie wtedy, gdy zauważysz, że coś się psuje w sposób, który ci przeszkadza. Sam robię to rzadko. Powiem tak: ludzie mierzą, o ile wydajniej pracują po takim sprzątnięciu — i różnice, które widzę od osób, którym ufam, to 30–40 procent. To się opłaca. Zawsze mogą się zdarzyć instrukcje, które pchają narzędzie w złą stronę, choć od dawna nie muszą — model i tak naturalnie idzie w dobrą, bo proces treningu poszedł naprzód.
Błąd 6: zarządzanie projektami — e-mail i transkrypty rozmów pod kontrolą agenta
Błąd szósty będzie szczególnie bliski ekonomistom rozwoju — a tak naprawdę wszystkim. Chodzi o brak skilli do zarządzania projektami. Dwa najcenniejsze skille, jakie posiadam, to: skill do poczty i skill do przeszukiwania wszystkich transkryptów rozmów. Bez tych dwóch obejść się najtrudniej. Wielu starszych pracowników naukowych już nie siedzi w kodzie — ale wszyscy prowadzą mnóstwo projektów i wszyscy ledwo nadążają. Podłączenie poczty i transkryptów do silnika jest kluczowe. Powiedzmy wprost: to również kwestia waszej oceny — jak się czujecie, dając tym narzędziom dostęp do tak informacji o sobie. Część mojego zainteresowania modelami lokalnymi bierze się stąd, że spory segment ludzi nie czerpie tych zysków produktywności, bo ma w pełni zasadnicze obawy prywatności — a sensownie wyceniony model lokalny mógłby dać im to samo, przy zredukowanym ryzyku.
Głos z sali: A jeśli Zoom jest chroniony hasłem — agent może wejść?
Aniket Panjwani: To, co dostajesz, to transkrypt — potrzebujesz mechanizmu, który go pozyska. Agent mógłby i sam, ale pokażę mechanizm, który polecam.
Zacznę od wartości: poczta plus AI daje kontekst dla twoich projektów badawczych i pozabadawczych. Mówiąc szczerze: mam po tej wizycie rozliczenie do wypełnienia — i zrobi je AI. Zwłaszcza w parze z funkcją sterowania komputerem: ustali, jaki formularz, pozbiera paragony, spięte. Ręcznie tego nie ruszam. Do tego szkice maili — bardzo pomocne. Nie wysyłam ich jednak od razu przez AI; zaraz pokażę, jak się przed tym chronić.
Częste zmartwienie: „a co, jeśli AI wyśle maila bez pytania?”. Z praktyki: dosłownie wystarczy mieć w skillu pocztowym zapisane coś w rodzaju: „najpierw szkic, potem moja akceptacja. Nigdy, przenigdy nie wysyłaj bez mojej zgody”. Sformułuj to stanowczo — i to w zasadzie załatwia sprawę.
Technicznie: wtyczki pocztowe Claude Code i Codexa pozwalają podłączyć jedną skrzynkę. Ja mam trzy — prywatną i do różnych projektów — więc koordynuję je narzędziem gogcli, które spina wiele kont Google. Napisał je Pete Steinberger — ktoś wie, kto to? Tak, ten od OpenClaw, tego szalonego asystenta AI, który zrobił furorę jakieś rok temu. Pierwsze skonfigurowanie jest dość żmudne, dużo kroków. Jeśli was przerasta: po pierwsze, zapłaćcie biednemu doktorantowi; po drugie, poproście własnego agenta, żeby przeprowadził was za rękę, a może nawet sam sterował przeglądarką i wypełniał te formularze.
Teraz transkrypty rozmów plus AI. To również kontekst — ale znacznie bogatszy niż z poczty. Analogia do zalet narzędzi zamiany mowy na tekst. Sam używam ich mocno, choć selektywnie: bywa, że pisząc, muszę wyklepać każdą literę ręcznie. Ale bywa i tak, że czuję: coś we mnie siedzi i wystarczy pogadać pięć minut, żeby to wyszło. Gdy to czuję — wiem: czas na spacer, kawa, i mówię. Chodzę sobie dziesięć minut, gadając do telefonu jak szaleniec — a telefon mam spięty z komputerem, wszystko trafia tam jako wejście i jestem w stanie wyciągnąć z głowy to, co w niej siedziało.
Głos z sali: U nas, doktorantów, jest odwrotny problem — nie wyglądamy dostatecznie dostojnie i nikt nie wie, czego dotyczą nasze porady… Ja notuję w aplikacji Notability na iPadzie, potem wracam do laptopa i każę [agentowi] przeczytać notatki i tworzyć zadania. Świetnie się sprawdza. Da się jeszcze wydajniej?
Aniket Panjwani: To dobre połączenie — notatki odręczne plus automatyczna generacja zadań; tak właśnie warto domykać obieg. (Odpowiedź urywa się w transkrypcji.)
David (prowadzący): Chcę wzmocnić coś, co powiedziałeś na marginesie, a czego ludzie mogą nie potraktować poważnie: te prompty-potoki świadomości, gdy człowiek po prostu mówi pięć–dziesięć minut. Wydawałoby się, że dadzą dziwaczne instrukcje. Tymczasem gdy czyta się prompty czołowych ludzi z Anthropic i OpenAI, to jest właśnie strumień świadomości: „chcę, żeby to było piękne”, „może zrób trochę tego”, „naprawdę chcę być pod wrażeniem” — mnóstwo emocji. Łatwo pomyśleć, że to bzdura, ale najwyraźniej się opłaca.
Aniket Panjwani: Andrej Karpathy — chyba wszyscy znacie: jeden z założycieli OpenAI, dziś, o ile pamiętam, szef pre-trainingu w Anthropic — opisywał kiedyś dokładnie to, co David mówi: po prostu mówi długimi wywodami. Trzeba jednak dodać jedną rzecz: osoby biegłe w słowie wyciągają z tych narzędzi lepsze rezultaty. Elokucja i precyzja wypowiedzi prawdopodobnie rosną na wartości używane w parze z tymi narzędziami. Dwulatek paplający pięć minut użytecznych rezultatów nie uzyska.
Głos z sala: A robiłeś skilla, który tłumaczy strumień świadomości na strukturę?
Aniket Panjwani: Czasem… Właściwie to skill, który powinienem zrobić, bo często nie wykorzystuję swojego potoku świadomości tak, jakbym chciał. Problem w tym, że między różnymi moimi użyciami nie ma jeszcze wystarczająco wspólnego mianownika. Powinienem więc przejrzeć transkrypty sesji, kazać zidentyfikować owe potoki, zobaczyć, w czym model zbłądził, jak musiałem prostować — i zaproponować odpowiedniego skilla. Faktycznie, powinienem to zrobić.
Kolejna świetna cecha transkryptów z AI: możliwość szybkiego działania. Pracuję teraz przy projekcie z mniej technicznym współautorem. Mamy rozmowę — i zaraz po niej mówię Codexowi: działaj, zatwierdzam. Na razie robimy proste rzeczy, ale to właśnie proste rzeczy stają się jasne dzięki jasnemu myśleniu: godzina gadania, z której w ostatnich dziesięciu minutach wyłania się jakaś jasność — i Codex wywodzi ją z transkryptu oraz błyskawicznie działa na tych dziesięciu minutach klarowności. Kazę mu nawet napisać do współautora na WhatsAppie, naszym zwykłym kanalem — tak u nas wygląda praca. A gdybyście kiedyś weszli do sektora prywatnego albo robili konsultacje — umiejętność błyskawicznej reakcji na klienta jest bezcenna.
Narzędzia: polecam dwa. Fathom — zakładam go na wideorozmowy; zapraszasz go do Zooma czy Google Meet jak uczestnika. Kluczowa rzecz, na którą macie uważać przy wyborze: narzędzie musi mieć API do łatwego wyciągania wszystkich transkryptów. Da się je wyciągać ręcznie, z logowaniem, ale to męczące — a przy tych rzeczach obowiązuje reguła: im więcej tarcia usuniesz, tym więcej z nich będziesz miał. Drugie to Granola — działa i w wideorozmowach, i poza nimi; wyciągasz je na spotkanie w kawiarni, bardzo wygodna forma. Różnica: Granola nie zachowuje audio ani wideo — po nagraniu zostają transkrypt i notatki. Fathom zachowuje dźwięk i obraz — gdy prowadzisz rozmowę z udostępnianym ekranem, który chcecie zachować, albo nagrywasz prelekcję pod YouTube czy stronę, wybierz Fathom. Za dostęp do API w Granoli płacisz — niewiele, 10 dolarów miesięcznie. Ja siedzę na darmowym planie Fathom i płacę za Granolę. Tak to u mnie działa.
Głos z sali: Czyli w darmowej wersji i tak muszę pytać rozmówców o zgodę?
Aniket Panjwani: Zgadza się. Sprawdźcie przepisy w swoim stanie — nie wiem, jak jest w Kalifornii. (śmiech)
Głos z sali: A da się użyć WhisperFlow? On ma chyba też notatnika?
Aniket Panjwani: WhisperFlow to narzędzie zamiany mowy na tekst — jeśli nie próbowaliście, a macie konto edukacyjne, dostajecie trzy miesiące za darmo; ja miałem rok gratis dzięki kanałowi na YouTube. Nie planuję odnawiać, bo sądzę, że darmowe narzędzia robią to samo. Ale tak — z prenumeratą WhisperFlow ma też notatnika.
Głos z sali: A jakie te darmowe?
Aniket Panjwani: Jest jedno — nie jestem pewien, czy naprawdę darmowe: może wchodzi w skład prenumeraty organizacji Every, o której opowiem za kilka slajdów. Nazywa się Monologue i wchodzi w cenę. Genuinely darmowych nie przytoczę z pamięci.
Jak to wszystko spiąć: jakimś mechanizmem łapiesz transkrypty, łączysz się integracją lub API, i masz skilla, który potrafi uderzyć w to API i wciągnąć właściwą rozmowę wraz z jej kontekstem do projektu. A jeśli chcecie robić to porządnie: automat, który regularnie zrzuca transkrypty do centralnego katalogu, tak by zawsze były pod ręką. To właśnie polecam.
Błąd 7: niekomponowanie skilli
Błąd siódmy — ostatni, na jaki zdążę; jeden jeszcze się zmieści, ale slajdy i tak wszyscy dostaniecie. Skille mogą wywoływać inne skille. Za dawnych czasów, gdy ludzie jeszcze pisali kod, istniało coś takiego jak funkcje: to, co robisz wielokrotnie, wklębiasz w funkcję, a funkcje wołają inne funkcje. Ze skillami można — i należy — robić dokładnie to samo.
Przykład: te slajdy. Wszystkie swoje slajdy robię ostatnio w HTML — są znacznie bardziej elastyczne, widzieliście drobne animacje. Prawie na pewno nie trafi w punkt polecenie „weź ten artykuł i zrób z niego prezentację”. Widzieliście to: wychodzi totalny śmieć, się nie da. Dobra droga — i możemy porozmawiać o procesie dojścia do niej — wygląda tak: najpierw sama treść slajdów w punktach: bez designu, bez LaTeX-a, bez pełnego wyjścia Beamera. Czy potrafisz w pliku tekstowym ułożyć z grubsza to, co chcesz mieć na slajdach, uporządkowane w punktach? U mnie bywa tak: mam zrobić zestaw slajdów, wiem, że coś zmieści się w tej przestrzeni i mniej więcej wiem co — więc gadam minutę–dwie, a potem, z pomocą skilla, proszę model, żeby pomógł mi to pociąć na slajdy. Gdy tekst slajdów stoi, myślę o wizualizacji: wykres? figura? wstawić obrazki? Powstają więc różne skille, które się komponują i przekazują sobie pałeczkę.
Głos z sali: Czyli nawet najnowocześniejsze modele nie potrafią wziąć artykułu i zrobić slajdów?
Aniket Panjwani: Potrafią — tylko słabo. Zależy, co znaczy „potrafią”: jakieś slajdy zrobią, ale to, co wypluje, jest do wyrzucenia.
Głos z sali: Bo jak to pokażesz, każdy wie, że to żenada.
Aniket Panjwani: Nie chodzi o to, że „każdy wie i wstyd, bo użyłeś AI” — chodzi o to, że to po prostu nie jest dobre: wywody się nie kleją, na slajdy trafiają rzeczy nie na temat. Czy technologia już tu dorośnię — dobre pytanie; w niektórych zadaniach nie wiem.
Gdy masz zestaw skillów, które mogłyby się zestawić — jak tamte płatkowe przykłady z pytaniem „czy to problem o kształcie skilla?” — LLM-y potrafią pomóc ocenić właściwy kształt i kompozycję, ale nie są doskonałe. Tamten skill „przesłuchanie”, który bardzo cenię, wyraźnie nie powstał przez kreator skilli: napisał go deweloper Matt Pocock, który ma bardzo wyrobiony gust w takich sprawach i jest znakomitym komunikatorem — i zapewne właśnie dlatego jego skille są dobre; jest w tym coś pokrewnego temu, dlaczego LLM-y po prostu kiepsko robią slajdy. Pewne aspekty komunikacji w nich „nie przechodzą”. Niektóre rzeczy ustalisz, pytając AI — innych naprawdę nie. To odpowiednik tego, dlaczego w tworzeniu oprogramowania — i w samej pracy badawczej — człowiek wciąż jest, i słusznie, potrzebny do decyzji architektonicznych i produktowych. Jestem ciekaw waszych ocen: nie wiem, jakiej jakości pomysły badawcze wychodzą z tych narzędzi. Czy one są naprawdę dobre? Sądząc po własnym doświadczeniu — niezbyt.
Dla części skillów da się jawnie sprawdzić, czy kompozycja jest trafna. Na przykład skill do przeglądu literatury, od którego żądasz: „znajdź wszystkie prace z ekonomii pracy o płacy minimalnej w Idaho”. Możesz zebrać te prace i przetestować, jak dobrze skill prowadzi model, żeby je odzyskał. Ale inne rodzaje przeglądów literatury trudno tak testować, a rzeczy oparte na guście — skill do projektowania stron, cokolwiek z komponentą estetyczną — liczbowo ocenić się nie da. Krótko: w tym aspekcie używania AI człowiek wciąż jest nieodzowny.
Na koniec, jeśli zdążę w tych czterech minutach — przykład kompozycji. Organizacja Every to wydawnictwo medialne piszące o AI dla wymagającej, choć nie technicznej publiczności — na poziomie bardzo użytecznym dla ekonomistów, bo skupia się na ogólnej pracy z wiedzą. Jeśli macie sto dolarów rocznie do wydania, to chyba dobra prenumerata; bywa okres próbny. Oferują darmowe skille — nie trzeba za nie płacić — a ja korzystam z nich ponad rok i bardzo pomagają. Zrobili wtyczkę do Claude Code i Codexa (wtyczkę można rozumieć jako zestaw skilli przygotowany do dystrybucji) zwaną Compound Engineer, z zestawem w środku, który naprawdę polecam wypróbować, bo świetnie rozwiązuje kwestię kompozycji:
- brainstorm — gdy planujesz coś i musisz przemyśleć, czego dokładnie chcesz; używam go cały czas, pewnie kilka razy dziennie;
- plan — gdy wiesz już co, a myślisz o kolejności wdrażania. Ten duet, zwłaszcza dla doktoranta na świeżym projekcie, jest niezastąpiony: brainstorm do „co robić” (zbieranie danych, poszczególne kroki), plan do „w jakiej kolejności”;
- implement — standardowy sposób faktycznego pisania kodu; to była odpowiedź na pytanie, skąd się biorą pliki Pythona;
- POV — drugie spojrzenie, gdy ważysz dwie możliwości; sam go używam w takich momentach, ale bez entuzjazmu — niuansów nie zdążę omówić;
- document review i code review — przeglądy dokumentów i kodu. Uwaga: code review często rzuca się na rzeczy ekonomiście zbędne — audyty bezpieczeństwa, szukanie wstrzyknięć SQL.
Ogólniejsza rada, gdy zaczniesz poważniej myśleć o swoich przepływach: przyda się mechanizm krytycznego oka na własną pracę. Kilka osób, z którymi rozmawiałem i które cenię, korzysta z czegoś w rodzaju document review, tylko skierowanego na krytykowanie własnych prac — bywa z kilkoma „personami” działającymi równolegle. A słynni ekonomiści — ludzie, których szanujecie — są bardzo głęboko osadzeni w wagach modeli granicznych. Czyli: chcesz skilla Gary’ego Beckera, który szuka tego, czego szukałby Becker? Albo Larsa Petera Hansena? W praktyce wystarczy poprosić agenta, żeby takiego skilla stworzył — i zrobi to z własnych wag, bez sięgania po zewnętrzne materiały.
Ostatni błąd, na który już nie zdążę, to brak wersjonowania skilli. Używajcie Gita — ale to będzie musiło poczekać na inny raz. Dziękuję.
(oklaski; prelegent zapowiada przesłanie slajdów)