Jak zebrać opinie od Państwa agentów opartych na sztucznej inteligencji

W tym tygodniu agent oparty na sztucznej inteligencji dostarczył Panu/Pani kod. Zapoznał się z Pańskim/Pani briefem, przeanalizował bazę kodu, natrafił na przeszkodę wynikającą z błędnej dokumentacji, samodzielnie znalazł sposób na jej pokonanie i kontynuował pracę. Następnie sesja dobiegła końca, a cała wiedza, jaką zdobył na temat trudnych punktów Pańskiego/Pani projektu, została utracona. Nikt nie zapytał jedynego uczestnika, który właśnie spędził godzinę w Państwa repozytorium, co spowodowało spowolnienie.

Retrospektywy mają na celu właśnie wypełnienie tej luki: zespół spotyka się, określa, co pomogło, a co stanowiło przeszkodę, i przekształca te spostrzeżenia w zmiany. Agenci AI wykonują obecnie rzeczywistą pracę w Państwa zespole i napotykają te same trudności, co Państwa pracownicy, a czasami nawet większe. Pytanie jest więc proste. Jeśli agent wykonuje pracę zespołu, dlaczego nie jest uwzględniony w retrospektywie?

Niniejszy przewodnik dotyczy włączenia tego „głosu”. Nie chodzi tu o nowy format retrospektywy ani o automatyzację opinii Państwa pracowników, lecz o nowego uczestnika. Sztuczna inteligencja dostarcza informacji zwrotnych, ale to Państwa zespół nadal decyduje, co one oznaczają. Oto jak je zebrać i jak włączyć je do retrospektywy, którą już Państwo prowadzą.

Niniejszy wpis stanowi wprowadzenie do tematu. W ramach tej praktyki dostępny jest już kompletny przewodnik, Retrospektywy agentów AI, obejmujący cały cykl — od rejestracji zdarzeń po ceremonię zespołową; proszę zacząć od tego wpisu, a następnie przejść tam, aby uzyskać pełny obraz sytuacji.

Dlaczego warto rejestrować doświadczenia Państwa agenta opartego na sztucznej inteligencji

Argumentem przemawiającym za ludzkim „retro” jest to, że pamięć blaknie, a wnioski nie są przekazywane innym. W przypadku agenta AI problem ten jest jeszcze bardziej dotkliwy: jego pamięć robocza nie blaknie, lecz po prostu znika. W chwili zakończenia sesji kontekst przepada. Żadna z tych informacji nie jest przenoszona do kolejnej sesji, chyba że ktoś ją zapisze: brakujący plik README, którego istnienie agent by sobie życzył, niezadokumentowana zmienna środowiskowa, a także brief, który można było zinterpretować na trzy różne sposoby.

Ponadto agenci gromadzą specyficzny, użyteczny rodzaj sygnałów. W ciągu godziny pracy agent dostrzega rzeczy, które człowiek pomija, ponieważ ma już w głowie odpowiedni kontekst:

• Dokument wprowadzający, w którym opisano etap kompilacji, który już nie istnieje.
• Funkcja ta jest wykorzystywana w różny sposób w trzech miejscach wywołania, dlatego wskazówka „proszę kierować się wzorcem” odnosi się do trzech wzorców.
• Zadanie, w którym napisano „uporządkować konfigurację”, nie precyzując jednak, o jaką konfigurację chodzi ani w jaki sposób należy to zrobić.
• Zestaw testów, który wymaga uruchomienia usługi, o której nikt nie informuje, że należy ją uruchomić.

Ludzki programista również napotyka te problemy, wzrusza ramionami, radzi sobie z nimi i rzadko zgłasza je, ponieważ utrudnienia te nie osiągają poziomu, który „warto poruszyć na spotkaniu”. Agent, poproszony we właściwy sposób, zgłosi każdą z nich, dołączając odpowiednie dowody. Na tym polega wartość: nie na tym, że sztuczna inteligencja lepiej rozumie Państwa proces, ale na tym, że stanowi ona świeże spojrzenie, pozbawione ego i nagromadzonej tolerancji na drobne utrudnienia. Współpraca między człowiekiem a sztuczną inteligencją przebiega najlepiej, gdy obie strony mogą wskazać, co spowolniło ich pracę.

Zanim przejdziemy dalej, należy ustalić jedną zasadę, ponieważ ma ona decydujący wpływ na wszystko, co nastąpi później. Sztuczna inteligencja jest uczestnikiem, a nie moderatorem ani sędzią. Wnosi ona swoje uwagi do retrospektywy tak samo, jak każdy inny uczestnik. Nie prowadzi ona spotkania, nie ocenia Państwa zespołu ani nie decyduje o tym, co należy poprawić. Ludzie zapoznają się z jej informacją zwrotną, weryfikują jej zasadność i wybierają to, co ma znaczenie. Proszę zachować tę granicę, a praktyka pozostanie zdrowa; zatarcie jej oznacza przekazanie procesu doskonalenia narzędziu, które nie może ponosić odpowiedzialności za wynik.

Trening: podsumowanie na zakończenie sesji

Mechanizm ten jest celowo niewielki. Pod koniec sesji roboczej (zadania programistycznego, pracy badawczej, refaktoryzacji) agent zapisuje jeden rzetelny wpis retrospektywny do pliku w repozytorium, w którym pracował. Zajmuje to agentowi mniej niż minutę. Człowiek poświęca mniej więcej tyle samo czasu na sprawdzenie poprawności tego wpisu. Na tym polega cały cykl.

Dobry wpis składa się z czterech części:

1. Co się udało: chwile, które warto zapamiętać, odnoszące się do konkretnych wydarzeń, które miały miejsce podczas sesji. Nie są to pochwały ani wypełniacze. Jeśli nie można odnieść się do konkretnego momentu, nie należy tego uwzględniać.
2. Przeszkody: sytuacje, w których praca stała się trudniejsza, niż to konieczne. Każda przeszkoda jest oznaczona jedną z dziesięciu stałych etykiet określających przyczynę źródłową (poniżej) i zakończona napisem „→ Rozwiązanie:” w formacie zgłoszenia – zasadą, dzięki której staje się ona przydatna. Nie ma ustalenia bez rozwiązania.
3. Najważniejsze rozwiązanie z serii „Zrób to najpierw”: pojedyncza zmiana, która przyniosłaby największą korzyść. Jedna pozycja, umieszczona na samym początku, dzięki czemu zabiegany czytelnik, który nie zapozna się z pozostałą treścią, przeczyta to, co ma największe znaczenie.
4. Wysunięte przypuszczenia: każdy punkt, w którym agent wypełnił lukę za pomocą przypuszczenia. Są one na wagę złota. Przypuszczenie to miejsce, w którym kontekst był niejednoznaczny lub go brakowało; agent pokazuje Państwu dokładnie, gdzie musiał wymyślić odpowiedź.

Dwie zasady gwarantują wiarygodność wpisów. Wyłącznie sytuacje poparte dowodami: każdy punkt odnosi się do czegoś, co faktycznie miało miejsce, dzięki czemu nikt nie czyta ogólnych porad. Ponadto uczciwość działa w obie strony: agent ocenia przekazany mu materiał oraz własne błędy. Wpis, który obwinia wyłącznie kod źródłowy i nigdy nie zawiera stwierdzenia „Źle to zinterpretowałem i straciłem dwadzieścia minut”, nie jest uczciwy; praktyka ta wymaga uwzględnienia obu aspektów.

Dziesięć kategorii przyczyn źródłowych

Każda przeszkoda otrzymuje dokładnie jedną etykietę. Stały, niewielki zestaw terminów pozwala przekształcić zbiór pojedynczych problemów w wzorzec, na podstawie którego można podjąć działania: gdy ta sama etykieta pojawia się w dziesięciu sesjach, wiadomo, na czym należy skupić się w ciągu najbliższej godziny. Te dziesięć etykiet obejmuje wszystkie sposoby, w jakie rzeczywista praca napotyka przeszkody.

Etykieta	Co to oznacza	Gdzie zazwyczaj pojawia się poprawka
ambiguous-instruction	Treść pisma można interpretować na więcej niż jeden sposób.	Osoba sporządzająca zadanie
missing-context	Nie przekazano informacji, których potrzebował agent.	Zadanie lub wspólny kontekst
incorrect-context	Przekazane informacje były błędne lub nieaktualne.	Zadanie lub wspólny kontekst
missing-documentation	W repozytorium brakuje informacji, które powinny się tam znajdować.	Dokumentacja / CLAUDE.md / AGENTS.md
incorrect-documentation	Dokumentacja istnieje, ale zawiera błędy lub jest nieaktualna.	Dokumentacja / CLAUDE.md / AGENTS.md
work-material-friction	Trudności w wprowadzeniu zmiany wynikały z charakteru opracowywanego materiału (nieuporządkowany kod, konto lub szablon).	Zaległości w zakresie zadań roboczych / długu technicznego
missing-access-or-tool	Brakowało poświadczenia, uprawnienia lub narzędzia.	Operacje / platforma / kontrola dostępu
agent-error	Agent popełnił błąd: źle to zinterpretował, popełnił błąd, zmarnował wysiłek.	Własna relacja agenta, szczera
changed-requirements	Bramka została przesunięta w trakcie sesji.	Planowanie / zarządzanie zakresem
environment-friction	Środowisko programistyczne postawiło opór: niestabilna kompilacja, powolna konfiguracja, niesprawne narzędzia.	Doświadczenie programistów

(Wersja 2 umiejętności została przemianowana codebase-frictionna work-material-friction; starsze wpisy zawierające poprzednią nazwę nadal zaliczają się do tej samej kategorii.)

Proszę zwrócić uwagę, w jaki sposób etykiety jasno rozdzielają zakres odpowiedzialności. Niektóre odnoszą się do Państwa: ambiguous-instruction, missing-context. Niektóre odnoszą się do projektu: missing-documentation, work-material-friction, environment-friction. A agent-errorodnosi się do wykonawcy. O to właśnie chodzi w tym rozłożeniu odpowiedzialności: zapobiega ono przekształceniu dziennika w listę skarg i sprawia, że staje się on mapą obszarów wymagających poprawy po każdej ze stron.

Dziennik: zwykły format Markdown w Państwa repozytorium

W etapie przechwytywania nie ma potrzeby instalowania żadnego oprogramowania. Agent zapisuje dane docs/ai-retros/entries/w formacie zwykłego Markdownu, które są zatwierdzane wraz z kodem. Jest to świadomy wybór:

• Znajduje się tam, gdzie miała miejsce praca. Konflikt miał miejsce w tym repozytorium; tam też znajduje się jego zapis. Każdy, kto zapozna się z historią git, zobaczy komentarz obok zmiany, która go spowodowała.
• Można to porównać za pomocą narzędzia diff i przeszukiwać za pomocą grep. Chce Pan uzyskać wszystkie missing-documentationpozycje z ostatniego miesiąca? To prostegrep. Chce Pan sprawdzić, czy wskaźnik tarcia spadł po naprawieniu kompilacji? Informacje te znajdują się w systemie kontroli wersji.
• Rozwiązanie to jest niezależne od narzędzi. Markdown w folderze działa z każdym agentem, każdym edytorem i w każdym procesie. Nie ma tu żadnych rozwiązań zastrzeżonych ani elementów wymagających późniejszej migracji.

Oto przykładowy wpis ilustrujący tę kwestię. Jest to fikcyjna sesja mająca na celu pokazanie struktury danych, a nie rzeczywiste dane pilota:

# Session retro — add rate limiting to the public API
Agent: Claude Code · 2026-07-13 · ~50 min

## Do this first
→ Fix: Document the Redis connection setup in CLAUDE.md — three of us
  will hit this same wall. (missing-documentation)

## What went well
- The `middleware/` folder has a clear pattern; the existing auth
  middleware was a clean model to copy for the rate limiter.
- Tests ran fast once the service was up.

## Friction
- Nothing documented that the test suite needs Redis running locally.
  Spent ~15 min chasing a connection error before finding it by reading
  docker-compose.yml. (missing-documentation)
  → Fix: Add a "Running tests locally" section to CLAUDE.md naming the
    Redis dependency and the `docker compose up redis` command.
- The brief said "add sensible rate limits" without numbers. I chose
  100 req/min per key. (ambiguous-instruction)
  → Fix: Decide the real limits with the team and put them in the ticket.
- `config/limits.ts` and `config/throttle.ts` both looked like the right
  home for the setting; I couldn't tell which was canonical. (work-material-friction)
  → Fix: Merge or clearly comment which config owns rate limiting.

## Guesses I made
- Assumed 100 req/min because the payment endpoints use that. May be
  wrong for read-heavy public endpoints — please check.
- Assumed rate-limit responses should be 429 with a Retry-After header.

Proszę potraktować to jako notatkę uczestnika, bo właśnie tym jest. Jest konkretna, zawiera własne przypuszczenia, a każde zadanie ma określony kolejny krok.

Włączenie tego do retrospektywy Państwa zespołu

Poszczególne wpisy stanowią surowiec. Przed spotkaniem podsumowującym przeprowadzany jest dodatkowy etap syntezy, w ramach którego analizowane są wpisy od ostatniego spotkania i tworzone jest jednostronicowe podsumowanie na potrzeby spotkania: powtarzające się problemy, najczęstsze rozwiązania pogrupowane według etykiet oraz przypuszczenia, które wciąż pojawiają się w tym samym miejscu. Podlega on tym samym standardom co same wpisy (bez pochwał ani wypełniaczy, żadnych ustaleń bez rozwiązania), a jego rzetelność działa w obie strony: krytykuje przekazane mu wpisy (słabe dowody, rozwiązanie zbyt niejasne, by można było je wdrożyć) równie chętnie, jak je podsumowuje.

A następnie aspekt ludzki, który pozostaje niezmienny:

1. Proszę zapoznać się z dokumentem przed spotkaniem podsumowującym: potraktujcie go jako materiał do przeczytania przed spotkaniem przygotowany przez kolejnego uczestnika, a nie jako porządek obrad.
2. Umieśćcie na tablicy jedną lub dwie pierwsze pozycje, obok tego, co przynieśli Państwa pracownicy. Teraz missing-documentationnotatka sztucznej inteligencji znajduje się obok komentarza kolegi z zespołu „wdrożenie zajęło mi tydzień” i widać, że dotyczą one tego samego problemu.
3. Przedyskutujcie to i podejmijcie decyzję wspólnie jako zespół. Agent poruszył tę kwestię; to Państwo, obecni w tym pomieszczeniu, decydują o dalszym przebiegu wydarzeń. Niektóre sprawy zostaną zrealizowane, inne odłożone na później, a z jeszcze innymi się Państwo nie zgodzą. To wszystko jest w porządku: chodzi o wkład uczestników, a nie o dyktat systemu.

Istnieją dwa sposoby na zakończenie tego ostatniego etapu, a pierwszy z nich jest bezpłatny:

• Przy użyciu dowolnego narzędzia do retrospektyw. Opis zadania to tylko dokument. Proszę zapoznać się z nim przed spotkaniem, a następnie dodać jedną lub dwie najważniejsze pozycje do dowolnej tablicy, w tym do karteczek samoprzylepnych. Cała praktyka działa w ten sposób od początku do końca, bez konieczności korzystania z TeamRetro ani żadnego innego konkretnego produktu.
• W przypadku TeamRetro agent samodzielnie publikuje posty. Jeśli Państwa zespół przeprowadza sesje retrospektywne w TeamRetro, agent może przygotować zalecenia na podstawie dziennika i – po uzyskaniu Państwa potwierdzenia w odniesieniu do każdej pozycji – opublikować je za pośrednictwem serwera MCP TeamRetro: pozycje odłożone do kolejnej sesji retrospektywnej, działania w przypadku, gdy za poprawkę odpowiada już konkretna osoba, lub pomysły przekazywane bezpośrednio na tablicę roboczą. Każda opublikowana pozycja ma przedrostek [AI retro], dzięki czemu uczestnicy spotkania mogą zobaczyć, który z nich ją zgłosił. Na tym polega różnica w skrócie: zamiast tego, by to Państwo przekazywali informacje zwrotne od sztucznej inteligencji na spotkaniu, uczestnik sam je przedkłada.

Rozpoczęcie pracy w około 10 minut

Całość jest oprogramowaniem typu open source na licencji MIT. Repozytorium teamretro-skills obejmuje obie ścieżki: ai-session-retro(tworzy wpis podsumowujący sesję) oraz ai-retro-brief(syntezuje wpisy w podsumowanie przed sesją retrospektywną) nie wymagają żadnego produktu, a teamretro-post-recommendationsdodaje ścieżkę publikacji dla zespołów korzystających z TeamRetro. Całość uzupełnia zestaw podpowiedzi niezależny od narzędzi.

Na początek:

1. Skopiujcie repozytorium i dodajcie umiejętności do swojej konfiguracji Claude Code lub pobierzcie pakiet podpowiedzi, jeśli korzystacie z innego narzędzia.
2. Nie korzystają Państwo z Claude Code? Ten zestaw podpowiedzi został opracowany z myślą o współpracy z Cursor, GitHub Copilot lub dowolnym agentem, któremu można przekazać podpowiedź systemową: ten sam czteroczęściowy wpis, te same dziesięć etykiet, ta sama zasada „żadnych wyników bez rozwiązania”.
3. Przeprowadź jedną sesję z włączoną tą funkcją. Na koniec przeczytaj zapisany wpis. To pierwsze przeczytanie jest zazwyczaj momentem, w którym wszystko staje się jasne: agent wskaże jakiś aspekt Państwa projektu, o którym mieli Państwo mgliste pojęcie, ale którego nigdy nie zapisali Państwo.

Proszę skierować te wpisy do folderudocs/ai-retros/entries/ w dowolnym repozytorium, w którym działają Państwa agenci, zatwierdzić je – i gotowe.

Rzeczywiste ograniczenia

Jest to młoda kancelaria, która zdobywa zaufanie dzięki szczerości w kwestii tego, czego nie jest w stanie zrobić.

• Sztuczna inteligencja nie jest w stanie dostrzec wszystkich własnych błędów. Niektóre agent-errorniedoskonałości są niewidoczne dla agenta, który je spowodował. Nie wie on o tym, czego nie wie. Sprawdzanie przez człowieka nie jest opcjonalnym dodatkiem; to właśnie dzięki niemu wykrywa się te „martwe punkty”. Dlatego właśnie sztuczna inteligencja pozostaje uczestnikiem, a nigdy sędzią.
• Jeden wpis to tylko anegdota. Potrzeba mniej więcej pięciu wpisów, aby dostrzec jakiekolwiek prawidłowości. Trudności podczas pojedynczej sesji mogą wynikać po prostu z pecha; pięć razy ta sama etykieta to już sygnał. Proszę poczekać kilka tygodni, zanim wyciągnie Pan/Pani jakiekolwiek wnioski.
• Agent przekazuje swoje spostrzeżenia, a nie fakty rzeczywiste. Gdy stwierdza, że dokumentacja jest błędna, należy to sprawdzić: czasami dokumentacja jest poprawna, a agent ją błędnie zinterpretował. Informacja ta jest nadal przydatna (oznacza bowiem, że dokumentację łatwo zinterpretować błędnie), ale wymaga innego rozwiązania.
• Niewyraźne wytyczne prowadzą do nieudanych wpisów. Praktyka ta ujawnia tarcia; nie tworzy ona wglądu tam, gdzie go nie było. Sesja oparta na jasnych wytycznych i uporządkowanym repozytorium skutkuje krótkim, nudnym wpisem, co jest całkowicie słuszne.

Nic z tego nie podważa zasadności tego argumentu. Państwa agenci AI już wykonują tę pracę i już napotykają przeszkody. Jedynym pytaniem jest, czy się o tym dowiadują Państwo. Proszę dać im chwilę pod koniec sesji, aby mogli Państwu o tym opowiedzieć, przeanalizować otrzymane informacje w świetle ludzkiej oceny sytuacji, a następnie uwzględnić szczere uwagi w podsumowaniu, które i tak już Państwo przeprowadzają. To właśnie tam należy umieścić informacje zwrotne od uczestników: tuż obok opinii Państwa pracowników.

Całą pętlę pokonaliśmy wyłącznie w składzie naszej drużyny, łącznie z agentami. Zobaczcie, co się stało, gdy nasi koledzy z drużyny oparci na sztucznej inteligencji dołączyli do naszej sesji retrospektywnej.

---

Tworzą Państwo pliki kontekstowe dla swoich agentów? Dowiedzcie się, dlaczego inżynieria kontekstowa wymaga pętli informacji zwrotnej. A jeśli dopiero zaczynają Państwo organizować retrospektywy, zacznijcie od poradnika dotyczącego prowadzenia retrospektywy agile.