Do Państwa zespołu dołączyli agenci oparci na sztucznej inteligencji. Państwa cykl doskonalenia tego nie wykrył.

Niniejszy przewodnik dotyczy zastosowania czegoś, co zespoły już znają – cyklu ciągłego doskonalenia – do czegoś nowego: pracy, którą Państwa zespół obecnie wykonuje z wykorzystaniem agentów sztucznej inteligencji. Tworzymy oprogramowanie do retrospektywy, więc właśnie tę perspektywę znamy najlepiej; opisany w nim cykl sprawdza się niezależnie od narzędzi i procedur, z których już Państwo korzystają.

Chcieliby Państwo najpierw zapoznać się z wersją skróconą (10 minut)? Proszę zacząć od wpisu poświęconego szybkiemu startowi, zbieranie opinii od agentów AI, a następnie wrócić tutaj, aby uzyskać pełny obraz sytuacji.

Najstarsza sztuczka w pracy zespołowej

Każda metoda, którą stosuje Państwa zespół w celu doskonalenia się, stanowi odmianę jednego cyklu: wykonaj zadanie, oceń, jak poszło, wprowadź zmianę, sprawdź, czy zmiana przyniosła korzyść. Deming wprowadził tę koncepcję do przemysłu wytwórczego jako cykl Plan–Do–Check–Act; firma Toyota uczyniła z niej część swojej kultury organizacyjnej i nazwała ją kaizen; w branży oprogramowania stała się ona rytuałem. Książka Norma Kertha Project Retrospectives (2001) spopularyzowała retrospektywę wśród zespołów programistycznych, a Manifest agile uznał ją za jedną z zasad: „W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć swoją skuteczność, a następnie odpowiednio dostosowuje i koryguje swoje działania” (zasada 12). Bezwinne analizy po zdarzeniu przebiegają według tego samego schematu w przypadku incydentów; podsumowanie kampanii przez zespół medialny oraz przegląd priorytetów przez zespół wsparcia odbywają się zgodnie z tym schematem, choć nigdy nie używa się w nich słowa „agile”.

Pętla ta działa w oparciu o jedną zasadę: praca dostarcza dowodów na to, w jaki sposób powinna ulec zmianie. Zespoły, które wykorzystują te dowody, osiągają efekt kumulacyjny: każdy cykl sprawia, że następny jest lepszy. Zespoły, które tego nie robią, powtarzają te same działania.

Przez siedemdziesiąt lat informacje pochodziły od ludzi. Ludzie zauważali tarcie, skarżyli się podczas lunchu, poruszali tę kwestię w retro. Czujnikami pętli byli ludzie.

Nowy typ pracownika

W ciągu ostatnich dwóch lat Państwa zespół zaczął powierzać rzeczywiste zadania nowemu rodzajowi pracowników. Agenci sztucznej inteligencji zajmują się obecnie pisaniem i sprawdzaniem kodu, kontrolowaniem kont reklamowych, przygotowywaniem odpowiedzi dla działu obsługi klienta, tworzeniem raportów oraz przenoszeniem treści. A pracownik ten ma niezwykły profil: jest niestrudzony, szybki, kompetentny i pozbawiony kontekstu. Sformułowanie Rahula Garga stało się skrótem stosowanym w tej dziedzinie: „Asystenci AI są jak młodsi programiści z nieskończoną energią, ale bez żadnego kontekstu”, dlatego też „czas zaoszczędzony dzięki kodowi wygenerowanemu przez AI jest często pochłaniany przez wysiłek wymagany do jego poprawienia” (Wzory na zmniejszenie tarć w programowaniu wspomaganym przez AI).

Kosztem tej korekty jest tarcie, a praca agenta nieustannie je generuje: niejasna specyfikacja, która zmusiła do zgadywania; dokument, który nie istniał; struktura konta, która sprawia problemy podczas każdej sesji; narzędzie, które przekroczyło limit czasu; wymaganie, które uległo zmianie w trakcie zadania. Nie ma w tym nic nowego. Praca ludzka generuje tę samą listę. Dwie rzeczy w tym kontekście są jednak nowe.

Nowy pracownik nie narzeka podczas przerwy obiadowej. Pracownik napotyka przeszkodę, znajduje sposób na jej obejście i kontynuuje pracę. Nie odczuwa na tyle dużej frustracji, by poruszyć tę kwestię podczas piątkowej sesji retrospektywnej. Sygnał, na którym zawsze opierał się Państwa cykl doskonalenia (osoba zwracająca uwagę na utrudnienia do momentu, gdy zostaną one zebrane podczas ceremonii), nie zostaje wysłany.

A dowody znikają. Gdy sesja się kończy, kontekst konfliktu zanika wraz z nią. Kolejna sesja (inna osoba, ten sam agent) napotyka tę samą przeszkodę od nowa. Nie da się poprawić sytuacji w oparciu o dowody, których nigdy się nie zebrano; pętla cicho się wyczerpuje, podczas gdy praca wydaje się przebiegać bez zarzutu.

Sytuacja wygląda więc następująco, mówiąc wprost: coraz większa część pracy Państwa zespołu dostarcza obecnie dowodów na poprawę, których Państwa cykl doskonalenia nigdy nie był przystosowany do gromadzenia.

Pole to zauważyło i samodzielnie odbudowało pętlę

Osoby najbardziej zaangażowane w prace nad agentami dostrzegły to już na wczesnym etapie, a do połowy 2026 r. „wykrywanie tarcia agenta i przekazywanie informacji zwrotnej” stało się powszechną praktyką znaną pod co najmniej pół tuzinem nazw: Feedback Flywheel autorstwa Garga, Compound Engineering autorstwa Every’ego, Loop Engineering autorstwa Osmaniego, sensor-instrumented harness engineering firmy Thoughtworks, pętle pamięciowe na skalę floty oferowane przez dostawców platform („dreaming” firmy OpenAI, Factory Signals) oraz gh-aw serwisu GitHub, którego przepływy pracy oparte na analizie sesji już generują zautomatyzowane raporty z analizy sesji. Nawet dostawcy sięgają po to retro termin: w wytycznych OpenAI dotyczących Codexa czytamy: „gdy Codex popełni ten sam błąd dwukrotnie, poproście go o przeprowadzenie retrospektywy i zaktualizujcie plik AGENTS.md” (najlepsze praktyki).

Te pętle są przydatne. Jeśli Państwa zespół korzysta z którejkolwiek z nich, proszę je zachować; wszystkie elementy zawarte w niniejszym przewodniku opierają się na nich, a nie zastępują ich. Należy jednak zwrócić uwagę na dwie luki.

Po pierwsze, luka w praktyce: samo obserwowanie nie prowadzi do poprawy. Około 90% zespołów wdraża narzędzia do śledzenia działania agentów; jedynie około 37–52% z nich systematycznie analizuje zebrane dane (LangChain, czerwiec 2026). Większość zespołów dysponuje pulpitem analitycznym. Znacznie mniej z nich stosuje cykl poprawy.

Po drugie, luka w spójności: prawie każdy cykl w tej dziedzinie przebiega w izolacji. Jeden specjalista dostosowuje swój osobisty zestaw procedur, jedna platforma zarządza pamięcią swojej floty, jeden stos narzędzi do obserwowalności grupuje własne ślady. Siedemdziesiąt lat ciągłego doskonalenia pokazuje, że efekt kumulacji zachodzi na poziomie zespołu: tam, gdzie powstaje widok zbiorczy, gdzie na nowo ustala się priorytety, gdzie procesy, dokumentacja i budżety mają swoich właścicieli. Właśnie tej warstwy nikt jeszcze nie przebudował. Raporty istnieją; sala nie została jeszcze zarezerwowana.

Budowa pętli

Kiedy Państwa zespół zdecyduje się to podłączyć, okaże się, że pętla składa się z większej liczby elementów ruchomych, niż mogłoby się wydawać na pierwszy rzut oka. Droga, jaką musi pokonać pojedynczy element powodujący tarcie:

Scena	Pytanie
Hosting	Gdzie działa agent i co dzięki temu można zaobserwować?
Wykrywanie	W jaki sposób wykrywa się tarcie? (Samokontrola, mechanizm monitorujący, telemetria oraz interwencja człowieka, która nadal stanowi dominujący sposób wykrywania: ~70% cichych awarii jest najpierw wykrywanych przez człowieka)
Oprzyrządowanie	Co sprawia, że agent to odnotowuje? (Nikt nie odnotowuje problemów, o których nie poinformowano go, aby zwracał na nie uwagę)
Nagranie	Co zawiera przydatny rekord i gdzie się on znajduje?
Zbiory	W jaki sposób łączą się zapisy z wielu sesji i od wielu osób?
Podsumowanie	Które wzorce mają znaczenie i na jakim poziomie należy wprowadzić poszczególne poprawki?
Zamknąć obieg	Czy to rozwiązanie rzeczywiście zmniejszyło tarcie, czy też była to tylko gra na pokaz?

Trzy obszary decydują o tym, czy mamy do czynienia z pętlą, czy z dziennikiem, a każdy z nich ma swój własny rozdział w niniejszym przewodniku:

• Zapisy, a nie wrażenia. Przydatny wpis odnosi się do konkretnego momentu, wskazuje jedną podstawową przyczynę spośród niewielkiego, ustalonego zestawu pojęć oraz proponuje rozwiązanie w formie zgłoszenia. To właśnie ustalone etykiety pozwalają na agregowanie wpisów: „dokumentacja była niejasna” nie może zostać uwzględnione; osiem wpisówmissing-documentation – już tak. (Rozdział: Jak wygląda dobry wpis dotyczący utrudnień)
• Kwestia poziomu wdrożenia poprawki. Każdy powtarzający się problem jest rozwiązywany na jakimś poziomie: w notatce, podpowiedzi, pliku konfiguracyjnym, dokumentacji, samym materiale roboczym, procesie lub u dostawcy. Jeśli poprawka zostanie wdrożona na zbyt niskim poziomie, problem powróci u wszystkich pozostałych użytkowników; jeśli natomiast na zbyt wysokim, spowoduje to nadmierne rozbudowanie dokumentacji, której nikt nie czyta. (Rozdział: Gdzie należy wprowadzić poprawkę?)
• Ocena w ramach zespołu. Niektóre utrudnienia są zamierzone: etap weryfikacji, który ktoś wybrał jako punkt kontrolny (podsumowanie wystąpienia Ronachera podczas konferencji AIE Europe: „utrudnienia są niezbędne… do sterowania”; firma Thoughtworks ostrzega obecnie przed długiem kognitywnym wynikającym z pracy agentów w środowisku pozbawionym tarcia). Decyzje o utrzymaniu lub usunięciu, ustalanie priorytetów oraz poprawki obejmujące wielu właścicieli to kwestie negocjacyjne, a nie obliczeniowe. Wymagają one udziału wszystkich właścicieli poprawek w jednej rozmowie. (Rozdział: Raport istnieje. Pomieszczenie nie.)

O czym opowiada ta historia

Lista rytmów Garga dotycząca koła zamachowego zawiera zdanie, które brzmi niemal jak wyzwanie: „punkt porządku obrad w ramach istniejącej retrospektywy sprintu: co sprawdziło się w zakresie sztucznej inteligencji w tym sprincie?” (martinfowler.com). To właśnie ten wątek rozwijany jest w niniejszym przewodniku. Nie jest to nowa ceremonia ani proces prowadzony przez sztuczną inteligencję: chodzi o pętlę doskonalenia, której Państwa zespół już ufa, rozszerzoną tak, by objąć najnowszego członka zespołu, przy czym agent pełni rolę uczestnika: dostarcza dowodów, opracowuje propozycje poprawek, odpowiada na pytania; zespół zachowuje prawo do oceny, ponieważ poprawki mają wpływ na procesy, dokumenty i budżety, za które ludzie są odpowiedzialni i przed którymi odpowiadają.

A na początek szczera uwaga: jeśli Państwa zespół po prostu dodaje punkt do porządku obrad i omawia go (bez protokołu, bez oznaczeń), to już jest to lepsze niż milczenie, a w przypadku niewielkiego wykorzystania narzędzia może to wystarczyć. Dalsza część niniejszego przewodnika dotyczy tego, co należy dodać, gdy taka rozmowa zaczyna się powtarzać.

Rozdziały

1. Ta strona: dlaczego praca wspomagana sztuczną inteligencją wymaga zastosowania cyklu, który Państwa zespół już stosuje.
2. Mapa: pętle sprzężenia zwrotnego agentów, narzędzia i podejścia: ramy odniesienia obejmujące cykl życia tarcia, pętle o określonych nazwach wypracowane w tej dziedzinie oraz stosowane schematy klasyfikacji. Proszę zacząć od tego miejsca, jeśli kierują się Państwo podejściem odgórnym.
3. Jak wygląda dobry zapis zdarzeń związanych z tarciem: uchwycenie sytuacji w danej chwili, oznaczenia przyczyn źródłowych, zasady dotyczące zdarzeń, których nie należy rejestrować.
4. Gdzie powinna znaleźć się poprawka? Problem z wysokością oraz tabela routingu.
5. Raport istnieje. Pomieszczenie nie. Dlaczego synteza jest ceremonią zespołową, której cena wyróżnia się na tle konkurencji.
6. Przeprowadzenie sesji „AI collaboration retro”: przewodnik dla moderatora zawierający 15-minutowy punkt porządku obrad, szablon oraz karty z podpowiedziami.
7. Rozpocznij w dziesięć minut: ai-session-retro oraz ai-retro-brief, czyli elementy pętli odpowiedzialne za przechwytywanie i syntezę, gotowe do instalacji.

Wolą Państwo skróconą wersję? Na blogu znajdują się dwa powiązane wpisy: przewodnik „Szybki start”, zbieranie opinii od agentów AI, oraz relacja z naszego pierwszego samodzielnego wdrożenia tego rozwiązania, nasi koledzy z zespołu AI dołączyli do naszego podsumowania.

Najczęściej zadawane pytania

Czy agenci AI potrzebują własnej, odrębnej retrospektywy?

Nie. Podejście przedstawione w niniejszym przewodniku stanowi rozszerzenie pętli doskonalenia, którą Państwa zespół już stosuje – zazwyczaj jako pojedynczy punkt porządku obrad podczas istniejących retrospektyw – a nie wprowadza nowej procedury. Uczestnik wnosi dowody i proponuje rozwiązania; decyzja należy do zespołu.

Dlaczego problemy związane z działaniem agentów opartych na sztucznej inteligencji nie pojawiają się podczas zwykłych retrospektyw?

Są dwa powody. Agenci nie narzekają: napotykają przeszkodę, znajdują sposób na jej obejście i idą dalej, więc nikt nie przenosi tego problemu do kolejnej sesji. Poza tym ślady znikają: gdy sesja się kończy, kontekst, w którym pojawiły się tarcia, zanika wraz z nią, więc podczas kolejnej sesji znów napotykają tę samą przeszkodę od nowa.

Już teraz rejestrujemy ślady naszych agentów. Czy to nie wystarczy?

Samo obserwowanie nie prowadzi do poprawy. Około 90% zespołów wdraża narzędzia do śledzenia działania agentów, ale jedynie około 37–52% z nich systematycznie analizuje zebrane dane. Dane te stanowią surowiec; proces ten wymaga dyscypliny w gromadzeniu danych, ich syntezy oraz forum na poziomie zespołu, na którym osoby odpowiedzialne za wprowadzanie poprawek wspólnie podejmują decyzje.

Czy sztuczna inteligencja powinna samodzielnie przeprowadzić retrospektywę?

Nie. Agent pełni rolę uczestnika: dostarcza dowody, opracowuje propozycje zmian i odpowiada na pytania. To zespół podejmuje ostateczną decyzję, ponieważ wprowadzone zmiany mają wpływ na procesy, dokumenty i budżety, za które odpowiadają konkretne osoby i przed którymi ponoszą odpowiedzialność.

Jaka jest minimalna wersja tej praktyki zapewniająca jej funkcjonowanie?

Proszę dodać jeden punkt do porządku obrad istniejącej retrospektywy (co sprawdziło się w przypadku sztucznej inteligencji w tym cyklu?) i omówić tę kwestię. Bez protokołu, bez etykiet. To już lepsze niż milczenie, a w przypadku niewielkiego wykorzystania agentów może to wystarczyć. Pozostała część przewodnika dotyczy tego, co należy dodać, gdy ta rozmowa zaczyna się powtarzać.

Wolimy, by się z nami spierano, niż by się z nami grzecznie zgadzano. Każdy rozdział kończy się opisem tego, co mogłoby zmienić nasze zdanie.