CLAUDE.md dla zespołów: jak przekształciliśmy wspomnienia pięciu osób oparte na sztucznej inteligencji we wspólne zasady

Każdy programista korzystający z agenta do kodowania opartego na sztucznej inteligencji po cichu tworzy zbiór zasad. Funkcja automatycznej pamięci Claude Code zapisuje notatki dotyczące Państwa poprawek w trakcie pracy, Państwa osobisty profil ~/.claude/CLAUDE.mdgromadzi preferencje, których powtarzanie stało się dla Państwa uciążliwe, a kilka osobistych umiejętności rozwija się w oparciu o zadania, które wykonują Państwo co tydzień. Wszystko to ma charakter prywatny. Pamięć automatyczna jest przypisana do danej maszyny i poszczególnych repozytoriów: agenci Państwa współpracowników nigdy nie mają do niej dostępu.

W ten sposób pięć osób przyswaja tę samą lekcję osobno, każda w swoim prywatnym pliku. Zasady, których Państwa zespół najbardziej potrzebuje, są już spisane. Po prostu nie znajdują się one w żadnym wspólnym dokumencie.

We wrześniu w pięcioosobowym gronie przeprowadziliśmy „zbiórkę wspomnień”: zebraliśmy te prywatne zapisy i zastanawialiśmy się, które z nich zasługują na to, by stać się zasadami zespołowymi. Oto, jak to zrobiliśmy, które zasady zostały wybrane, gdzie każda z nich znalazła swoje miejsce oraz jakie wnioski wyciągnęliśmy – w tym również te dotyczące zasad, co do których popełniliśmy błąd.

Czym jest „żniwo wspomnień”

„Zbieranie wspomnień” to ćwiczenie zespołowe składające się z trzech etapów. Każda osoba eksportuje swoje prywatne wspomnienia dotyczące agentów oraz osobiste zasady. Jedna osoba sprawdzająca grupuje wpisy pochodzące z eksportów wszystkich uczestników. Zasady, które kilka osób zapisało niezależnie od siebie, są proponowane do wykorzystania we wspólnych plikach: w projekcieCLAUDE.md, AGENTS.mdwe wspólnej umiejętności lub podczas zatwierdzania w CI.

Jest to etap konserwacji, który w inżynierii kontekstowej zazwyczaj pomija się. Już wcześniej argumentowaliśmy, że pliki kontekstowe wymagają pętli sprzężenia zwrotnego napędzanej przez agentów, którzy z nich korzystają. „Zbiór” stanowi tę samą pętlę, realizowaną w odniesieniu do osób zamiast sesji: jest to etap 4 cyklu życia sprzężenia zwrotnego agenta, ukierunkowany na notatki, które utknęły już w pamięci prywatnej.

Narzędzia służące do tego celu są ograniczone. Spośród dziesięciu narzędzi do kodowania sztucznej inteligencji, które przeanalizowaliśmy, jedynie Devin oferuje pętlę, która monitoruje sesję, proponuje wspólną regułę i oczekuje na zatwierdzenie przez użytkownika. Pozostałe opierają się na plikach tworzonych i zatwierdzanych ręcznie przez użytkowników lub na zestawach instrukcji przekazywanych przez administratora. Żadne z nich nie analizuje prywatnych wspomnień wielu osób w celu znalezienia potencjalnych zasad zespołowych.

Co zrobiliśmy

W dniu 17 września 2026 r. pięciu programistów uruchomiło skrypt eksportujący, przetwarzając nim swoje własne pamięci Claude Code, osobiste zmienne globalne orazCLAUDE.md osobiste umiejętności. Skrypt nie przesyła żadnych danych. Każda z tych osób przejrzała swój własny pakiet danych, usunęła z niego wszystko, co nie powinno zostać przesłane, a dopiero potem go przesłała.

Pięć pakietów zawierało 444 wpisy pamięci, 5 CLAUDE.mdplików globalnych, 13 umiejętności osobistych oraz 194 wiersze opisujące umiejętności zainstalowane w każdym repozytorium. Jeden z recenzentów – agent sztucznej inteligencji współpracujący z człowiekiem – pogrupował wpisy we wszystkich pięciu pakietach i sporządził propozycję dla każdej grupy. 22 września czworo z nas zagłosowało na dwóch stronach recenzji. Zmiany zostały wprowadzone w formie zwykłych pull requestów w trzech repozytoriach: naszym głównym repozytorium produktu, repozytorium gier oraz naszym wspólnym repozytorium wtyczek umiejętności.

Pakiety znajdują się na gałęzi, która nigdy nie jest scalana. Wyjść mogą jedynie promocje – każda z nich jako oddzielny PR dotyczący repozytorium, którym zarządza, i podlegająca weryfikacji tak jak każda inna zmiana.

Co decyduje o awansie: należy brać pod uwagę liczbę autorów, a nie liczbę zgłoszeń

Zasada zostaje zatwierdzona, gdy co najmniej dwie osoby zapisały ją niezależnie od siebie. Należy liczyć poszczególnych autorów, a nie same wpisy. Ta jedna zasada wykonała większość pracy, a zanim można było jej zaufać, wymagała trzech udoskonaleń.

Proszę wziąć pod uwagę użytkownika intensywnie korzystającego z serwisu. Jeden pakiet zawierał 251 z 444 wpisów, rozmieszczonych w 10 repozytoriach. Wszyscy pozostali wnieśli od 37 do 68 wpisów w 1–4 repozytoriach. Zatem określenie „dwóch autorów” zazwyczaj oznaczało „naszego użytkownika o największej aktywności oraz jeszcze jedną osobę”, a klaster bez tego użytkownika o największej aktywności stanowił rzadszy i mocniejszy dowód. Klastry te oznaczyliśmy oddzielnie.

Jedna osoba to jeden autor. Jeden programista, którego dane zostały wyeksportowane z dwóch komputerów. To jeden autor. Jedna osoba powtarzająca tę samą zasadę trzykrotnie – to podkreślenie. Potwierdzenie wymaga obecności drugiej osoby.

Wspólne źródła nie są niezależne. CLAUDE.mdPliki globalne obu osób były identyczne na poziomie bajtów w pierwszych czterech sekcjach, ponieważ obie osoby wykorzystały ten sam opublikowany tekst: wytyczne Andreja Karpathy’ego dotyczące kodowania agentów sztucznej inteligencji. Obie osoby powoływały się na ten sam dokument źródłowy, więc uznano to za jedno źródło. Każdy przyszły klaster oparty wyłącznie na tej parze zostanie najpierw porównany z brzmieniem dokumentu źródłowego.

W celu sklasyfikowania każdego klastra wykorzystaliśmy cztery operatory z ExpeL, metody badawczej dotyczącej agentów uczących się reguł na podstawie doświadczenia: DODAJ nową regułę, POPRZEJ tę, która już znajduje się we wspólnych dokumentach, ODRZUĆ tę, której zaprzeczają dowody, EDYTUJ tę, która jest zbliżona, ale błędna. Głosowanie przeciwko i edycja mają równie duże znaczenie jak dodawanie. Proces gromadzenia danych, który ogranicza się wyłącznie do dodawania reguł, powoduje jedynie wydłużenie plików kontekstowych, nie przyczyniając się do poprawy ich poprawności.

To próg decyduje o tym, co proponuje recenzent, a nie o tym, co zespół może przyjąć. Na drugiej stronie recenzji wymieniono informacje autorstwa pojedynczych autorów, które wydawały się warte opublikowania, a uczestnicy spotkania głosowali nad każdą z nich. Zostały one przyjęte, ponieważ ludzie je przeczytali i zgodzili się z nimi.

Gdzie powinna znajdować się każda reguła

Uzgodnienie zasady to połowa decyzji. Druga połowa dotyczy jej poziomu: poziomu, na którym będzie ona faktycznie odczytywana i stosowana. (W rozdziale naszego przewodnika poświęconym temu, na jakim poziomie powinna znajdować się poprawka, omówiono tę hierarchię w całości.) W przypadku zasad zebranych z innych źródeł korzystaliśmy z następującej tabeli routingu:

Zasada brzmi:	To należy do	Dlaczego
Niezmiennym faktem jest, że każda sesja w tym repozytorium wymaga	Projekt CLAUDE.md	Ładuje się na początku każdej sesji
To samo dotyczy każdego narzędzia opartego na sztucznej inteligencji, z którego korzysta zespół	AGENTS.md, sprowadzone z CLAUDE.md	Jeden plik, który może odczytać każde narzędzie
Dotyczy wyłącznie części kodu źródłowego	Reguła o zasięgu ścieżki w .claude/rules/	Pobiera dane wyłącznie wtedy, gdy agent wykryje pasujące pliki
Procedura stosowana w wielu repozytoriach	Umiejętność w wspólnej wtyczce	Wtyczki zawierają funkcje, a nie CLAUDE.md
Procedura dotycząca konkretnego repozytorium	Umiejętność repo	Ładuje się, gdy wymaga tego zadanie
Szczegóły odniesienia są zbyt długie, by uwzględniać je w każdej sesji	Dokumentacja oraz jednowierszowa wskazówka w CLAUDE.md	Dokument, który się nie ładuje, to dokument, którego agent nigdy nie przeczyta
Możliwe do sprawdzenia mechanicznie	Reguła Lint, test lub kontrola w ramach ciągłego wdrażania (CI)	Prose ostrzega; czek to powstrzymuje
Preferencje dotyczące Państwa własnych narzędzi, maszyn lub budżetu	Państwa osobiste CLAUDE.mdlub wspomnienie	Nie jest to fakt dotyczący kodu źródłowego

Należy zwrócić uwagę na dwie kwestie. Po pierwsze, wtyczka Claude Code może zawierać umiejętności, agenty i haki, ale nie proceduryCLAUDE.md. Procedury obejmują różne repozytoria w ramach jednej wtyczki; stałe reguły należy umieścić w każdym repozytorium, które ich wymaga.

Po drugie, pamięć prywatną należy usunąć dopiero po automatycznym załadowaniu dokumentu docelowego. Przeniesienie reguły do dokumentu, który nie jest ładowany, powoduje, że agent po prostu o niej zapomina. W przypadku umieszczenia reguły w dokumentach referencyjnych pamięć prywatna zmniejszała się do rozmiarów wskaźnika, zamiast całkowicie znikać.

Jak radzić sobie z sprzecznościami

Wspólne zapisy pamięci są ze sobą sprzeczne. W miarę możliwości należy rozwiązać sprzeczność poprzez określenie zakresu, zastąpić nieaktualną stronę, a rozbieżności dotyczące preferencji pozostawić w wyraźnie oznaczonej grupie spraw nierozstrzygniętych.

Proszę najpierw sprawdzić zakres. Jedna z rozbieżności dotyczyła sposobu konfigurowania zależności w drugiej kopii roboczej repozytorium: dwie osoby sformułowały sprzeczne zasady. Obie były prawdziwe w ich własnych repozytoriach. Późniejsza zmiana we wspólnej umiejętności rozstrzygnęła tę kwestię dla obu stron, a pamięć naszego najbardziej aktywnego użytkownika okazała się nieaktualna, dlatego to właśnie ta wersja powinna zostać zastąpiona, a nie po cichu usunięta.

Zastępuj, nigdy nie nadpisuj. Gdy zmienia się reguła wspólna, proszę dodać nową regułę wraz z datą i pozostawić starą w postaci czytelnej – tak jak zapis decyzji architektonicznej zastępuje wcześniejszą decyzję. Kolejny recenzent będzie mógł sprawdzić, co uległo zmianie i dlaczego.

Zachowajcie kwestię nierozstrzygniętą. Drugą sprzecznością było to, z jakiego modelu sztucznej inteligencji powinni korzystać podagenci. Dwie osoby opowiadały się za jednym modelem najwyższej klasy dla każdego podagenta; jedna osoba proponowała dobór modeli w zależności od zadania. W głosowaniu padły dwa głosy „do dyskusji” i dwa „zgadzam się”. Kwestia ta pozostała celowo nierozstrzygnięta, ponieważ dotyczy ona tego, ile każda osoba jest skłonna wydać ze środków własnych, a nie faktu związanego z kodem źródłowym. Pozostaje to w prywatnych zasadach każdej osoby.

Co odkryto podczas żniw

Z pierwszej strony przeglądu przyjęto piętnaście zgłoszeń: 11 dotyczących naszego głównego repozytorium produktów (z czego dwa dotyczyły również repozytorium gier), trzy dotyczące wtyczki „shared skills” oraz jedno dotyczące poprawki eksportera właściwego dla projektu „Harvest”. Kolejne siedemnaście propozycji pochodziło z drugiej strony: fakty autorstwa jednej osoby, które zespół zgodził się udostępnić, oraz dwa zestawy, które podczas pierwszego liczenia zostały błędnie zakwalifikowane jako autorstwa jednej osoby. Na drugiej stronie jedna propozycja została odrzucona w głosowaniu, trzy odłożono do dalszej dyskusji lub w celu znalezienia dla nich bardziej odpowiedniego miejsca, a trzy zostały zatwierdzone, ale wymagają kodu lub umiejętności, a nie jedynie wpisu w dokumentacji. Kwestia dotycząca modelu pozostała otwarta.

Najczęściej powtarzającym się zagadnieniem były komentarze. Trzech autorów, z których jeden odnotował to czterokrotnie: komentarze przedstawiają trwałe fakty dotyczące kodu; nigdy nie opisują samej zmiany ani jej historii. Jeden z autorów zauważył, że najczęściej winowajcami są podagenci.

Najszersza z nich dotyczyła dowodów. Czterech z pięciu autorów sformułowało wersję zasady: „zweryfikuj, zanim sformułujesz twierdzenie; nieudane poszukiwanie nie stanowi dowodu na brak”. Twierdzenia recenzentów mają charakter hipotez, a niemożność odtworzenia błędu nie dowodzi, że nie może on wystąpić. Była to zasada najbliższa wspólnej regule postępowania obowiązującej w zespole, jednak nie została nigdzie spisana ani udostępniona innym.

Inny zbiór przypadków, autorstwa dwóch osób, dotyczył nieaktualnego stanu repozytorium Git: lokalnej gałęzi znacznie opóźnionej względem zdalnej oraz wyszukiwania przeprowadzonego w niewłaściwym kopii roboczej. Każdy z pięciu odnotowanych w nim incydentów skutkował pewnym, ale błędnym stwierdzeniem, które znalazło się w treści komunikatu commit lub opisie zgłoszenia PR.

W ramach gromadzenia danych skorygowano błędne wytyczne, a nie tylko te brakujące. Trzy ustalenia dotyczyły wniosków o „GŁOSOWANIE PRZECIW” lub „EDYCJĘ” w odniesieniu do wytycznych, które już posiadaliśmy:

• W naszym wspólnym komunikacie poinstruowanoAGENTS.md agentów, aby przylint:fix wprowadzaniu zmian w regułach lintowania stosowali poprawki obejmujące całe repozytorium. Trzy osoby niezależnie od siebie ostrzegały przed takim postępowaniem: repozytorium nie przechodzi pomyślnie lintowania w stanie początkowym, więc poprawka obejmująca całe repozytorium powoduje, że Państwa różnice zostają zagubione wśród niepowiązanych zmian formatowania.
• Wspólna funkcja, która zgodnie z opisem ma przełączać się na API w przypadku gh pr editniepowodzenia. Nie kończy się ona jednak niepowodzeniem: wyświetla komunikat ostrzegawczy o charakterze niekrytycznym, zwraca kod wyjścia 0 i pozostawia pull request bez zmian. Mechanizm awaryjny oparty na sytuacji, która nigdy nie ma miejsca, nigdy nie zostaje uruchomiony. Trzech autorów napotkało tę sytuację w trzech repozytoriach.
• W istniejącym ostrzeżeniu zawartym w dokumentacji naszego agenta pewien błąd w bazie danych został określony jako „bezpieczny”, ponieważ powoduje natychmiastowy błąd. Trzy osoby popełniły ten błąd w trzech różnych tabelach. W jednym przypadku błąd ten przeszedł proces weryfikacji, przeszedł kontrolę ciągłości integracji (CI) i spowodował awarię dopiero w czasie wykonywania.

Niektóre uzgodnione zasady powinny zostać uwzględnione w ramach automatycznej kontroli. Powyższe ostrzeżenie dotyczące bazy danych można sprawdzić automatycznie: test odczytujący schemat spowodowałby zakończenie działania całej klasy, podczas gdy dokumentacja jedynie o tym ostrzega. Stwierdzono, że zasada „Nigdy nie edytuj ręcznie wygenerowanego pliku schematu” jest prawdziwa, jednak pozostawiono ją w zawieszeniu, ponieważ sformułowanie tekstowe nie jest właściwym sposobem jej egzekwowania. Dwa inne uzgodnione punkty zostały już opisane jako procedury krok po kroku, co czyni je umiejętnościami. Kilka pozycji opuszczono głosowanie jako zgłoszenia, a nie jako dokumentacja.

Zasada może stanowić domyślne zachowanie, a mimo to wymaga sformułowania. Dwie osoby niezależnie od siebie zapisały: „nigdy nie należy dokonywać commitów ani wysyłać zmian, chyba że zostanie o to poproszone”. Jedna z nich ujęła to najlepiej: „zapisanie plików nie oznacza zgody na ich zatwierdzenie”. Każdy użytkownik powinien już postępować w ten sposób. Dwie osoby zapisały to, ponieważ sytuacja ta i tak wciąż się powtarzała, co stanowi argument przemawiający za wyraźnym sformułowaniem tej zasady.

W procesie zbierania wykryto błąd. Każdy pakiet posiadał znacznik wersji, dzięki czemu mechanizm weryfikacyjny odmawiał porównywania pakietów utworzonych na podstawie różnych reguł zbierania. Znacznik ten pochodził z wersji wtyczki, a nie z eksportera. Wszystkie pięć pakietów zostało utworzonych za pomocą skryptów identycznych pod względem bajtowym, a mimo to opatrzonych trzema różnymi wersjami. Mechanizm zabezpieczający nigdy nie uruchamiałby się w przypadku rzeczywistej zmiany reguł, a uruchamiałby się przy każdej niepowiązanej aktualizacji wtyczki. Ta poprawka była jedną z piętnastu.

Jak często należy to uruchamiać

Pierwsze podsumowanie jest najbardziej czasochłonne: miesiące prywatnych notatek, przeglądanych podczas jednej, ściśle wyznaczonej sesji. Następnie proszę wprowadzić pięciominutowe, rutynowe sprawdzanie podczas regularnych spotkań zespołowych: czy pojawiło się coś nowego, co zapisała więcej niż jedna osoba?

Pięć rodzajów awarii, które należy uwzględnić przy projektowaniu:

• Tylko do zapisu: reguły są promowane, a nikt nie sprawdza, czy zachowanie agenta uległo zmianie.
• Nieaktualna i bez właściciela: reguła współdzielona przetrwała dłużej niż kod, który opisuje.
• Promowane na zasadzie „n=1”: zdecydowana opinia jednej osoby staje się zasadą obowiązującą w zespole, ponieważ to właśnie ona jako pierwsza ją sformułowała.
• Jeden dokument zawierający cztery rodzaje treści: stałe zasady, procedury, materiały referencyjne oraz historię — wszystko w jednym pliku, którego nikt nie czyta od początku do końca.
• Wyprowadzona do tego stopnia, że stała się bezużyteczna: zasada uogólniona w tak dużym stopniu w stosunku do zdarzenia, które ją spowodowało, że nie wskazuje już podmiotowi, jak ma postępować.

Proszę wykonać to ręcznie

Nie potrzebują Państwo specjalnych narzędzi. Nasz eksport polegał na zastosowaniu niewielkiego skryptu, jednak każdy etap można wykonać ręcznie:

1. Eksportuj w trybie prywatnym. Każda osoba powinna skopiować swój folder pamięci automatycznej (w Claude Code: ~/.claude/projects/<project>/memory/), swoje oraz~/.claude/CLAUDE.md wszelkie umiejętności osobiste do jednego folderu przeznaczonego dla danej osoby.
2. Przed udostępnieniem należy usunąć niepotrzebne informacje. Każda osoba usuwa wszystko, co nie powinno zostać przekazane: dane uwierzytelniające, dane klientów, wszelkie informacje dotyczące konkretnych współpracowników. Żadna treść nie opuszcza systemu, dopóki jej właściciel jej nie przeczyta.
3. Grupowanie według znaczenia. Recenzent – czy to osoba, czy automat – grupuje wpisy, które wyrażają tę samą treść innymi słowami, i odnotowuje, kto jest autorem każdego z nich.
4. Proszę policzyć unikalnych autorów. Kandydatem jest sytuacja, w której występują co najmniej dwaj niezależni autorzy. Proszę połączyć urządzenia należące do jednej osoby, pominąć wspólny tekst źródłowy oraz odnotować, które klastry pozostają bez udziału Państwa najaktywniejszego użytkownika.
5. Klasyfikacja i kierowanie. Proszę oznaczyć każdy element jako ADD, UPVOTE, DOWNVOTE lub EDIT, a następnie przypisać mu miejsce docelowe zgodnie z powyższą tabelą kierowania.
6. Proszę wymienić sprzeczności osobno. W miarę możliwości proszę je rozstrzygnąć na podstawie zakresu; pozostałe proszę pozostawić nierozstrzygnięte i wyraźnie to zaznaczyć.
7. Niech zgromadzeni zagłosują. Proszę umieścić propozycje na jednej stronie, a informacje dotyczące jednego autora na drugiej, a następnie wspólnie podjąć decyzję.
8. Każdą aktualizację należy traktować jako odrębną akcję PR w odniesieniu do repozytorium, którego dotyczy. Proszę nie umieszczać surowych pakietów w gałęzi głównej.

Najczęściej zadawane pytania

Czym jest „zbieranie wspomnień”?

„Zbieranie pamięci” to praktyka zespołowa stosowana w przypadku agentów programowych opartych na sztucznej inteligencji: każdy programista eksportuje pamięć swojego prywatnego agenta oraz osobiste reguły, a jeden recenzent grupuje te wpisy spośród eksportów wszystkich uczestników; reguły, które kilka osób opracowało niezależnie, są następnie przenoszone do plików współdzielonych, takich jak CLAUDE.mdlub AGENTS.md. Jest to etap utrzymania inżynierii kontekstowej na poziomie zespołu.

Ile osób musi wyrazić zgodę, aby dana zasada została wprowadzona do pliku CLAUDE.md?

Korzystamy z usług co najmniej dwóch niezależnych autorów. Należy liczyć poszczególne osoby, a nie wpisy: osoba, która trzykrotnie sformułowała tę samą zasadę lub dokonała eksportu z dwóch urządzeń, nadal liczy się jako jeden autor. Dwie osoby, które skopiowały ten sam opublikowany tekst, również nie są niezależne. Próg ten decyduje o tym, co zostanie zaproponowane; zespół nadal głosuje nad każdą promocją.

Co należy do zasobów zespołu CLAUDE.md, a co do pamięci osobistej?

Należy pamiętać, że wszystkie elementy zawarte w tym repozytorium muszą znajdować się w projekcieCLAUDE.md, ponieważ są one ładowane automatycznie. Procedury należy umieszczać w sekcji „umiejętności”, szczegółowe informacje referencyjne – w sekcji „dokumentacja” wraz z odnośnikiem, a wszystko, co może sprawdzić maszyna, – w regule lintowej lub teście. Preferencje dotyczące Państwa własnych narzędzi, sprzętu lub budżetu pozostają sprawą osobistą.

Czy zasady dotyczące zespołu należy umieścić w pliku CLAUDE.md czy w pliku AGENTS.md?

Zasady, których powinno przestrzegać każde narzędzie oparte na sztucznej inteligencji, należy umieścić w AGENTS.md; instrukcje dotyczące konkretnie Claude’a należy umieścić w CLAUDE.md. Claude Code może odczytywać pliki bezpośrednioAGENTS.md lub poprzez import@AGENTS.md, dzięki czemu jeden plik może służyć wszystkim narzędziom wykorzystywanym przez Państwa zespół.

Co należy zrobić, gdy zeznania dwóch programistów są ze sobą sprzeczne?

Proszę najpierw sprawdzić zakres: obie opcje mogą być prawdziwe w różnych repozytoriach, a późniejsza zmiana narzędzia mogła rozwiązać tę kwestię. Jeśli jedna ze stron jest nieaktualna, proszę ją zastąpić, a nie nadpisywać. Jeśli rozbieżność dotyczy raczej preferencji niż faktu związanego z kodem źródłowym, proszę pozostawić ją nierozwiązaną i uwzględnić w prywatnych zasadach każdej osoby.

Jak często zespół powinien przeprowadzać „zbieranie wspomnień”?

Proszę przeprowadzić jedną sesję o ograniczonym zakresie, aby uporać się z zaległościami, a następnie podczas regularnych spotkań synchronizacyjnych zespołu poświęcać pięć minut na sprawdzanie na stojąco, czy pojawiły się nowi kandydaci. Pierwsza selekcja jest najbardziej kosztowna; później liczba kandydatów powinna być niewielka.

Niech to będzie decyzja zespołowa

W ramach procesu gromadzenia wiedzy zespół decyduje, które zasady zostaną przyjęte wspólnie; osoba dokonująca przeglądu jedynie przedstawia propozycje. Eksport danych, grupowanie i liczenie można w całości zautomatyzować. Głosowanie jednak nie może i nie powinno być zautomatyzowane. To, które zasady są wiążące dla wszystkich, które pozostają osobiste, a które kwestie sporne pozostają otwarte, to decyzje należące do osób, które będą się nimi kierować. To samo stwierdzenie zawarte jest w raporcie „Istnieje, ale pomieszczenia nie ma”: zbiorczy obraz ma sens dopiero wtedy, gdy osoby odpowiedzialne za poprawki podejmą wspólną decyzję.

Jest to retrospektywa oparta na różnych źródłach danych. Kiedy nasi agenci AI zgłaszali własne punkty do omówienia podczas retrospektywy, dane pochodziły z ich sesji. Tym razem pochodziły one z naszych prywatnych notatek, a system „Room” wykonał tę samą pracę: odczytał wzorzec, wybrał poziom szczegółowości i przypisał właściciela do każdego punktu. Jeśli Państwa zespół organizuje już regularne sesje retrospektywne, „zbieranie wspomnień” może stanowić jeden z punktów porządku obrad. Pełny opis tej praktyki znajduje się w naszym przewodniku po retrospektywach agentów AI.

Chcieliby Państwo przeprowadzić własną ocenę plonów lub uważają Państwo, że nasz próg jest nieprawidłowy? Prosimy o kontakt: ai-discussion@teamretro.com.