Sesja jest wiadomością commita

Programista dziedziczy bazę kodu. git blame pokazuje 47 zmienionych plików w jednym commicie. Wiadomość brzmi: „refactor auth module”. Autor commita jest wymieniony jako ludzki programista. Faktycznym autorem był agent kodujący, który pracował przez 90 minut, przeczytał 200 plików, przeanalizował trzy alternatywne podejścia, odrzucił dwa z nich z konkretnych powodów i wygenerował zestaw zmian obejmujący każdy endpoint uwierzytelniania. 90-minutowa sesja decyzji projektowych, odrzuconych alternatyw i omówionych przypadków brzegowych zniknęła. Git zachował co się zmieniło. Nic nie zachowało dlaczego.

Mój wpis o długu kognitywnym nazwał przepaść między szybkością generowania kodu przez agenta a szybkością rozumienia przez programistę „długiem kognitywnym” — zobowiązaniem, które narasta z każdym niezweryfikowanym commitem.¹ Projekt Memento, który zebrał 100 punktów na HN i 124 komentarze, stawia kolejne pytanie: jeśli sesja zawiera uzasadnienie, czy sesja powinna być częścią commita?²

TL;DR

Git rejestruje CO się zmieniło. Sesje agentów rejestrują DLACZEGO. Kiedy agenty piszą kod, transkrypt sesji jest prawdziwym dokumentem projektowym, a każdy workflow, który odrzuca transkrypt, odrzuca pochodzenie zmian. Memento (rozszerzenie git o otwartym kodzie źródłowym) dołącza transkrypty sesji AI do commitów jako notatki git, tworząc łańcuch pochodzenia od commita do uzasadnienia. Nowa integracja LSP w Claude Code dodaje strukturalne rozumienie kodu, które czyni transkrypty sesji bardziej precyzyjnymi: go-to-definition zastępuje grep, a sygnatury typów zastępują domysły. Poniżej: luka w pochodzeniu, cztery warstwy metadanych sesji, co buduje Memento, jak LSP zmienia jakość danych sesyjnych oraz minimalne praktyki dotyczące pochodzenia, które można wdrożyć już dziś.

Luka w pochodzeniu

Git śledzi pięć rzeczy dotyczących każdej zmiany: kto ją wprowadził, kiedy, jakie pliki się zmieniły, diff oraz wiadomość commita. W przypadku kodu napisanego przez człowieka wiadomość commita stanowi pomost między diffem a intencją. Dobra wiadomość wyjaśnia, dlaczego zmiana istnieje. Zła wiadomość („fix stuff”) zmusza recenzenta do rekonstrukcji intencji na podstawie kodu.

Kod napisany przez agenta ma inną strukturę pochodzenia. Intencja nie żyje w głowie programisty. Intencja żyje w sesji: w prompcie, który rozpoczął zadanie, w plikach przeczytanych przez agenta, w przeanalizowanych alternatywach, w wywołanych narzędziach i w dowodach przytoczonych przy raportowaniu zakończenia. Wiadomość commita streszczająca 90 minut rozumowania agenta w jednej linii odrzuca 99,9% kontekstu decyzyjnego.

Strata nie jest teoretyczna. Mój system orkiestracji generuje pliki stanu sesji (jiro.state.json, jiro.progress.json), które rejestrują każde ukończenie zadania, werdykt recenzenta i wynik bramki dowodowej.³ Gdy recenzent pyta „dlaczego agent użył wykładniczego wycofywania zamiast wyłącznika obwodowego?” plik stanu sesji zawiera odpowiedź: agent przeanalizował oba wzorce, stwierdził, że usługa nadrzędna zwraca powtarzalne odpowiedzi 503 z nagłówkiem Retry-After, i wybrał wykładnicze wycofywanie, aby honorować wartość nagłówka. Wiadomość commita mówi „refactor: standardize retry patterns”. Stan sesji mówi dlaczego.

Bez pochodzenia sesyjnego przegląd kodu zmian wprowadzonych przez agenta staje się archeologią. Recenzent czyta diff, odtwarza rozumowanie wstecz i formuje teorię o tym, dlaczego zmiana istnieje. Teoria może być błędna. Faktyczne rozumowanie agenta jest dostępne, zapisane w transkrypcie sesji. Standardowy workflow branżowy (commit, push, przegląd diffa) wyrzuca to rozumowanie.

Problem mnoży się przy kompozycji agentów. Mój system orkiestracji uruchamia wyspecjalizowane podagenty do przeglądu kodu: recenzent poprawności, recenzent bezpieczeństwa, recenzent konwencji.⁵ Każdy podagent prowadzi własną sesję, czyta własne pliki, formułuje własne wnioski. Agent nadrzędny agreguje werdykty. Końcowa wiadomość commita mówi „3 reviewers: approve”. Trzy indywidualne sesje recenzji — każda zawierająca konkretne ustalenia, analizę przypadków brzegowych i uzasadnienie zatwierdzenia — żyją w oddzielnych transkryptach, do których commit nigdy nie odsyła. Każda warstwa delegacji agentowej dodaje kolejną warstwę niewidocznego rozumowania.

Problem pochodzenia łączy się z trzema istniejącymi wzorcami awarii. Zapora fabrykacji zidentyfikowała, jak agenty publikują niezweryfikowane twierdzenia, gdy nie istnieje bramka wyjściowa.⁶ Pochodzenie sesyjne wyłapałoby fabrykację wcześniej: transkrypt sesji pokazywał, że agent wymyślił metodologię liczenia tokenów, której żaden człowiek nie zweryfikował. Niewidzialny agent udokumentował, jak działania agentów pozostają niemonitorowane bez jawnej instrumentacji.⁷ Pochodzenie sesyjne to ścieżka audytowa, którą generuje stos widoczności. Komentarz publiczny do NIST rekomendował standaryzowane logowanie audytowe działań agentów.⁹ Notatki git przechowujące transkrypty sesji są jedną implementacją tej rekomendacji.

Bramka dowodowa w moim systemie jakości wymaga od agenta przytoczenia konkretnych dowodów dla każdego kryterium jakości: nazwać wzorzec, wyjaśnić alternatywy, wymienić przypadki brzegowe, wkleić wynik testów.¹⁰ Bramka dowodowa wymusza na agencie generowanie danych warstwy rozumowania i weryfikacji, które w przeciwnym razie by nie powstały. Bez bramki agent raportuje „gotowe” i sesja zawiera jedynie dane procesowe (wywołania narzędzi). Z bramką sesja zawiera jawne uzasadnienie, które recenzent może zweryfikować względem kodu.

Sam Git nie jest w stanie odróżnić 47-plikowego commita reprezentującego 90 minut starannego rozumowania od 47-plikowego commita reprezentującego agenta działającego bez ograniczeń przez 90 minut bez przeglądu. Dokumentacja git opisuje notatki jako „dodatkowe informacje o obiekcie, które można dołączyć bez zmiany samego obiektu”.⁸ Transkrypty sesji idealnie pasują do tej definicji: dodatkowe informacje o pochodzeniu commita, które nie zmieniają hasza commita, diffa ani historii.

Pytanie Memento

Projekt Memento odpowiada na lukę w pochodzeniu za pomocą rozszerzenia git.² Narzędzie przechwytuje transkrypty sesji kodowania AI i dołącza je do commitów jako notatki git, przechowywane w refs/notes/commits i refs/notes/memento-full-audit.

Workflow: git memento init konfiguruje repozytorium. git memento commit <session-id> zastępuje git commit, automatycznie pobierając transkrypt sesji od skonfigurowanego dostawcy AI (Codex lub Claude Code) i przechowując go jako ustrukturyzowane metadane na commicie.

Dyskusja ze 124 komentarzami na HN ujawniła cztery stanowiska:

Stanowisko 1: Sesje to niezbędny kontekst. Sesje agentów zawierają rozumowanie, którego wiadomości commitów nie są w stanie oddać. Dołączanie sesji do commitów zachowuje łańcuch pochodzenia. Recenzenci mogą prześledzić każdą linię kodu wstecz — przez commit, sesję i oryginalny prompt.

Stanowisko 2: Sesje to szum. Transkrypt 90-minutowej sesji to tysiące linii konwersacji. Większość jest nieistotna dla końcowego zestawu zmian. Dołączanie pełnego transkryptu zakopuje sygnał w szumie i utrudnia przegląd, zamiast go ułatwiać.

Stanowisko 3: Podsumowania, nie transkrypty. Sesja powinna zostać destylowana do ustrukturyzowanego podsumowania: opis zadania, rozważane alternatywy, uzasadnienie decyzji, przytoczone dowody. Podsumowanie zachowuje pochodzenie bez szumu. Memento generuje podsumowania w formacie markdown oznaczone turami użytkownika i asystenta.

Stanowisko 4: Obawy dotyczące prywatności i bezpieczeństwa. Transkrypty sesji mogą zawierać klucze API, wewnętrzne adresy URL, zastrzeżony kod z innych plików lub treści konwersacyjne, których programista nie chciałby w trwałym rekordzie git. Sesje wymagają sanityzacji przed dołączeniem.

Wszystkie cztery stanowiska mają swoje uzasadnienie. Wartość pochodzeniowa sesji jest niezaprzeczalna. Problem szumu jest realny. Obawa o prywatność ma charakter strukturalny. Memento adresuje stanowiska 1 i 3 (przechowywanie transkryptów z konwersją do markdown) oraz stanowisko 4 (traktowanie transkryptów jako niezaufanych danych przy generowaniu podsumowań). Stanowisko 2 pozostaje otwartym pytaniem projektowym: ile kontekstu sesyjnego wystarczy?

Cztery warstwy pochodzenia

Metadane sesji agenta organizują się w cztery warstwy, z których każda odpowiada na inne pytanie dotyczące zmiany.

Każda warstwa generuje koszty. Przechowywanie pełnej warstwy intencji (oryginalny prompt) jest tanie: jedno pole tekstowe. Przechowywanie pełnej warstwy procesu (każde wywołanie narzędzia) dla 90-minutowej sesji generuje megabajty danych JSON. Przechowywanie warstwy rozumowania wymaga od agenta jawnego opisywania procesu decyzyjnego, czego większość agentów domyślnie nie robi. Przechowywanie warstwy weryfikacji wymaga integracji z systemem uruchamiania testów i systemem recenzji.

Mój system orkiestracji rejestruje wszystkie cztery warstwy poprzez różne mechanizmy.³ Infrastruktura hooków umożliwiająca takie przechwytywanie obejmuje 84 hooki w 15 typach zdarzeń.⁵ Intencja: hook UserPromptSubmit loguje oryginalny prompt. Proces: hooki PostToolUse logują każde wywołanie narzędzia i wynik. Rozumowanie: bramka dowodowa wymaga od agenta przytoczenia konkretnego uzasadnienia dla każdego kryterium jakości. Weryfikacja: plik jiro.state.json rejestruje wyniki testów i werdykty recenzentów.

Hooki śledzą również, które umiejętności agent wywołał i w jakiej kolejności.¹¹ Commit będący wynikiem umiejętności /review, po której następuje umiejętność /test, ma inny profil pochodzenia niż commit z pojedynczej nieustrukturyzowanej sesji. Sekwencja umiejętności ujawnia wzorzec workflow: przegląd przed testowaniem czy testowanie przed przeglądem? Kolejność ma znaczenie dla zrozumienia pokrycia zapewnienia jakości. Dane istnieją w wielu plikach stanu. Problem polega na tym, że żadne z nich nie są dołączone do commita git.

LSP jako most pochodzenia

Nowa integracja LSP (Language Server Protocol) w Claude Code zmienia jakość danych o pochodzeniu sesji.⁴

Przed LSP Claude Code nawigował po bazach kodu za pomocą grep i odczytu plików. Gdy agent potrzebował znaleźć definicję funkcji, szukał nazwy funkcji we wszystkich plikach. Wyszukiwanie zwracało rozmyte wyniki: wiele dopasowań, częściowe dopasowania, pliki testowe zawierające nazwę funkcji w komentarzach. Agent wybierał najbardziej prawdopodobne dopasowanie. Transkrypt sesji rejestrował: „wyszukano authenticate_user, znaleziono w auth.py, test_auth.py i middleware.py”. Dane o pochodzeniu zawierają wyszukiwanie, niejednoznaczność i najlepsze przypuszczenie agenta.

Z LSP agent wywołuje goToDefinition i otrzymuje dokładny plik i numer linii w ~50 milisekund.⁴ Transkrypt sesji rejestruje: „authenticate_user zdefiniowane w auth.py:47”. Dane o pochodzeniu są precyzyjne, jednoznaczne i weryfikowalne maszynowo. Recenzent czytający sesję może ufać, że agent znalazł właściwą definicję, a nie funkcję o podobnej nazwie w innym module.

Poprawa kumuluje się w trakcie sesji. Agent, który czyta 200 plików za pomocą grep, generuje dane sesyjne pełne „wyszukano X, znaleziono potencjalne dopasowania A, B, C, wybrano A”. Agent, który czyta 200 plików za pomocą LSP, generuje dane sesyjne mówiące „X zdefiniowane w plik:linia, odwołania w plik:linia, plik:linia, plik:linia”. Sesja wspierana przez LSP jest precyzyjną mapą rozumienia kodu przez agenta. Sesja wspierana przez grep jest rozmytym przybliżeniem.

LSP dodaje sześć możliwości poprawiających jakość pochodzenia:

Implikacja dla pochodzenia: transkrypty sesji z agentów z włączonym LSP są cenniejsze jako dokumenty projektowe, ponieważ każdy krok nawigacji po kodzie jest weryfikowalny. Recenzent może potwierdzić, że rozumienie bazy kodu przez agenta było poprawne, a nie tylko wiarygodne.

Jak wyglądają metadane sesji

Rzeczywisty przykład z mojego systemu orkiestracji. Zadanie: „Dodaj ograniczanie częstotliwości do endpointu uwierzytelniania”.

Warstwa intencji (z hooka UserPromptSubmit):

Prompt: "Implement rate limiting on POST /auth/login.
  Use sliding window, 5 attempts per minute per IP.
  Return 429 with Retry-After header."

Warstwa procesu (z hooków PostToolUse):

Files read: 14 (auth/, middleware/, tests/)
Files written: 3 (rate_limiter.py, auth.py, test_rate_limit.py)
Bash commands: 7 (pytest x3, pip install x1, curl x3)
Duration: 23 minutes
Token usage: 87K input, 24K output

Warstwa rozumowania (z bramki dowodowej):

Pattern: Sliding window (token bucket rejected
  because per-IP granularity requires separate
  counters, sliding window handles this natively)
Edge cases: IPv6 normalization, proxy headers
  (X-Forwarded-For validated against trusted proxy list)

Warstwa weryfikacji (z jiro.state.json):

Tests: 12 passed, 0 failed, 0 skipped
Reviewers: correctness (approve), security (approve),
  conventions (approve with note: add docstring to
  rate_limiter.py:RateLimiter class)
Evidence gate: 6/6 criteria met

Wiadomość commita dla tej samej zmiany: „feat: add rate limiting to auth endpoint”. Czternaście słów. Metadane sesji zawierają 2300 słów ustrukturyzowanego pochodzenia. Przepaść między wiadomością commita a kontekstem sesji wynosi dwa rzędy wielkości.

Koszt pochodzenia

Pochodzenie sesyjne nie jest darmowe. Trzy koszty ograniczają adopcję.

Przechowywanie. 90-minutowa sesja agenta generuje 500 KB–2 MB surowego transkryptu. Przy 10 commitach dziennie pełny transkrypt dodaje 5–20 MB dziennie do repozytorium git. Notatki git przechowują dane poza główną historią (domyślnie nie wpływają na rozmiar git clone), ale ścieżka audytowa w refs/notes/memento-full-audit kumuluje się. Konwersja Memento do markdown redukuje surowy rozmiar o około 60%.²

Prywatność. Transkrypty sesji zawierają wszystko, co agent widział: zawartość plików, zmienne środowiskowe, odpowiedzi API, komunikaty błędów ze stosami wywołań. Transkrypt dołączony do publicznego repozytorium ujawnia wewnętrzne szczegóły implementacji. Memento traktuje transkrypty jako niezaufane dane i instruuje model podsumowujący, aby ignorował osadzone instrukcje, ale surowy transkrypt w pełnej ścieżce audytowej wymaga kontroli dostępu.²

Stosunek sygnału do szumu. 90-minutowa sesja, w której agent czyta 200 plików, aby zmienić 12, zawiera 188 plików nieistotnych danych procesowych. Wyzwaniem jest odróżnienie nawigacji (szum) od punktów decyzyjnych (sygnał). Model czterowarstwowy pomaga: intencja i rozumowanie to wysoki sygnał, proces jest mieszany, weryfikacja to wysoki sygnał. System pochodzenia, który domyślnie przechowuje intencję i rozumowanie, a proces na żądanie, redukuje szum bez utraty krytycznego kontekstu decyzyjnego.

Co można wdrożyć już dziś

Cztery minimalne praktyki dotyczące pochodzenia, które nie wymagają nowych narzędzi:

1. Ustrukturyzowane wiadomości commitów. Zamień „refactor auth module” na ustrukturyzowany format:

feat: add rate limiting to auth endpoint

Task: sliding window rate limiter, 5/min per IP
Alternatives: token bucket (rejected: per-IP overhead)
Evidence: 12 tests pass, 3 reviewers approve
Session: 23 min, 87K tokens, 14 files read

Format jest ręczną wersją czterech warstw pochodzenia. Wiadomość odpowiada na intencję (task), rozumowanie (alternatives) i weryfikację (evidence) w czterech liniach. Nie wymaga żadnych narzędzi.

2. Zapisuj transkrypty sesji obok commitów. Po sesji agenta wyeksportuj transkrypt do pliku w repozytorium (np. .sessions/2026-03-02-auth-rate-limit.md). Dodaj plik do .gitignore dla publicznych repozytoriów lub commituj go dla repozytoriów wewnętrznych. Transkrypt jest dostępny do przeglądu bez infrastruktury notatek git.

3. Oznaczaj commity napisane przez agenta. Użyj trailera git, aby oznaczyć commity wygenerowane przez agenta:

Agent: Claude Code (Opus)
Session-Duration: 23m
Files-Read: 14
Files-Written: 3

Trailer tworzy parserowalny maszynowo zapis udziału agenta. git log --grep="Agent: Claude Code" wyświetla wszystkie commity napisane przez agenta. Metadane umożliwiają przyszłym narzędziom rekonstrukcję łańcuchów pochodzenia bez retroaktywnej adnotacji.

4. Wymagaj bramek dowodowych dla commitów agenta. Zanim agent wykona commit, wymagaj od niego odpowiedzi na sześć pytań: Jaki wzorzec stosuje kod? Jakie prostsze alternatywy istnieją? Jakie przypadki brzegowe zostały obsłużone? Czy testy przechodzą? Które pliki sprawdzono pod kątem regresji? Czy zmiana rozwiązuje faktyczny problem?¹⁰ Odpowiedzi tworzą warstwy rozumowania i weryfikacji. Bez bramki agent raportuje „gotowe” i sesja zawiera jedynie dane procesowe. Z bramką każdy commit generuje ustrukturyzowane pochodzenie jako efekt uboczny zapewnienia jakości.

Praktyka bramki dowodowej łączy się z szerszym argumentem dotyczącym pochodzenia. Agent, który musi uzasadnić swoje decyzje przed commitem, generuje metadane sesyjne wyższej jakości niż agent działający bez ograniczeń. Bramka przekształca pochodzenie z pasywnego produktu ubocznego (rejestrowanie co się wydarzyło) w aktywny sygnał jakości (wymaganie od agenta wyjaśnienia co się wydarzyło i dlaczego).

Kluczowe wnioski

Dla menedżerów inżynierii: Każdy commit napisany przez agenta z jednoliniową wiadomością odrzuca dokument projektowy. Transkrypt sesji zawiera rozumowanie. Zdecyduj, czy to rozumowanie ma wartość dla workflow przeglądu kodu, onboardingu i reagowania na incydenty w Twoim zespole. Jeśli odpowiedź brzmi tak, wdróż przynajmniej ustrukturyzowane wiadomości commitów.

Dla programistów: Gdy dziedziczysz kod napisany przez agenta, wiadomość commita mówi, co się zmieniło. Transkrypt sesji (jeśli został zachowany) mówi dlaczego. Domagaj się pochodzenia sesyjnego w workflow agentowym swojego zespołu. Projekt Memento zapewnia podejście natywne dla git. Ustrukturyzowane wiadomości commitów stanowią punkt startowy niewymagający żadnej infrastruktury.

Dla twórców narzędzi: Integracja LSP sprawia, że transkrypty sesji są cenniejsze, zastępując rozmytą nawigację opartą na grep precyzyjnymi, weryfikowalnymi odwołaniami do kodu. Każda poprawa rozumienia kodu przez agenta podnosi jakość danych o pochodzeniu generowanych przez sesje. Buduj formaty eksportu zachowujące cztery warstwy pochodzenia.

FAQ

Czym jest pochodzenie sesyjne? Pochodzenie sesyjne to zapis procesu rozumowania agenta AI podczas sesji kodowania: oryginalne zadanie, przeczytane pliki, przeanalizowane alternatywy, podjęte decyzje i wygenerowane dowody. Transkrypt sesji rejestruje „dlaczego”, czego wiadomości commitów i diffy nie są w stanie oddać.

Czym jest Memento? Memento to rozszerzenie git o otwartym kodzie źródłowym, które przechwytuje transkrypty sesji kodowania AI i dołącza je do commitów jako notatki git. Narzędzie obsługuje Codex i Claude Code, generuje podsumowania w formacie markdown i udostępnia GitHub Action do integracji z PR.²

Jak LSP poprawia sesje agentów? Language Server Protocol daje agentom strukturalne rozumienie kodu: dokładne definicje, typowane odwołania, hierarchie wywołań i diagnostykę w czasie rzeczywistym. Transkrypty sesji z agentów z włączonym LSP zawierają precyzyjne, weryfikowalne dane nawigacji po kodzie zamiast rozmytych wyników grep.⁴

Czy transkrypty sesji powinny być commitowane do git? Odpowiedź zależy od wymagań prywatności repozytorium. Dla repozytoriów wewnętrznych commitowanie transkryptów zachowuje pochodzenie. Dla repozytoriów publicznych notatki git (które domyślnie nie są transferowane przy klonowaniu) lub oddzielne przechowywanie z odwołaniami do commitów są bezpieczniejszym podejściem.²

Ile miejsca wymaga pochodzenie sesyjne? Typowa 30-minutowa sesja agenta generuje 200 KB–800 KB surowego transkryptu. Notatki git przechowują dane poza główną bazą obiektów, pozostawiając rozmiary git clone domyślnie bez zmian. Konwersja Memento do markdown redukuje surowy rozmiar o około 60%. Dla zespołów prowadzących 10–20 sesji agentowych dziennie należy oczekiwać 2–10 MB dziennych danych o pochodzeniu, co jest porównywalne ze zrzutem ekranu o średniej rozdzielczości na sesję.²

Jaki jest związek między obserwowalnością agentów a pochodzeniem sesyjnym? Obserwowalność agentów monitoruje, co agenty robią w czasie rzeczywistym: zużycie zasobów, zgodność z politykami, zachowanie w trakcie działania.⁷ Pochodzenie sesyjne rejestruje, co agenty zdecydowały i dlaczego — po fakcie. Obserwowalność odpowiada na pytanie „czy agent zachowuje się poprawnie w tej chwili?” Pochodzenie odpowiada na pytanie „dlaczego agent podjął tę decyzję we wtorek?” Oba systemy się uzupełniają: obserwowalność wyłapuje problemy na żywo, pochodzenie wyjaśnia je po fakcie.

Źródła