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

W tym tygodniu agent oparty na sztucznej inteligencji dostarczył Państwu kod. Zapoznał się z Państwa wytycznymi, 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 wraz z nią zniknęła cała wiedza, jaką agent zdobył na temat trudnych punktów Państwa projektu. Nikt nie zapytał jedynego uczestnika, który właśnie spędził godzinę w Państwa repozytorium, co spowodowało spowolnienie działania.

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 konkretne zmiany. Agenci AI wykonują obecnie rzeczywistą pracę w Państwa zespole — i napotykają te same trudności, co Państwa pracownicy, a czasem nawet większe. Pytanie jest więc proste. Jeśli agent wykonuje pracę zespołu, dlaczego nie bierze udziału w retrospektywie?

Niniejszy przewodnik dotyczy właśnie dodania tego „głosu”. Nie chodzi tu o nowy format retrospektywy ani o automatyzację opinii Państwa pracowników — chodzi o nowego uczestnika. Sztuczna inteligencja dostarcza informacje zwrotne, 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ą.

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

Argumentem przemawiającym za „ludzkim retro” jest to, że pamięć blaknie, a zdobyte doświadczenia nie są przekazywane dalej. W przypadku agenta opartego na sztucznej inteligencji problem ten jest jeszcze bardziej dotkliwy: jego pamięć robocza nie blaknie, lecz po prostu znika. W chwili zakończenia sesji kontekst przepada. Brakujący plik README, którego istnienie agent ten sobie życzył, zmienna środowiskowa, która nie została udokumentowana, brief, który można było interpretować na trzy sposoby — nic z tego nie zostanie przeniesione do następnej sesji, chyba że ktoś to zapisze.

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 „postępuj zgodnie ze 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, której nikt nie zaleca uruchomienia.

Ludzki programista również napotyka takie problemy, wzrusza ramionami, znajduje obejście i rzadko zgłasza je — utrudnienia te nie są na tyle istotne, by „warto było poruszyć tę kwestię 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. Zachowajcie 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 czy 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 — momenty, które warto zapamiętać, powiązane z konkretnymi wydarzeniami, które miały miejsce podczas sesji. Nie chodzi o pochwały ani o wypełniacze. Jeśli nie da się tego powiązać z konkretnym momentem, nie należy tego uwzględniać.
2. Przeszkody — sytuacje, w których praca stała się trudniejsza, niż to było konieczne. Każda przeszkoda jest oznaczona jedną z dziesięciu ustalonych etykiet określających przyczynę źródłową (poniżej) oraz — i to właśnie ta zasada sprawia, że jest to przydatne — zakończona jest napisem „→ Rozwiązanie:” wielkości zgłoszenia. Nie ma ustalenia bez rozwiązania.
3. Najważniejsze rozwiązanie z serii „Zrób to najpierw” — jedyna zmiana, która przyniosłaby największą korzyść. Jedna pozycja, umieszczona na samym początku, dzięki czemu zapracowany czytelnik, który nie zapozna się z resztą tekstu, przeczyta to, co ma największe znaczenie.
4. Wypowiedziane przypuszczenia — każde miejsce, 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 niekompletny; agent pokazuje Państwu dokładnie, gdzie musiał wymyślić odpowiedź.

Dwie zasady zapewniają 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ólnikowych 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 odczytał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żdy element powodujący utrudnienia otrzymuje dokładnie jedną etykietę. Stały, niewielki zestaw terminów pozwala przekształcić zbiór pojedynczych zastrzeżeń 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ść tego dokumentu 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
codebase-friction	To właśnie sam kod utrudniał wprowadzenie tej zmiany — zagmatwana struktura, brak płynnych przejść.	Kod źródłowy / zaległości związane z długiem technologicznym
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ł, pomylił kierunek, 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 dało o sobie znać — niestabilne kompilacje, powolna konfiguracja, niesprawne narzędzia.	Doświadczenie programistów

Proszę zwrócić uwagę, jak 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, codebase-friction, environment-friction. Aagent-error odnosi się do wykonawcy. Właśnie o to chodzi: dzięki temu dziennik nie staje się listą skarg, lecz mapą wskazującą, gdzie z każdej strony konieczne są ulepszenia.

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

W etapie przechwytywania nie trzeba instalować żadnego oprogramowania. Agent zapisuje danedocs/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 wywołała.
• grepMożna to porównać i przeszukać za pomocą grep. Chcą Państwo uzyskać wszystkiemissing-documentationpozycje z ostatniego miesiąca? To proste. Chcą Państwo 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 dowolnym agentem, dowolnym edytorem i dowolnym procesem. Nie ma tu żadnych rozwiązań zastrzeżonych, nie ma też potrzeby późniejszej migracji.

Oto przykładowy wpis ilustrujący tę kwestię — jest to fikcyjna sesja mająca na celu pokazanie ogólnego schematu, 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. (codebase-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 hipotezy, a każde zadanie ma wskazany 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 streszczenie na potrzeby spotkania: powtarzające się problemy, najczęstsze rozwiązania pogrupowane według etykiet oraz przypuszczenia, które nieustannie powracają w tym samym miejscu. Podlega on tym samym standardom co same wpisy — żadnych 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 ta ludzka strona, która pozostaje niezmienna:

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ść jedną lub dwie pierwsze pozycje na tablicy, obok tego, co przynieśli Pańscy pracownicy. Teraz notatka sztucznejmissing-documentation inteligencji znajduje się obok komentarza kolegi z zespołu: „wdrożenie zajęło mi tydzień” — i widać, że chodzi o ten sam problem.
3. Przedyskutujcie to i podejmijcie decyzję wspólnie jako zespół. Agent poruszył tę kwestię; to obecni w pomieszczeniu ludzie decydują o dalszym przebiegu wydarzeń. Niektóre sprawy zrealizujecie, inne odłożysz na później, a z jeszcze innymi się nie zgodzicie. 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 nic nie kosztuje:

• Przy użyciu dowolnego narzędzia do retrospektywy. 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, z której Państwo korzystają — 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 TeamRetro agent publikuje posty samodzielnie. Jeśli Państwa zespół prowadzi retrospektywy w TeamRetro, agent może przygotować swoje 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 kolejnego spotkania retrospektywnego, działania w sytuacjach, gdy za poprawkę odpowiada już konkretna osoba, lub pomysły zgłaszane bezpośrednio na tablicę roboczą. Każda opublikowana pozycja ma przedrostek [AI retro], dzięki czemu uczestnicy spotkania mogą sprawdzić, 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 zgłasza.

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 kończący sesję) orazai-retro-brief (syntezuje wpisy w podsumowanie przed sesją retrospektywną) nie wymagają żadnego produktu, ateamretro-post-recommendations dodaje ś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. Sklonuj repozytorium i dodaj umiejętności do swojej konfiguracji Claude Code lub skopiuj pakiet podpowiedzi, jeśli korzystają Państwo z innego narzędzia.
2. Nie korzystają Państwo z Claude Code? Ten pakiet poleceń został opracowany z myślą o współpracy z Cursorem, GitHub Copilotem lub dowolnym agentem, któremu można przekazać polecenie systemowe — ta sama czteroczęściowa struktura, te same dziesięć etykiet, ta sama zasada „brak wyników bez rozwiązania”.
3. Przeprowadź jedną sesję z włączonym programem. Na koniec przeczytaj zapisany przez niego wpis. To pierwsze przeczytanie jest zazwyczaj momentem olśnienia — program 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óreagent-errorniedociągnięcia są niewidoczne dla agenta, który je spowodował — nie wie on bowiem, czego nie wie. Sprawdzanie przez człowieka nie jest zbędnym dodatkiem; to właśnie w ten sposób 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 można było wyciągnąć z nich jakieś wnioski. Pojedyncze utrudnienie podczas sesji może być po prostu pechowym zbiegiem okoliczności; 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 to dokumentacja jest poprawna, a agent ją błędnie zinterpretował. Informacja ta jest nadal przydatna (oznacza bowiem, że dokumentację łatwo jest błędnie zinterpretować), ale wymaga innego rozwiązania.
• Niewyraźne wytyczne prowadzą do nieudanych wpisów. Praktyka ta ujawnia tylko tarcia; nie tworzy nowych spostrzeżeń tam, gdzie ich nie było. Sesja oparta na jasnych wytycznych i uporządkowanym repozytorium skutkuje krótkim, nudnym wpisem — co jest całkowicie słuszne.

Żadna z tych kwestii nie podważa zasadności tego argumentu. Państwa agenci oparci na sztucznej inteligencji już wykonują tę pracę i już napotykają przeszkody. Jedynym pytaniem jest to, czy się o tym dowiadują Państwo. Pod koniec sesji proszę dać im chwilę na przekazanie informacji, przeanalizować otrzymane dane w oparciu o ludzki osąd, a następnie uwzględnić szczere uwagi w retrospektywie, którą już Państwo prowadzą — tuż obok Państwa pracowników, gdzie właśnie powinno znaleźć się sprzężenie zwrotne od uczestników.

---

Chcieliby Państwo poznać historię tego, co się wydarzyło, gdy zastosowaliśmy to rozwiązanie w naszym własnym zespole? Przeczytaj nasza sztuczna inteligencja dołączyła do naszej retrospektywy — oto, co nam powiedziała. Tworzą Państwo pliki kontekstowe dla swoich agentów? Dowiedz się, dlaczego inżynieria kontekstowa wymaga pętli informacji zwrotnej. A jeśli dopiero zaczynają Państwo organizować retrospektywy, zacznij od jak przeprowadzić retrospektywę w metodologii agile.