O czym jest ten film
- Rozmowy z agentem programistycznym są zapisywane na komputerze i mogą posłużyć do oceny jego pracy.
- Najprościej zacząć od prośby, by agent przejrzał wcześniejsze sesje i wskazał najważniejsze powtarzające się problemy.
- Surowe pliki rozmów są obszerne, więc ich wielokrotne czytanie przez agenta zużywa dużo tokenów.
- Autor pokazuje, jak przechowywać transkrypty w Databricks i przekształcić je w tabele sesji, wypowiedzi oraz wywołań narzędzi.
- Agent Genie pomaga rozpoznać strukturę plików, przygotować kod i analizować dane zgromadzone w tabelach.
- Po połączeniu Databricks z agentem przez MCP można zadawać pytania o historię pracy bez przeglądania wszystkich plików od nowa.
- Na podstawie wykrytych problemów autor zmienił własne reguły, uprawnienia i skrypt uruchamiany na początku sesji.
- Przed przesłaniem historii rozmów do zewnętrznej usługi trzeba sprawdzić, czy pliki nie zawierają poufnych danych.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od historii własnych sesji
Na czym polega: Zapisane rozmowy zawierają polecenia użytkownika, działania agenta i wywołania narzędzi. Można w nich znaleźć problemy, które powracają podczas codziennej pracy.
Jak stosować: Poproś agenta o przejrzenie wcześniejszych sesji i wskazanie kilku najczęstszych przyczyn pomyłek lub niepotrzebnej pracy.
Na co uważać: Pojedyncza nieudana sesja nie dowodzi, że dany problem występuje regularnie. Szukaj powtórzeń.
2.Ogranicz liczbę proponowanych zmian
Na czym polega: Szerokie polecenie może przynieść długą listę drobnych uwag, w której trudno znaleźć rzeczy istotne.
Jak stosować: Poproś na przykład o dziesięć najważniejszych usprawnień i krótkie uzasadnienie każdego z nich.
Na co uważać: Taka lista jest punktem wyjścia. Przed zmianą konfiguracji sprawdź, na jakich sesjach opiera się każda propozycja.
3.Wybierz sposób analizy odpowiedni do skali
Na czym polega: Bezpośrednie czytanie plików przez agenta jest proste, ale przy dużej historii pochłania wiele tokenów. Agent może też przeanalizować tylko część materiału.
Jak stosować: Przy niewielkiej liczbie sesji zacznij od prostego przeglądu. Jeśli chcesz wracać do analizy regularnie, rozważ uporządkowanie danych w tabelach.
Na co uważać: Wnioski z niepełnej próbki łatwo uznać za obraz całej historii.
4.Zachowaj transkrypty, które mają służyć do późniejszej analizy
Na czym polega: Według autora Claude Code domyślnie usuwa zapisane rozmowy po 30 dniach. Długofalowe porównania wymagają więc osobnego miejsca przechowywania.
Jak stosować: Ustal, które sesje warto archiwizować, i zapisuj je w miejscu dostępnym dla wybranego sposobu analizy.
Na co uważać: Przechowywanie większej liczby rozmów zwiększa ilość danych, które trzeba kontrolować i chronić.
5.Porządkuj dane według pytań, na które chcesz odpowiedzieć
Na czym polega: Autor dzieli historię na tabele sesji, kolejnych wypowiedzi i wywołań narzędzi. Dzięki temu może sprawdzać konkretne wzorce bez ponownego czytania całych rozmów.
Jak stosować: Najpierw zdecyduj, czy interesują Cię na przykład nieudane wywołania narzędzi, długość sesji czy powracające błędy. Potem dobierz potrzebne pola tabel.
Na co uważać: Pliki JSONL mogą różnić się budową. Sprawdź, czy dane z różnych sesji zostały poprawnie odczytane.
6.Zleć agentowi przygotowanie przetwarzania, ale sprawdź wynik
Na czym polega: W pokazanym przykładzie Genie bada pliki, pisze kod i wypełnia tabele w Databricks.
Jak stosować: Daj mu dostęp do przykładowych transkryptów, poproś najpierw o opis rozpoznanej struktury, a następnie o utworzenie i zasilenie tabel.
Na co uważać: Automatycznie przygotowany kod i liczby rekordów warto przejrzeć przed wyciąganiem wniosków z danych.
7.Pytaj o powtarzające się przyczyny, a nie tylko o objawy
Na czym polega: Sama lista błędów niewiele zmienia. Przydatniejsza jest odpowiedź, która wskazuje, jaka reguła, umiejętność agenta lub mechanizm uruchamiany automatycznie może ograniczyć dany problem.
Jak stosować: Po znalezieniu wzorca poproś agenta o konkretną propozycję zmiany konfiguracji i wskaż sesje, na których ma ją oprzeć.
Na co uważać: Sugestia agenta pozostaje hipotezą. Oceń ją podczas kolejnych rzeczywistych zadań.
8.Podawaj agentowi aktualny układ repozytorium
Na czym polega: Jednym z problemów wykrytych przez autora było zgadywanie ścieżek do plików. Dodał więc skrypt, który na początku rozmowy przekazuje agentowi bieżący układ repozytorium.
Jak stosować: Jeśli Twój agent często szuka plików pod błędnymi adresami, rozważ automatyczne dostarczanie mu krótkiego opisu struktury projektu.
Na co uważać: Taki opis powinien odpowiadać aktualnemu stanowi repozytorium; ręcznie utrzymywana lista katalogów może się zdezaktualizować.
9.Sprawdź pliki przed wysłaniem ich do zewnętrznej usługi
Na czym polega: W wariancie z Databricks historia rozmów opuszcza komputer użytkownika. W transkryptach mogą znajdować się klucze API lub inne poufne informacje.
Jak stosować: Przejrzyj pliki przed przesłaniem. Jeśli zawierają dane wrażliwe, usuń je lub przygotuj oczyszczone kopie.
Na co uważać: Nie zakładaj, że rozmowy są bezpieczne do udostępnienia tylko dlatego, że nie pamiętasz wpisywania w nich sekretów.
10.Mierz poprawę w następnych rozmowach
Na czym polega: Wartość analizy zależy od tego, czy wprowadzone zmiany faktycznie ograniczają powracające kłopoty.
Jak stosować: Po zmianie reguł lub narzędzi obserwuj kolejne sesje i sprawdź, czy wskazany problem występuje rzadziej.
Na co uważać: Jedna udana rozmowa nie wystarcza, by uznać problem za rozwiązany.
Redakcyjne tłumaczenie
Dane, które już masz
Niezależnie od tego, jakiego agenta używasz do programowania, prawdopodobnie masz na komputerze zbiór danych, z którego prawie nie korzystasz: historię własnych rozmów z tym agentem. Chcę pokazać, jak wykorzystać ją do stopniowego poprawiania jego pracy bez dużego nakładu pracy z Twojej strony.
Rozmowy są zapisywane w plikach. W Claude Code mają one format JSONL. Agent potrafi do nich zaglądać; zauważyłem, że robi to również wtedy, gdy ma do dyspozycji osobny system pamięci, a pytam go o wcześniejsze sesje. Nic dziwnego, bo te pliki zawierają mnóstwo szczegółów.
Właśnie ta obfitość danych stanowi jednak trudność. Kiedy otworzysz taki plik i zaczniesz go przewijać, trudno od razu dostrzec, jak wyciągnąć z niego coś przydatnego. Możemy jednak zebrać setki lub tysiące zapisanych rozmów i wydobyć z nich informacje o tym, co agent robi dobrze, gdzie się myli i na co zużywa czas oraz tokeny.
W plikach znajdują się nasze polecenia, wywołania narzędzi i serwerów MCP, a także zapis przebiegu pracy agenta. Jeśli wyodrębnimy potrzebne dane i ułożymy je w tabelach, będziemy mogli szukać powtarzających się wzorców. Być może odkryjemy, gdzie agent niepotrzebnie zużywa tokeny. Być może zauważymy błędy, którym można zapobiec przez zmianę reguł albo dodatkowych instrukcji. Agent może pomóc nam przeprowadzić całą tę analizę.
Punktem wyjścia są rozmowy, które już odbyłeś. Potrzebujemy jedynie sposobu na ich zachowanie i uporządkowanie. Według domyślnych ustawień, o których mówię w tym materiale, Claude Code usuwa zapisane sesje po 30 dniach. Jeśli chcemy analizować je w dłuższym okresie, musimy przechowywać kopie. Przyda się też baza danych, bo surowe pliki JSONL są niewygodne do przeszukiwania.
Pokażę rozwiązanie przygotowane w Databricks. To sposób, który najlepiej sprawdził się u mnie, choć podobną analizę można przeprowadzić innymi metodami. W moim przykładzie osobne tabele przechowują sesje, kolejne wypowiedzi i wywołania narzędzi.
Najprostszy początek: poproś agenta o przegląd rozmów
Zanim przejdziemy do tabel, zacznijmy od łatwiejszej wersji. Wystarczy poprosić agenta, by przeanalizował wcześniejsze rozmowy, znalazł możliwości poprawy swojej skuteczności i niezawodności, a następnie przedstawił dziesięć najważniejszych propozycji w krótkiej liście.
Nie trzeba używać dokładnie takiego polecenia jak moje. Ograniczam liczbę odpowiedzi, ponieważ nie chcę dostawać ogromnego zestawu zmian, z których wiele ma znikome znaczenie. Zależy mi na problemach, którymi rzeczywiście warto się zająć.
Możesz też po prostu spytać agenta, gdzie na komputerze znajdują się jego zapisane rozmowy. Claude Code potrafi wskazać folder z plikami JSONL, podzielonymi według projektów. Innym sposobem ich znalezienia jest wyszukanie plików z rozszerzeniem .jsonl.
Na potrzeby tego prostego przeglądu przygotowałem dodatkową instrukcję dla agenta, określaną w Claude Code jako skill. Agent korzysta z niej, uruchamia polecenia powłoki, odczytuje pliki i szuka powtarzających się błędów. Link do tej instrukcji podaję w opisie filmu.
Kiedy dostanę listę problemów, mogę wybrać jeden z nich i zapytać: co trzeba zmienić w konfiguracji agenta, żeby trudność nie wracała? Przez tę konfigurację rozumiem między innymi reguły, dodatkowe instrukcje, podagentów oraz mechanizmy uruchamiane automatycznie przy określonych zdarzeniach.
W mojej analizie trzecim wskazanym problemem było zbyt częste osiąganie limitu równolegle działających podagentów. Poprosiłem więc Claude Code o propozycję poprawki. Wskazał konkretnego podagenta jako prawdopodobną przyczynę i zaproponował zmianę. Jeśli diagnoza jest trafna, taka poprawka powinna pomóc. Trzeba to jeszcze sprawdzić podczas następnych rozmów.
To cała idea w najprostszej postaci: przeglądasz historię pracy, poprawiasz konfigurację i obserwujesz, czy agent radzi sobie lepiej.
Dlaczego warto uporządkować historię
Prosty sposób ma poważne ograniczenie. Aby znaleźć wzorce w wielu rozmowach, agent musi przejrzeć bardzo obszerne pliki JSONL. Może zużyć na to setki tysięcy tokenów. Jeśli zaś ograniczy się do kilku plików, łatwo przeoczy ważne problemy.
Istnieją projekty takie jak CC Usage czy Claude Mem, które pomagają śledzić korzystanie z agenta lub zapewniają mu pamięć. Mnie zależy jednak na czymś konkretnym: chcę przechowywać historię w postaci, która pozwoli regularnie wykrywać problemy i na tej podstawie poprawiać działanie agenta.
W tym celu używam bezpłatnej wersji Databricks. Pokażę, jak przenieść tam transkrypty, zbudować tabele i zadawać pytania o zgromadzone dane. Pomaga w tym Genie, agent dostępny w Databricks.
Pełna informacja: zdecydowałem się współpracować z Databricks przy przygotowaniu tego filmu. Korzystałem już z tej platformy w opisanym zastosowaniu, a jej bezpłatna wersja wystarcza do przejścia przez pokazywany proces.
Połączenie Databricks z agentem programistycznym
Najpierw instalujemy narzędzie wiersza poleceń Databricks CLI. Instrukcje dla poszczególnych systemów operacyjnych podlinkowałem w opisie filmu. Następnie można połączyć Databricks z używanym agentem, na przykład Claude Code, Pi albo Codex. W moim przykładzie służą do tego narzędzia AI dostępne przez CLI.
Po skonfigurowaniu połączenia agent może korzystać z Databricks przez serwer MCP. (Informacja dodatkowa: MCP to sposób udostępniania agentowi narzędzi i danych z innych aplikacji.) Dzięki temu można z poziomu zwykłej rozmowy z agentem przesyłać transkrypty, pracować nad tabelami i pytać o wyniki analizy.
Gdy dane są już przygotowane, mogę na przykład poprosić Claude Code, by użył Genie do zbadania historii moich sesji. Mogę też zwrócić się do Genie bezpośrednio z wiersza poleceń. Zanim jednak zaczniemy zadawać takie pytania, trzeba utworzyć miejsce na pliki i przekształcić ich zawartość w uporządkowane dane.
Przesłanie transkryptów i kontrola danych
Na stronie głównej bezpłatnej wersji Databricks przechodzę do katalogu i tworzę volume, czyli miejsce przechowywania plików. Tam trafiają rozmowy w oryginalnym formacie JSONL.
Pliki można przesłać ręcznie z komputera albo zlecić to agentowi przez wcześniej skonfigurowane połączenie MCP. Na potrzeby pokazu wybrałem 62 największe rozmowy, żeby nie przenosić od razu tysięcy plików. Można jednak pracować z większym zbiorem.
W tym miejscu trzeba podjąć świadomą decyzję: przesyłamy rozmowy z agentem do kolejnej usługi. Według zapewnienia, które przywołuję w filmie, Databricks nie używa tych danych do trenowania modeli. Mimo to przed wysłaniem warto sprawdzić zawartość plików. Jeśli znalazły się w nich klucze API lub inne poufne informacje, nie należy przesyłać ich w tej postaci. Można wcześniej usunąć takie dane, również z pomocą agenta.
Kiedy pliki są już w volume, kopiuję ścieżkę do tego miejsca. Za chwilę podam ją Genie, aby wiedział, skąd pobrać transkrypty.
Od plików JSONL do tabel
W Databricks przechodzę do obszaru roboczego i otwieram notatnik. Następnie uruchamiam Genie. Daję mu ścieżkę do zapisanych rozmów i proszę o ich przetworzenie. Wyjaśniam, że są to transkrypty sesji Claude Code, których rekordy mogą mieć różnie zbudowane, zagnieżdżone pola.
Ta różnorodność jest jedną z trudniejszych części zadania. Genie najpierw przygląda się plikom i ustala, jak są zbudowane. Potem przygotowuje w notatniku kod, który je przetwarza. W moim przykładzie korzysta przy tym ze Sparka. Nie zlecam więc głównemu agentowi odczytania całych transkryptów w ramach rozmowy i zużycia na to ogromnej liczby tokenów.
W pokazanym przebiegu Genie przygotował kod, utworzył tabele sesji, kolejnych wypowiedzi oraz wywołań narzędzi, a następnie wypełnił je danymi. Pokazał też liczbę rekordów i kolumn w każdej tabeli. Nie pisałem tego kodu samodzielnie.
Przeprowadziłem pracę w dwóch krokach. Najpierw poprosiłem Genie o rozpoznanie danych i pokazanie, jak je rozumie. Dopiero potem zleciłem utworzenie tabel i załadowanie do nich zawartości plików. Można sformułować prośbę mniej szczegółowo, ale taki podział pozwolił mi obejrzeć proponowaną strukturę przed dalszą pracą.
Pytania o błędy bez ponownego czytania całych rozmów
Po utworzeniu tabel wracam do agenta programistycznego. Dzięki połączeniu MCP mogę pytać go o historię sesji, a on kieruje zapytania do Genie. Mogę na przykład poprosić o wskazanie powtarzających się niepowodzeń i propozycje zmian w regułach lub narzędziach agenta.
Tym razem Claude Code nie musi przy każdym pytaniu uruchamiać poleceń odczytujących wszystkie pliki. Genie pracuje na uporządkowanych danych: przygotowuje zapytania SQL, analizuje tabele i zwraca wyniki. Główny agent pomaga mi zadawać pytania i korzystać z odpowiedzi.
W pokazanej analizie Genie wskazał trzy główne wzorce problemów. Mogłem następnie poprosić Claude Code o propozycje zmian, które ograniczą ich występowanie. Otrzymałem również odnośnik do rozmowy z Genie w Databricks, więc w razie potrzeby mogłem sprawdzić, jak przebiegała analiza.
Kiedy pojawią się nowe rozmowy, można dołączyć je do przygotowanego już sposobu przetwarzania danych. Nie trzeba za każdym razem zaczynać od ręcznego przeglądu całej historii.
Co zmieniłem we własnym systemie
Chciałem sprawdzić tę metodę na swojej codziennej konfiguracji. Analiza doprowadziła do kilku zmian, które zamierzam zachować.
Do globalnych reguł agenta dopisałem około 38 wierszy odnoszących się do wykrytych problemów. Jedna z zasad mówi, by agent nie zgadywał ścieżek do plików. Bez wyraźnej instrukcji agenci potrafią to robić zaskakująco często. Zmieniłem też uprawnienia w pliku settings.json, aby agent mógł sprawniej pracować z Gitem.
Najbardziej podoba mi się jednak dodany mechanizm uruchamiany na początku każdej nowej rozmowy. Skrypt odczytuje aktualny układ repozytorium i przekazuje go agentowi. Dzięki temu agent ma pod ręką rzeczywiste ścieżki, gdy szuka plików i poznaje projekt.
Można wpisać strukturę projektu do stałych reguł, ale wtedy trzeba ją ręcznie aktualizować. Skrypt pobiera ją przy rozpoczęciu sesji, więc opis odpowiada bieżącemu stanowi repozytorium.
To przykłady z mojego środowiska, a nie gotowa lista poprawek dla każdego użytkownika. Pokazują jednak, jak przejść od zauważonego w historii problemu do konkretnej zmiany w działaniu agenta.
Wnioski na dalszą pracę
Historia rozmów z agentem programistycznym może powiedzieć nam znacznie więcej niż pamięć o kilku ostatnich zadaniach. Można ją przejrzeć bezpośrednio albo uporządkować w tabelach i regularnie analizować. W obu przypadkach najważniejszy jest ten sam ciąg działań: znaleźć powtarzający się problem, wprowadzić poprawkę i sprawdzić w następnych sesjach, czy przyniosła skutek.
Databricks i Genie są sposobem, którego użyłem, by pokazać cały proces od zapisanych transkryptów po zmiany w konfiguracji. Dalsze korzyści zależą już od tego, czy będziemy wracać do własnych danych i oceniać działanie wprowadzonych poprawek.