Raport istnieje. Pomieszczenie nie.

Niedawno agent oparty na sztucznej inteligencji opublikował sześć wpisów na naszej własnej tablicy retro.

Pierwsza z nich brzmiała: „Zacznij od weryfikacji przed podjęciem działania — błędy wykonania agentów stanowią 38% przeszkód (dwukrotnie więcej niż kolejna przyczyna); powtarzającym się kosztem jest ustalanie przyczyny, wysyłanie zmian lub zmiana celu przed sprawdzeniem działającego kodu, danych lub stanu gałęzi”. Za tym kryły się dowody potwierdzające ten wzorzec: błędy związane ze stanem gałęzi w systemie Git podczas pracy agentów równoległych w ośmiu sesjach i dwóch repozytoriach; częściowe kontrole przed wysłaniem, które zakłóciły działanie CI w czterech sesjach, w tym dwukrotnie w jednym repozytorium tego samego dnia; luka w testach mockujących, którą jedna z sesji zidentyfikowała dzień wcześniej, wraz z adnotacją, że dokumentacja dotycząca poprawki nigdy nie została sporządzona.

Warto zwrócić uwagę na dwie kwestie dotyczące tej tablicy. Po pierwsze, żadna z sesji roboczych nie uznałaby żadnej z tych spraw za najważniejszy problem: każdy przypadek był jedynie wzruszeniem ramion, kilkoma straconymi minutami, irytacją, z którą ktoś sobie radził. Ranking ten istnieje wyłącznie w ujęciu zbiorczym, obejmującym wszystkie sesje i osoby. Po drugie, co jest jeszcze bardziej niekomfortowe: najbardziej obciążające pozycje w ogóle nie dotyczyły agenta ani kodu. Dotyczyły one nas: poprawek, na które zgodziliśmy się, ale których nie wdrożyliśmy, oraz powtarzającego się impasu, w którym „nie wprowadzono żadnego stałego rozwiązania między nimi”.

Wszystkie te informacje można uzyskać dzięki automatycznemu raportowi. Nie jest on jednak w stanie skłonić osób odpowiedzialnych za proces, dokumentację, budżet na narzędzia oraz ustalanie priorytetów do wspólnego podjęcia decyzji, jakie działania należy podjąć w tej sprawie. Raport istnieje. Nie ma jednak miejsca, w którym mogliby się Państwo spotkać. Niniejszy artykuł dotyczy właśnie tego miejsca.

Wszyscy zbudowali pętlę

Do połowy 2026 r. „identyfikowanie błędów w pracy wspomaganej przez sztuczną inteligencję i przekazywanie informacji zwrotnej na ten temat” stanie się powszechną praktyką. Istnieje ona pod co najmniej sześcioma nazwami, a wszystkie z nich są trafne. Model Feedback Flywheel autorstwa Rahula Garga wykorzystuje trudności napotkane podczas sesji do tworzenia dokumentacji wprowadzającej i wytycznych. Metoda Compound Engineering firmy Every sprawia, że każda jednostka pracy stanowi naukę dla kolejnej. Thoughtworks wyposaża agentów w czujniki; Addy Osmani nazywa tę dyscyplinę Loop Engineering. Dostawcy platform zamykają pętlę na skalę floty: funkcja „dreaming” pamięci OpenAI, kuracja kontekstu Anthropic oraz Factory Signals automatycznie rejestrujące zgłoszenia. Otwarte oprogramowanie GitHub gh-aw, będące frameworkiem dla agentowych przepływów pracy napisanym w języku naturalnym Markdown, najdalej wykracza w kierunku naszego tematu: jego przepływy pracy oparte na wglądzie w sesje już teraz generują zautomatyzowane raporty z analizy sesji. Jeden z publicznie dostępnych przykładów, czyli zautomatyzowana analiza 50 sesji z jednego dnia, wskazuje 24-procentowy wskaźnik pominięć oraz 33-procentowy wskaźnik powodzenia wykonawców jako „sygnały niepowodzenia”.

Jeśli korzystają Państwo z którejkolwiek z tych metod: proszę nadal z nich korzystać. W niniejszym artykule nie proponuje się zastąpienia żadnej z nich. Proszę jednak posortować pętle według poziomu, na którym są wykonywane, i zwrócić uwagę na następujący schemat:

Jeden podręcznik dla specjalisty. Jedna konfiguracja sesji. Jedna pamięć platformy. Jeden stos rozwiązań do monitorowania. Jedna flota dostawcy.

Prawie każda pętla w tej dziedzinie stanowi cykl indywidualny: osoba i jej agent lub dostawca i jego flota. Model „koła zamachowego” Garga jest jedynym rozwiązaniem, które opiera się na wspólnych artefaktach zespołowych, a jego lista rytmów zawiera punkt, którego prawie nikt nie wdrożył w praktyce: „Podczas retrospektywy: punkt porządku obrad w ramach bieżącej retrospektywy sprintu: co sprawdziło się w zakresie sztucznej inteligencji w tym sprincie?” Wskazuje miejsce i przechodzi dalej. Tymczasem praktyka „dogfoodingu” stosowana w serwisie GitHub generuje dokładnie taki raport dotyczący tarć, jaki ceremonia zespołowa chciałaby otrzymać jako dane wejściowe, i traktuje go wyłącznie jako obserwowalność inżynieryjną – kropka.

Najbliższym przykładem wyjątku jest serwis Scrum.org, którego seria poświęcona zespołom hybrydowym zawiera artykuł Jak przeprowadzić retrospektywę sprintu, gdy połowa zespołu to agenci AI. Warto się z tym zapoznać, ponieważ autorzy poważnie podchodzą do kwestii miejsca przeprowadzenia retrospektywy i odpowiadają na nią inaczej niż my: ich retrospektywa staje się opartą na danych sesją debugowania wskaźników agentów (częstotliwość przepisywania podpowiedzi, wskaźniki odchyleń, zużycie tokenów). Jest to przydatne podejście, a zespół mógłby stosować oba rozwiązania. Jednak tamta retrospektywa dotyczy agentów; pętla, o której mowa w niniejszym artykule, dotyczy współpracy: przyczyn, a nie symptomów, z rozwiązaniami kierowanymi na odpowiedni poziom (brief, dokumentacja, proces, materiały), przy czym agenci przedstawiają własną relację z pracy, a nie pojawiają się jedynie jako element pulpitu nawigacyjnego.

Problem nie leży w technologii. Wszystkie elementy (gromadzenie danych, agregacja, raportowanie) są już dostępne. Problem dotyczy praktyki: prawie nikt nie wyjaśnił, co zespół robi wspólnie po otrzymaniu raportu.

Co tak naprawdę wymaga osobnego pomieszczenia

W tej sytuacji naturalnym odruchem jest dążenie do większej automatyzacji: lepsze grupowanie, automatyczne wprowadzanie poprawek, pulpit nawigacyjny. W przypadku znacznej części zidentyfikowanych problemów jest to słuszne podejście, a opisane powyżej procesy radzą sobie z tym dobrze. Proszę jednak wymienić decyzje, które faktycznie wynikają z raportu, i zwrócić uwagę na ich charakter:

• Zachować czy wyeliminować. Które z powtarzających się utrudnień stanowią marnotrawstwo, a które są celową formą kontroli? Etap weryfikacji, który spowalnia działanie agenta, może być swego rodzaju smyczą, którą ktoś celowo wybrał (podsumowanie wystąpienia Armina Ronachera podczas konferencji AIE Europe: „utrudnienia są tym, co jest niezbędne… do sterowania”); Narzędzie Radar firmy Thoughtworks ostrzega obecnie przed długiem poznawczym wynikającym z usunięcia zbyt wielu elementów. Usunięcie punktu kontrolnego zmienia poziom ryzyka dla wszystkich. Z definicji jest to decyzja zespołowa.
• Gdzie pojawia się rozwiązanie. Powtarzający się problem zostaje rozwiązany na pewnym poziomie: może to być osobista uwaga, wskazówka lub umiejętność, konfiguracja środowiska, dokumentacja, sam materiał roboczy, proces lub kwestia związana z dostawcą. Te elementy mają swoich właścicieli, a właściciele ci to różne osoby.
• Priorytet w kontekście agregacji. Pięć minut, które każda osoba poświęca na tę czynność podczas każdej sesji, jest dla niej niezauważalne, a w ujęciu zbiorczym stanowi znaczny koszt dla zespołu. Podjęcie odpowiednich działań (przeredagowanie wspólnego szablonu, zmiana procesu przyjmowania zgłoszeń, eskalacja sprawy do dostawcy) wymaga poziomu decyzji, którego żadna osoba z osobna nie jest w stanie podjąć.
• Kontrola wdrożenia. Czy poprawka z ostatniego cyklu została faktycznie wdrożona i czy ustały trudności? Najcenniejszym stwierdzeniem naszego zarządu było właśnie to: zgłoszono wczoraj, nigdy nie wdrożono. Pętla bez tej kontroli jest jak koło zamachowe wirujące w powietrzu.

Żadna z tych czynności nie stanowi obliczenia. Wszystkie one stanowią negocjacje między osobami odpowiedzialnymi za różne elementy funkcjonowania zespołu. Osoby pracujące samodzielnie w uzasadniony sposób uwzględniają te decyzje intuicyjnie; procesy w ramach floty w uzasadniony sposób tworzą podzbiór zrozumiały dla maszyn z prędkością maszynową. Wersje na skalę zespołu wymagają obecności osób w jednym pomieszczeniu, posługujących się wspólnym słownictwem i posiadających uprawnienia do realokacji uwagi. To nie jest potok. To ceremonia.

Dlaczego styl retro, czy też ceremonia o podobnym charakterze?

Zanim przejdziemy do argumentacji, pragnę zaznaczyć: zajmujemy się sprzedażą oprogramowania retrospektywnego. Właśnie dlatego w niniejszej sekcji opieramy się na właściwościach, a nie na marce: prosimy o odpowiednie zweryfikowanie naszego wniosku i samodzielne sprawdzenie tych właściwości.

Cechy, jakie powinien posiadać zbiór decyzji: miejsce spotkań, które ma charakter cykliczny (długotrwałe drobne tarcia nigdy nie powodują zwołania doraźnego spotkania), w którym zgodnie z normą nie obwinia się nikogo, międzyfunkcyjne (obecni są przedstawiciele odpowiedzialni za procesy, dokumentację, narzędzia i priorytety) oraz oparte na dowodach. Dla większości zespołów retrospektywa sprintu jest miejscem, w którym te cztery cechy są już obecne: nie wymaga to organizowania nowego spotkania, o które trzeba by walczyć w „wojnie kalendarzowej”, a konwencja „bez obwiniania” ma większe znaczenie, niż mogłoby się wydawać, ponieważ kuszącym scenariuszem niepowodzenia jest tutaj analiza po fakcie polegająca na obwinianiu podmiotu, a szkoła inżynierii harnessu wyraźnie odrzuca to domyślne podejście: inżynier obwinia model i odłoży sprawę do kategorii „poczekaj na następną wersję”; zamiast tego należy naprawić harness (Osmani, Agent Harness Engineering).

Jednak uczciwa forma tego twierdzenia polega raczej na wycenie konkurentów niż na wyłonieniu zwycięzcy:

• Planowanie sprintu ma największy autorytet w zebraniu, jednak jego porządek obrad jest ukierunkowany na przyszłość i nieustannie przepełniony; czas na retrospektywę w ramach sesji planowania jest niezmiennie ograniczony. Planowanie to etap, na którym zatwierdzone działania są wpisywane do harmonogramu, a nie etap, na którym analizuje się wzorce.
• „Bezbłędna analiza po fakcie” opiera się na właściwych standardach, ale ma niewłaściwy punkt wyjścia: zwoływana jest w przypadku poważnych, sporadycznych niepowodzeń, a nigdy w przypadku powtarzającego się schematu „pięć minut na osiem osób w każdym sprincie” – a właśnie ten schemat można dostrzec wyłącznie dzięki agregacji danych.
• Asynchroniczny (raport wraz z narzędziem do śledzenia postępów) stanowi najtańsze rozwiązanie i w przypadku większości rutynowych zadań jest wystarczające. Nie pozwala ono jednak na podejmowanie decyzji: kwestia „zachować czy usunąć” wymaga negocjacji, spory dotyczące priorytetów wykraczają poza granice odpowiedzialności poszczególnych właścicieli, a zmiana priorytetów wymaga udziału właścicieli w tej samej rozmowie.
• Alternatywa zerowa (po prostu rozmowa o sztucznej inteligencji w stylu retro, bez zapisów, bez etykiet) jest bezpłatna, sprawdza się w dzisiejszych realiach i dla niewielkiego zespołu, który w ograniczonym stopniu korzysta z agentów, może rzeczywiście okazać się wystarczająca. Proszę zacząć od tego. Nie zapewnia ona jednak porównywalności między sesjami, trendów ani weryfikacji stopnia przyjęcia: rozmowa za każdym razem zaczyna się od zera. Poniższa praktyka jest tym, co należy dodać, gdy ta rozmowa ciągle się powtarza.

A zatem, ujmując to szczerze: ceremonia w stylu retro lub Państwa dotychczasowa ceremonia o podobnym charakterze. Miesięczny przegląd kampanii przeprowadzany przez zespół ds. mediów oraz przegląd priorytetów przeprowadzany przez zespół wsparcia to ta sama procedura pod różnymi nazwami, a nic w tej praktyce nie zakłada stosowania kodu: dziennik problemów dotyczących splątanego konta reklamowego lub niespójnej biblioteki szablonów wygląda dokładnie tak samo jak dziennik problemów dotyczący starszego repozytorium.

Osoba obecna w pomieszczeniu: uczestnik, a nie moderator

Jeśli dowód pochodzi od agentów, czy to agent powinien zająć się tą sprawą? Nie, i to nie przede wszystkim z powodu, który Pan/Pani by przypuszczał(-a).

Powód, dla którego to się zmienia: dzisiejsze modele są niewiarygodne właśnie w tego rodzaju ocenach: wyniki generowane przez duże modele językowe (LLM) zmieniają się przy identycznych danych wejściowych ~13,6% przypadków, a w jednym z ośmiotygodniowych badań produkcyjnych ~70% cichych awarii agentów zostało najpierw wykrytych przez osobę, a nie przez testy czy monitoring. Obecnie jest to prawda; modele ulegają jednak udoskonaleniu.

Powodem, dla którego sytuacja ta nie ulega zmianie, jest fakt, że facylitacja i podejmowanie decyzji kierują uwagę zespołu oraz wprowadzają zmiany w artefaktach, za które zespół ponosi odpowiedzialność. Uprawnienia te nie przechodzą na najbardziej kompetentną osobę w pomieszczeniu, tak samo jak nie przechodzą na najbardziej kompetentnego inżyniera w pomieszczeniu. Jest to fakt organizacyjny, a nie luka w kompetencjach.

W ten sposób agent działa tak samo, jak najlepiej poinformowany uczestnik. Przedstawia dowody: swoje zapisy sesji, opatrzone etykietami i informacjami o kosztach. Odpowiada na pytania: na pytanie „Co faktycznie pan/pani próbował(a) przed zastosowaniem rozwiązania tymczasowego?” udziela odpowiedzi popartej transkrypcją. Opracowuje propozycje, ale nigdy nie podejmuje decyzji: proponowane poprawki są przedstawiane wraz z sugerowanymi poziomami priorytetu; zespół wprowadza do nich poprawki, zmienia priorytety lub je odrzuca. Ponadto przywraca zatwierdzone działania (edycję dokumentu, zmianę konfiguracji), realizując je po zakończeniu procedury w ramach zwykłego przeglądu. W praktyce badawczej istnieje nazwa dla tego podziału: w ramach modelu ACE agent pełni rolę Reflektora, a Kurator konsoliduje treści wprowadzane do podręcznika postępowania. Wprowadzamy jedno celowe dostosowanie: w modelu ACE kurator jest elementem deterministycznym; tutaj kuratorami jest zespół.

Jedna z asymetrii dotyczy obciążenia. Wszystko, co agent wprowadza do pomieszczenia, powinno być wolne od ograniczeń, ponieważ agent, który potrzebuje uprawnień do zgłaszania oporów, zgłasza zbyt mało przypadków. Wszystko, co opuszcza pomieszczenie i trafia do elementów, na których agenci później polegają (pamięć, pliki kontekstowe, konfiguracja), podlega standardowej weryfikacji, ponieważ ta ścieżka zapisu stanowi uznaną powierzchnię podatną na zatruwanie i dryft (OWASP Agentic Top 10, ASI06). Procedura ta przebiega dokładnie na tej granicy: dane wejściowe bez kontroli, zapisy wyjściowe podlegające kontroli.

Piętnaście minut

Oto, co faktycznie proponujemy, aby zespół wypróbował w tym sprintie, przy czym każda pętla działa już bez zmian:

1. Po zakończeniu każdej sesji agent sporządza krótką retrospektywę podsumowującą własną pracę: co poszło dobrze, poszczególne problemy wraz z określeniem ich przyczyny źródłowej i związanymi z nimi kosztami, proponowane rozwiązanie w formie zgłoszenia oraz poziom, na który ma ono oddziaływać. Wpis ten jest zatwierdzany wraz z samą pracą, bez żadnych ograniczeń.
2. Przed spotkaniem podsumowującym wpisy opublikowane od ostatniego spotkania są syntetyzowane w formie jednostronicowego podsumowania: powtarzające się tematy wraz z ich częstością występowania, która grupa przyczyn źródłowych dominuje, czy wdrożono wcześniejsze rozwiązania oraz trzy najważniejsze zalecane działania. Podsumowanie to stanowi punkt wyjścia do dyskusji; nie zastępuje jej jednak.
3. W ramach podsumowania (punkt porządku obrad, a nie nowe spotkanie): piętnaście minut poświęconych na omówienie tematu „Co sprawdziło się w zakresie sztucznej inteligencji w tym cyklu, a co nadal stanowiło problem?”. Uczestnicy dokonują selekcji: zatrzymać czy odrzucić, potwierdzić czy przekierować priorytety, wyznaczyć osoby odpowiedzialne za trzy najważniejsze kwestie.
4. W kolejnym cyklu kontrola przyjęcia wytycznych sprawdza, czy tarcie faktycznie spadło. To właśnie ta kontrola sprawia, że raport staje się pętlą. I właśnie w tym miejscu nasza rada nas przyłapała.

Rodzaje niepowodzeń, których nazwy pozwalają się przed nimi zabezpieczyć: teatr retro (ceremonia organizowana dla publiczności: krótkie odczytanie, kiwanie głowami, brak podjętych decyzji; właśnie w tym celu istnieje zasada „trzech najważniejszych kwestii wraz z właścicielami”); obwinianie agenta (traktowanie stwierdzenia „agent popełnił błąd” jako wyjaśnienia, a nie jako skutku ubocznego; większość niepowodzeń wynika z układu testowego i danych wejściowych, a nie z rozumowania modelu); rozrost listy życzeń (dwadzieścia działań, brak osób odpowiedzialnych); oraz pętla, która nigdy się nie zamyka (brak kontynuacji działań: wprowadzono poprawki, ale nikt nie sprawdza trendu). Opracowaliśmy obszerny przewodnik praktyczny dotyczący przyczyn niepowodzeń ceremonii; wszystkie opisane w nim tryby mają również zastosowanie w tym przypadku.

Czego nie twierdzimy

Nie zastępuje to żadnego cyklu dostawcy: wyniki tych cykli stanowią dane wejściowe dla tej ceremonii. Nie jest to nowe spotkanie. Nie jest to ceremonia prowadzona przez sztuczną inteligencję; w przypadku firmy, której produktem są retrospektywy, te ograniczenia są celowe. Nie jest to konieczne dla osób pracujących samodzielnie, których cykle zamykają się prawidłowo na podstawie wyczucia. Nie jest to również dążenie do całkowitego braku tarcia: pewien stopień tarcia stanowi element sterujący, a ten punkt porządku obrad istnieje po to, by dokonywać wyboru, a nie eliminować go od razu.

Co mogłoby nas przekonać?

Niniejszy dokument ma charakter dyskusyjny, a oto jego część podlegająca weryfikacji. Jeśli pętle dostawców będą sprzyjać prawdziwej, niezależnej od narzędzi i osób ocenie, a nie tylko zapisywaniu danych w pamięci całej floty, ich rola ograniczy się do funkcji audytowej. Jeśli zespoły korzystające z wersji asynchronicznej opartej wyłącznie na briefie wykażą taką samą tendencję do zmniejszenia oporu jak zespoły realizujące punkt porządku obrad, te piętnaście minut okaże się tylko pozorem i otwarcie to stwierdzimy. Natomiast nasze twierdzenie dotyczące oznaczonego słownictwa opiera się na eksperymencie dotyczącym zgodności między oceniającymi, który obecnie przeprowadzamy na rzeczywistych wpisach, a nie na z góry sformułowanych założeniach. Wolimy opublikować dane liczbowe niż poziom pewności.

Jeśli Państwa zespół realizuje którąkolwiek z tych inicjatyw (punkt porządku obrad, briefing dotyczący zadań asynchronicznych lub jakąkolwiek ceremonię, o której jeszcze nie pomyśleliśmy), chcielibyśmy dowiedzieć się, jak to przebiegło: ai-discussion@teamretro.com.

---

Następny rozdział: Przeprowadzenie retrospektywy współpracy z AI. Przewodnik dla moderatora dotyczący piętnastominutowej sesji: szablon, format wpisów oraz karty z podpowiedziami. Część przewodnika po retrospektywach z udziałem agentów AI.