Raport istnieje. Pomieszczenie nie istnieje.

Niedawno agent oparty na sztucznej inteligencji dodał sześć pozycji 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, wdrażanie zmian lub zmiana celu przed sprawdzeniem działającego kodu, danych lub stanu gałęzi”. Za tym stwierdzeniem kryły się dowody w postaci wzorca: 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 przesłaniem, które spowodowały awarię ciągłego integracji (CI) w czterech sesjach, w tym dwukrotnie w jednym repozytorium tego samego dnia; luka w testach mockingowych, którą jedna z sesji zasygnalizował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 związane z tą tablicą. Po pierwsze, żadna z poszczególnych sesji roboczych nie uznałaby żadnej z tych spraw za najważniejszy problem: każdy taki przypadek był jedynie wzruszeniem ramion, kilkoma straconymi minutami, irytacją, z którą ktoś sobie jakoś radził. Ranking ten istnieje wyłącznie w ujęciu zbiorczym, obejmującym wszystkie sesje i osoby. Po drugie, co jest jeszcze bardziej niepokojące: najbardziej krytyczne 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 wyniku którego „między nimi nie wprowadzono żadnego stałego rozwiązania”.

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 przedyskutowania i 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 stworzyli tę 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ę w skali całej floty: funkcja „dreaming” pamięci OpenAI, kuracja kontekstu firmy Anthropic oraz Factory Signals automatycznie generujące zgłoszenia. Otwarte oprogramowanie GitHub gh-aw, będące frameworkiem dla agentowych przepływów pracy napisanym w języku naturalnym w formacie Markdown, najdalej wykracza w kierunku naszego tematu: jego przepływy pracy oparte na spostrzeżeniach z sesji już 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 skuteczności 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 zapoznać się z poniższym schematem:

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 elementów rytmu pracy zawiera pozycję, której prawie nikt nie wdrożył w praktyce: „Podczas retrospektywy: punkt porządku obrad w ramach istniejącej retrospektywy sprintu: co sprawdziło się w zakresie sztucznej inteligencji w tym sprincie?” Wskazuje miejsce i przechodzi dalej. Tymczasem praktyka „dogfoodingu” stosowana przez 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 składa się z agentów 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 wykrytych 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 zastosował (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 następuje rozwiązanie problemu. 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ścicielami tymi są różne osoby.
• Priorytet w kontekście agregacji. Pięć minut poświęconych na nieistotne sprawy na osobę podczas każdej sesji pozostaje niezauważalne dla poszczególnych osób, 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 decyzyjnego, którego żadna osoba z osobna nie posiada.
• Kontrola wdrożenia. Czy poprawka z poprzedniego cyklu została faktycznie wdrożona i czy problem ustał? Najcenniejszym stwierdzeniem naszego zarządu było właśnie to: zgłoszono wczoraj, nigdy nie zaimplementowano. Pętla bez tej kontroli jest jak koło zamachowe kręcące się 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 sposób uzasadniony uwzględniają te decyzje intuicyjnie; procesy w ramach floty w uzasadniony sposób tworzą podzbiór czytelny 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 — lub 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: proszę odpowiednio zweryfikować nasz wniosek i samodzielnie sprawdzić te właściwości.

Cechy, jakie powinien posiadać zestaw decyzyjny: 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ędzywłaścicielskie (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 pofaktoryjna polegająca na obwinianiu podmiotu, a szkoła inżynierii harnessów wyraźnie odrzuca to domyślne podejście: inżynier obwinia model i odkładają 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 nieuchronnie ograniczony. Planowanie to etap, na którym zatwierdzone działania są wpisywane do harmonogramu, a nie etap, na którym analizuje się wzorce.
• „Bezwadliwa analiza po fakcie” opiera się na właściwych normach, ale jej punktem wyjścia jest niewłaściwy czynnik: zwołuje się ją w przypadku poważnej, sporadycznej awarii, a nigdy w przypadku powtarzającego się co sprintu schematu „pięć minut – osiem osób”, który jest właśnie tym wzorcem, który można dostrzec wyłącznie dzięki agregacji danych.
• Asynchroniczny raport wraz z narzędziem do śledzenia to najtańsze rozwiązanie i w przypadku rutynowej większości zadań w zupełności 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 wszystkich właścicieli w tej samej rozmowie.
• Alternatywa zerowa — po prostu mówienie 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 wystarczyć. Zacznijcie od tego. Nie zapewnia to jednak porównywalności między sesjami, trendów ani weryfikacji stopnia wdrożenia: rozmowa za każdym razem zaczyna się od zera. Poniższa praktyka jest tym, co należy wprowadzić, gdy ta rozmowa nieustannie 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 zagmatwanego 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 ta sytuacja ulega pogorszeniu: 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 człowieka, a nie przez testy czy monitorowanie. 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 wpływają na artefakty, 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 uczestniczy w procesie 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; uczestnicy spotkania wprowadzają do nich poprawki, zmieniają priorytety lub odrzucają je. Ponadto przejmuje zatwierdzone działania (edycję dokumentu, zmianę konfiguracji), realizując je po zakończeniu ceremonii w ramach standardowej weryfikacji. 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. 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ć pozbawione ograniczeń — agent, który potrzebuje uprawnień do zgłaszania problemów, zgłasza zbyt mało. Wszystko, co opuszcza pomieszczenie i trafia do zasobó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, dane 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 przyczyny źródłowej i związanymi z nimi kosztami, proponowane rozwiązanie w formie zgłoszenia oraz poziom, na którym ma ono zostać wdrożone. Wpis jest zatwierdzany wraz z samą pracą, bez żadnych ograniczeń.
2. Przed spotkaniem podsumowującym wpisy opublikowane od ostatniego spotkania są zestawiane 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 na omówienie tematu „Co sprawdziło się w zakresie sztucznej inteligencji w bieżącym cyklu, a co nadal stanowiło problem?”. Uczestnicy dokonują selekcji: zachować czy odrzucić, potwierdzić czy przekierować priorytety, wyznaczyć osoby odpowiedzialne za trzy najważniejsze kwestie.
4. W kolejnym cyklu kontrola wdrożenia zawarta w briefie wskazuje, czy poziom oporu rzeczywiście się zmniejszył. To właśnie ta kontrola sprawia, że raport staje się pętlą — i właśnie w tym miejscu nasza rada nadzorcza nas przyłapała.

Tryby awarii, nazwane tak, aby można było 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 wraz z właścicielami”); obwinianie agenta (traktowanie stwierdzenia „agent popełnił błąd” jako wyjaśnienia, a nie jako zjawiska resztkowego; 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, nikt nie sprawdza trendu). Opracowaliśmy kompletny przewodnik praktyczny dotyczący przyczyn niepowodzeń ceremonii; każdy opisany w nim scenariusz ma również zastosowanie w tym przypadku.

Czego nie twierdzimy

Nie zastępuje to żadnego cyklu dostawcy: wyniki tych cykli stanowią dane wejściowe dla niniejszej ceremonii. Nie jest to nowe spotkanie. Nie jest to ceremonia prowadzona przez sztuczną inteligencję; w przypadku firmy, której produktem są retrospektywy, takie ograniczenie jest zamierzone. 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 poziom tarcia stanowi element kontroli, a ten punkt porządku obrad ma na celu dokonywanie wyboru, a nie natychmiastowe eliminowanie problemów.

Co mogłoby skłonić nas do zmiany zdania?

Niniejszy dokument ma charakter dyskusyjny, dlatego poniżej przedstawiono część podlegającą weryfikacji. Jeśli pętle dostawców doprowadzą do powstania prawdziwej, niezależnej od narzędzi i osób oceny, a nie będą jedynie zapisem danych w pamięci całej floty, zakres działania ograniczy się do funkcji audytowej. Jeśli zespoły stosujące wersję asynchroniczną opartą 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. 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ąś 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 wykorzystaniem sztucznej inteligencji — 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.