GitHub Octoverse 2026: agenci rozpoczynają ponad 40% pull requestów, a aktywność rośnie

GitHub opublikował 28 października raport Octoverse 2026, podając, że agenci przygotowali pierwszy szkic dla ponad 40% pull requestów z września. Pull request to propozycja zmian w kodzie, przekazywana do przeglądu przed dołączeniem do projektu. Wynik ten umieszcza automatyczne tworzenie szkiców w centrum kluczowego procesu wytwarzania oprogramowania, pozostawiając jednak produktywność i jakość jako odrębne kwestie.

GitHub Octoverse 2026 informuje także o rekordowej aktywności na platformie. Z tego powodu rozróżnienie między tworzeniem zmian a dostarczaniem użytecznego oprogramowania staje się ważniejsze. Agent AI do programowania, czyli oprogramowanie wykonujące zadania programistyczne przy użyciu modelu AI, może generować pracę, która nadal wymaga istotnej oceny człowieka.

Dla liderów inżynierii główne napięcie dotyczy rosnącej produkcji kodu i zdolności do jego oceny. Wcześniejsze badania METR pokazały, dlaczego te wskaźniki należy traktować oddzielnie. Tymczasem wsparcie GitHub dla agentów Anthropic i OpenAI umieszcza konkurujących dostawców w tym samym środowisku przeglądu. Praktyczne pytanie brzmi, ile użytecznej pracy przechodzi przez cały proces.

GitHub Octoverse 2026 odnotowuje zmianę w sposobie rozpoczynania zmian

Według ustaleń Octoverse firmy GitHub programiści wykonali 17,9 miliarda pushów i scalili 1,3 miliarda pull requestów w roku objętym raportem. Push wysyła zapisane zmiany w kodzie do GitHub. Łączna liczba pushów przekroczyła sumę z dwóch poprzednich lat.

Okres raportowania trwa od 1 października 2025 r. do 30 września 2026 r. Większość danych obejmuje projekty publiczne i prywatne. GitHub przeliczył wcześniejsze lata z użyciem porównywalnych definicji, co jest istotnym zastrzeżeniem przy zestawianiu tych danych z wcześniej opublikowanymi raportami.

Udział zmian rozpoczętych przez agentów wzrósł z 17% w marcu do ponad 40% we wrześniu. GitHub definiuje te zgłoszenia na podstawie wykrywalnego pierwszego szkicu wygenerowanego przez agenta.

Wskaźnik adopcji mierzy sposób rozpoczynania proponowanych zmian, a nie ilość ukończonego oprogramowania, które agent tworzy samodzielnie.

To rozróżnienie zmienia znaczenie nagłówka. Programista może określić zadanie, odrzucić początkowe podejście, przepisać części wyniku i podjąć ostateczną decyzję o zatwierdzeniu. Uznanie powstałej pracy za całkowicie autonomiczną pomijałoby te wkłady.

Równie ważny jest mianownik. Udział pull requestów nie przekłada się bezpośrednio na udział kodu, godzin pracy ani funkcjonalności produktu. Proponowane zmiany różnią się rozmiarem, trudnością i znaczeniem.

Rozważmy korektę dokumentacji obok zmiany w autoryzacji płatności. Obie mogą skutkować pull requestem. Ich wymogi dotyczące przeglądu i konsekwencje istotnie się różnią, nawet jeśli platforma rejestruje każdą jako pojedynczą propozycję.

Podobnie rosnąca liczba proponowanych zmian może odzwierciedlać kilka zjawisk. Zespoły mogą podejmować więcej projektów, dzielić pracę na mniejsze części lub generować dodatkowe poprawki. Każda z tych możliwości wymaga odmiennej interpretacji.

Dlatego raport zasługuje na uwagę, nie powinien jednak unieść wszystkich wniosków przypisywanych debacie o programowaniu z AI. Dokumentuje istotną zmianę w obserwowalnych zachowaniach programistycznych. Ustalenie ekonomicznej wartości tego zachowania wymaga dodatkowych dowodów.

Dla osób śledzących adopcję agentów GitHub użytecznym punktem wyjścia jest zatem precyzyjne przypisanie źródła. Są to pomiary platformy GitHub, oparte na definicjach i granicach wykrywania przyjętych przez firmę. Nie są niezależnie audytowanym szacunkiem wkładu AI w całe wytwarzanie oprogramowania.

W tych kategoriach wiadomość nadal ma znaczenie. Tworzenie szkiców stanowi istotny punkt wejścia do pracy inżynieryjnej. Gdy agenci w nim uczestniczą, systemy przeglądu stają się miejscem, w którym ich propozycje spotykają się z wymaganiami projektu i ludzką odpowiedzialnością.

To bezpośrednio włącza maintainerów, menedżerów inżynierii i osoby odpowiedzialne za przegląd bezpieczeństwa w tę historię. Ich decyzje określają, czy dodatkowa aktywność zamieni się w użyteczne oprogramowanie, czy w większy zbiór niedokończonych propozycji.

Więcej szkiców zwiększa presję na zdolność przeglądu

Zespoły inżynieryjne zyskują na szybszym tworzeniu szkiców wtedy, gdy potrafią oceniać powstające zmiany bez utraty kontroli nad jakością lub priorytetami.

To argument operacyjny, a nie twierdzenie, że każdy zespół już mierzy się z przeciążoną kolejką przeglądów. Presja wynika z procesu pracy: przygotowanie propozycji i przyjęcie za nią odpowiedzialności wymagają innej pracy.

Recenzent musi ustalić, co zmiana ma osiągnąć. Następnie powinien określić, czy jej implementacja odpowiada temu celowi. Zautomatyzowane testy mogą wspierać ten osąd, ale ich użyteczność zależy od tego, co faktycznie sprawdzają.

Test potwierdzający oczekiwane dane wyjściowe może nadal pominąć błędne założenie dotyczące zachowania klienta. Zmiana może spełniać przypisane zadanie, a zarazem kolidować z inną częścią produktu. To powody, by analizować dowody dotyczące propozycji.

Konsekwencje wykraczają też poza poprawność w chwili zgłoszenia. Ktoś musi utrzymywać implementację, wyjaśniać stojące za nią decyzje i reagować na zmiany wymagań. Dodatkowy kod tworzy zobowiązania obok każdej bezpośredniej wartości, jaką zapewnia.

Dla menedżerów inżynierii rodzi to pytanie o przepustowość. Jeśli tworzenie szkiców staje się łatwiejsze, jak zespół powinien rozdzielać uwagę między nowe propozycje, bieżące utrzymanie i niezawodność produkcyjną? Zwiększanie liczby zgłoszeń bez dostosowania tych priorytetów grozi przesunięciem ograniczenia dalej w procesie.

Badacze DORA z Google Cloud opisują podobne napięcie w analizie kompromisów związanych z rozwojem AI. Informują, że czas zaoszczędzony podczas tworzenia często przenosi się na audyt i weryfikację. W ich interpretacji AI wzmacnia istniejące mocne strony i słabości organizacji.

Ta obserwacja zapewnia użyteczne ramy do odczytywania danych platformy. Zespół z jasnymi wymaganiami i niezawodnymi mechanizmami kontroli ma inny punkt wyjścia niż zespół z niejasną odpowiedzialnością. Zapewnienie obu zespołom szybszego tworzenia szkiców nie usuwa tych różnic.

Bezpośrednia presja spada na osoby zatwierdzające zmiany i ponoszące ich konsekwencje. Maintainer nie może rozsądnie traktować pewności agenta jako substytutu dowodów. Menedżer inżynierii nie może wywnioskować wartości dla klienta wyłącznie z rosnącej liczby zgłoszeń.

Zespoły bezpieczeństwa stoją przed podobnym problemem alokacji zasobów. Propozycja może wymagać analizy, ponieważ zmienia zasady dostępu, obsługuje wrażliwe informacje lub wprowadza komponent zewnętrzny. Jej pochodzenie nie określa poziomu ryzyka.

Również zespoły produktowe mają tu rolę. Łatwiejsza implementacja zwiększa pokusę realizowania luźno zdefiniowanych zgłoszeń. Jasne kryteria akceptacji stają się cenniejsze, gdy wygenerowanie wiarygodnej implementacji wymaga mniej wysiłku.

Dla indywidualnych programistów wniosek jest bardziej konkretny niż samo uczenie się tworzenia promptów. Cenną umiejętnością jest łączenie żądanej zmiany z dowodami, że działa ona prawidłowo i należy do projektu.

Obejmuje to zachowanie uzasadnienia stojącego za decyzjami. Zespoły próbujące zbudować przeszukiwalną bazę wiedzy mierzą się z pokrewnym wyzwaniem: utrzymaniem dostępności kontekstu technicznego, gdy pierwotny autor jest nieobecny.

Dokumentacja nie może zatwierdzić zmiany. Może pomóc recenzentowi zrozumieć ograniczenia, od których zależy zatwierdzenie. Wraz z przyspieszeniem tworzenia szkiców ten wspólny kontekst zasługuje na uwagę obok samych narzędzi generatywnych.

Copilot, Claude i Codex konkurują w tym samym procesie pracy

Konkurencyjne tło pomaga wyjaśnić, dlaczego adopcja agentów staje się kwestią procesu pracy. Programiści mogą korzystać z różnych dostawców, nie opuszczając miejsca, w którym ich zespoły omawiają i zatwierdzają zmiany.

Lutowe ogłoszenie GitHub wprowadziło partnerskich agentów programistycznych, w tym Claude firmy Anthropic i Codex firmy OpenAI, w publicznej wersji zapoznawczej. Opisano w nim przydzielanie pracy z poziomu GitHub oraz przeglądanie szkiców pull requestów wygenerowanych przez tych agentów.

Ogłoszenie to wyznacza kierunek produktu w roku objętym raportem. Nie należy odczytywać go jako kompletnego zestawienia bieżącej dostępności ani warunków dostępu.

Dla GitHub udostępnianie konkurujących agentów sprawia, że proces przeglądu staje się strategicznym zasobem obok własnego asystenta programistycznego.

Platforma może pozostać centralna nawet wtedy, gdy programista preferuje innego dostawcę do konkretnego zadania. Praca nadal potrzebuje miejsca docelowego, historii, dyskusji i procesu zatwierdzania.

Dla Anthropic i OpenAI obecność w tym środowisku oferuje kolejną drogę do pracy programistycznej. Ich agenci mogą konkurować o zadania tam, gdzie zespoły już zarządzają zmianami w oprogramowaniu.

To porównanie nie przesądza, który agent osiąga lepsze rezultaty. Umowa dystrybucyjna i ogłoszenie produktu nie mogą odpowiedzieć na to pytanie. Pokazują, jak dostawcy docierają do użytkowników, a nie jak niezawodnie rozwiązują porównywalne zadania.

Rozróżnienie to ma znaczenie przy interpretowaniu adopcji agentów GitHub. Więcej propozycji rozpoczętych przez agentów nie wskazuje automatycznie zwycięskiego dostawcy. Adopcja procesu pracy i konkurencja w jego obrębie to odrębne zjawiska.

Konkretny przykład pojawia się w lutowym ogłoszeniu: programiści mogli przypisać issue agentowi i otrzymać szkic do przeglądu. Issue rejestruje żądane zadanie lub problem. Nadaje to delegowaniu rozpoznawalny początek i wynik możliwy do oceny.

Znaczenie tkwi w przekazaniu zadania. Żądanie staje się próbą implementacji, która wraca do systemu, w którym ludzie mogą sprawdzać zmiany i prosić o poprawki. Agent uczestniczy w istniejącej strukturze odpowiedzialności.

Dla zespołu oceniającego dostawców ta struktura powinna czynić porównanie bardziej miarodajnym. Istotne pytanie brzmi, czy dostawca realizuje rzeczywistą pracę zespołu przy akceptowalnym nakładzie przeglądu. Dopracowana demonstracja nie może tego potwierdzić.

Wyobraźmy sobie porównanie agentów w powtarzalnym zadaniu utrzymaniowym. Użyteczna ocena uwzględniałaby, czy każda propozycja odpowiada na żądanie, respektuje konwencje projektu i zapewnia wiarygodną weryfikację. Liczenie wygenerowanych plików odpowiadałoby na inne pytanie.

To samo dotyczy wdrażania agenta w zespole. Dostęp do narzędzia to dopiero początek. Uprawnienia, granice zadań i odpowiedzialność za zatwierdzanie nadal wymagają wyraźnych decyzji.

Zachowanie spójnego środowiska przeglądu ma także praktyczną korzyść. Zespoły mogą ocenić nowego dostawcę bez jednoczesnej wymiany wszystkich otaczających procesów. Ułatwia to odróżnienie różnic między dostawcami od zmian w procesie pracy.

Historia konkurencji wspiera więc główne napięcie. Dostawcy sprawiają, że tworzenie szkiców staje się bardziej dostępne w ustalonych środowiskach inżynieryjnych. Wartość tego dostępu zależy od tego, jak skutecznie zespoły przekształcają konkurujące propozycje w zaakceptowane, łatwe w utrzymaniu zmiany.

Szybsze scalanie pozostawia otwarte ważne pytania o jakość

GitHub podaje, że pull requesty z udziałem agentów we wrześniu osiągnęły 90% wskaźnik scalenia w ciągu dwóch tygodni, wobec około 86% dla zgłoszeń bez wykrytego udziału agentów.

Scalenie oznacza przyjęcie zmiany do projektu; nie potwierdza jej długoterminowej niezawodności ani wartości biznesowej.

Ograniczenie to dotyczy również zmian wprowadzanych przez ludzi. Zatwierdzenie może być uzasadnione na podstawie dostępnych dowodów, choć późniejsze zachowanie ujawni przeoczoną interakcję. Jakość oprogramowania ujawnia się z czasem.

Szybsza ścieżka do akceptacji może odzwierciedlać poprawę. Może też wynikać z różnic w zgłaszanych zadaniach, praktykach projektowych lub wymaganym poziomie kontroli. Porównanie obserwacyjne nie może automatycznie rozdzielić tych wyjaśnień.

Dobór zadań ma szczególne znaczenie. Zespoły mogą delegować pracę, którą już potrafią sprecyzować i zweryfikować. Bardziej niejednoznaczne zadania mogą pozostawać po stronie programistów. Porównywanie tych grup bez uwzględnienia ich różnic grozi zawyżeniem wyniku.

Należy też rozważyć odwrotną możliwość. Agent może sprawić, że wcześniej zaniedbane utrzymanie stanie się praktyczne, rozszerzając zakres pracy podejmowanej przez zespół. Rzetelna ocena powinna uwzględniać użyteczny dodatkowy efekt.

W tym miejscu zawodzą uproszczone interpretacje w obu kierunkach. Dodatkowa aktywność nie jest wystarczającym dowodem, że każdy zespół stał się bardziej produktywny. Brak uniwersalnego wskaźnika produktywności nie jest wystarczającym dowodem, że ta aktywność nie ma wartości.

Eksperyment METR dotyczący produktywności programistów pokazuje, dlaczego pomiar ma znaczenie. W ich randomizowanym badaniu z początku 2025 roku 16 doświadczonych programistów wykonało 246 zadań w znanych im projektach open source. Dopuszczenie użycia AI wydłużyło czas realizacji o 19%.

Wyniki te opisują określoną populację, środowisko zadań i generację narzędzi. Nie należy traktować ich jako bezpośredniego pomiaru wydajności agentów pod koniec 2026 roku.

Znaczenie badania w tym kontekście jest metodologiczne. Obserwacja, że programiści korzystają z narzędzia, nie mówi, o ile szybciej wykonują porównywalną pracę. Wymaga to wiarygodnego porównania.

Badania historyczne również wymagają aktualizacji wraz ze zmianą zachowań. Wynik może pozostawać trafny dla pierwotnego kontekstu, a zarazem stać się mniej informacyjny dla nowszego sposobu pracy. Traktowanie go jako ponadczasowego byłoby kolejnym błędem pomiarowym.

Porównania jakości wymagają równie starannych granic. Proponowana zmiana może przejść istniejące kontrole, jednocześnie dodając złożoność, którą przyszli opiekunowie kodu będą musieli przejąć. Z drugiej strony większa implementacja może usunąć niewygodne obejście i zmniejszyć przyszły nakład pracy.

Recenzenci potrzebują zatem dowodów powiązanych z zadaniem. Trafne kontrole, zrozumiałe uzasadnienie i jasny opis zmienionego zachowania dostarczają więcej informacji niż etykieta pochodzenia.

Dla nabywców korporacyjnych tworzy to wyzwanie zakupowe. Panele wdrożeniowe łatwo podsumować, podczas gdy ustalenie liczby unikniętych incydentów i zmniejszonych obciążeń utrzymaniowych zajmuje więcej czasu. Przekonująca ocena powinna uznać tę różnicę.

Właściwy wniosek jest konkretny. Dane GitHub dotyczące akceptacji dostarczają informacji o tym, jak zmiany przechodzą przez jego platformę. Pozostawiają pole do dalszych badań nad poprawkami, niezawodnością, wysiłkiem recenzentów i użytecznym dostarczaniem oprogramowania.

Ta luka stanowi program pomiaru. Nie wymaga zakładania ani że agenci są powszechnie korzystni, ani że ich wkład jest jedynie szumem.

Pomiar produktywności agentów staje się trudniejszy, gdy zmienia się praca

Wyzwanie pomiarowe wykracza poza wybór właściwego panelu. Korzystanie z agentów może zmieniać zadania, których podejmują się programiści, oraz sposób, w jaki rozdzielają uwagę.

W swojej aktualizacji badań nad produktywnością z lutego 2026 roku METR stwierdził, że jego późniejszy eksperyment dostarczył niewiarygodnego oszacowania bieżącego wpływu AI na produktywność. Rekrutacja, dobór zadań i równoległe używanie agentów komplikowały interpretację.

Badacze uznali, że programiści prawdopodobnie odnosili większe korzyści, niż sugerowały ich wcześniejsze oszacowania. Podkreślili też, że ich dane dają słabe dowody co do skali tej poprawy.

Wiarygodna ocena musi uwzględniać zmiany w samej pracy, obok zmian w narzędziach, które ją wykonują.

Ma to znaczenie, ponieważ porównanie stałych zadań odpowiada na ograniczone pytanie. Może oszacować, jak wsparcie wpływa na konkretne zlecenie. Nie może w pełni uchwycić tego, co dzieje się, gdy wsparcie zmienia zadania wybierane przez ludzi.

Załóżmy, że programista wcześniej odkładał żmudną migrację, ponieważ wymagała zbyt dużego skupionego wysiłku. Agent może uczynić tę pracę wykonalną w skądinąd intensywnym tygodniu. Korzyść obejmuje wykonanie czegoś, co pozostałoby niezrealizowane.

Rozważmy teraz przypadek odwrotny. Łatwiejsze tworzenie szkiców może zachęcić zespół do wdrożenia funkcji, zanim ustali, czy użytkownicy jej potrzebują. Implementacja może odnieść sukces techniczny, jednocześnie pochłaniając uwagę, którą lepiej byłoby przeznaczyć gdzie indziej.

Te przykłady są możliwościami analitycznymi, a nie zgłoszonymi wynikami z zestawu danych Octoverse. Wyjaśniają, dlaczego użyteczne dostarczanie wymaga powiązania z intencją i rezultatami.

Praca równoległa wprowadza kolejną komplikację. Programista może recenzować propozycję, podczas gdy agent pracuje nad osobnym zadaniem. Mierzenie czasu działania agenta jako czasu pracy człowieka błędnie przedstawiałoby taki układ.

Jednak pomijanie nadzoru również zniekształciłoby wynik. Przygotowanie zadania, przerwania, odrzucone podejścia i końcowa recenzja należą do oceny procesu pracy. Granica rozliczania wpływa na wniosek.

Dla organizacji przemawia to za kilkoma uzupełniającymi się formami dowodów. Oceny porównywalnych zadań mogą badać wysiłek potrzebny do ich ukończenia. Rejestry operacyjne mogą pokazywać akceptację i poprawki. Wyniki produktowe mogą ustalić, czy dostarczone zmiany pomogły użytkownikom.

Żaden pojedynczy wskaźnik nie obejmuje wszystkiego. To powód, aby jasno wskazywać, co dany wskaźnik przedstawia, zamiast scalać nieporównywalne wyniki w uniwersalny wynik produktywności.

Zespół może poprawić szybkość dostarczania, jednocześnie mieć trudności z utrzymaniem. Inny może ograniczyć powtarzalny wysiłek bez zwiększania częstotliwości wydań, ponieważ akceptacje nadal są ograniczane gdzie indziej. Oba przypadki zasługują na opisy odpowiadające ich rzeczywistym doświadczeniom.

Ta sama dyscyplina obowiązuje przy porównywaniu zespołów. Dojrzała usługa o rygorystycznych wymaganiach niezawodności różni się od nowego projektu eksperymentalnego. Liczba ich zgłoszeń nie powinna stawać się rankingiem skuteczności programistów.

GitHub Octoverse 2026 jest użyteczny jako dowód zmieniającego się środowiska programistycznego. Jego szersze implikacje stają się wyraźniejsze, gdy aktywność platformy rozpatruje się obok badań na poziomie zadań i wyników organizacyjnych.

Dla programistów praktycznym pytaniem jest, czy ich pracę łatwiej ukończyć i utrzymać. Dla menedżerów — czy te korzyści utrzymują się w całym zespole. Żadne z tych pytań nie znika, gdy tworzenie szkiców staje się powszechne.

Obserwuj wysiłek recenzji, niezawodność i wyniki porównywalnych zadań

Kolejne użyteczne dowody powinny łączyć udział agentów z tym, co dzieje się po pojawieniu się propozycji. W nadchodzących miesiącach czytelnicy powinni zwracać uwagę na zmiany wyjaśniające związek między tworzeniem szkiców a dostarczaniem.

Najmocniejsze kolejne dowody połączą pracę pochodzącą od agentów z wysiłkiem recenzji, wynikami produkcyjnymi i wiarygodnymi porównaniami zadań.

Pierwszym sygnałem jest lepsze raportowanie wysiłku recenzji. Dostawcy platform i zespoły inżynieryjne powinni pokazywać, ile ludzkiej uwagi wymagają zaakceptowane propozycje agentów. Sam czas oczekiwania nie może tego ustalić.

Zgłoszenie może czekać w kolejce, nie pochłaniając dużego wysiłku recenzentów. Inne może przejść szybko, wymagając intensywnej dyskusji. Rozróżnienie tych sytuacji uczyniłoby statystyki akceptacji bardziej informacyjnymi.

Dowody spadku wysiłku recenzji przy porównywalnej pracy wzmocniłyby argument, że agenci usprawniają cały proces pracy. Rosnący wysiłek sugerowałby, że część oszczędności na tworzeniu szkiców przenosi się na nadzór.

Czytelnicy powinni także badać, jak zespoły uwzględniają odrzuconą pracę. Panel skupiony wyłącznie na udanych scaleniach może pomijać wysiłek poświęcony ocenie propozycji, które nigdy nie zostają zaakceptowane. Te próby również należą do oceny.

Drugim sygnałem jest niezawodność po akceptacji. Szukaj ocen śledzących zmiany po scaleniu i badających, czy wymagają one poprawek, cofnięć lub reakcji na incydenty.

Cofnięcie usuwa lub odwraca wcześniejszą zmianę. Jego znaczenie zależy od kontekstu, ponieważ decyzje produktowe mogą się zmieniać z przyczyn niezwiązanych z jakością kodu. Użyteczne raportowanie wymaga wystarczającej ilości szczegółów, aby rozdzielić te wyjaśnienia.

Stabilna niezawodność przy szybszym dostarczaniu wzmocniłaby argument za zyskami netto. Więcej późniejszych napraw by go ograniczyło. Odpowiednie porównanie powinno uwzględniać ryzyko zadania i dojrzałość projektu.

Jest to szczególnie ważne dla nabywców oceniających wdrożenie w całej organizacji. Udany pilotaż w ograniczonych pracach utrzymaniowych nie dowodzi automatycznie gotowości do obsługi wrażliwych systemów. Rozszerzenie powinno dostarczyć dowodów dotyczących nowego zakresu.

Trzecim sygnałem są zaktualizowane badania porównujące równoważną pracę z użyciem obecnych narzędzi. Badania powinny wyjaśniać, jak radzą sobie z doborem zadań, równoległymi agentami i ludzkim wysiłkiem otaczającym generowanie.

Spójna poprawa w wiarygodnych ocenach wzmocniłaby argument dotyczący produktywności. Mieszane wyniki sugerowałyby, że korzyści zależą od zadania, programisty lub organizacji. Każdy z tych rezultatów byłby bardziej użyteczny niż uniwersalne twierdzenie.

Badacze powinni również uwidaczniać granice. Wynik na poziomie zadania, wynik dostarczania przez zespół i wynik satysfakcji programistów mogą być trafne. Opisują różne wymiary doświadczenia.

Czytelnicy oceniający GitHub Octoverse 2026 powinni zachować te kluczowe rozróżnienia, gdy pojawiają się nowe ogłoszenia. Pytajcie, jaką pracę rozpoczynają agenci, kto ją ocenia i co dzieje się po zatwierdzeniu. Śledźcie, czy organizacje publikują dowody dotyczące wysiłku recenzji i niezawodności obok wdrożenia. Porównując narzędzia, szukajcie wyników z zadań podobnych do własnych, z nadzorem uwzględnionym w rozliczeniu. Zachowujcie kontekst stojący za ważnymi zmianami, aby przyszli recenzenci mogli zrozumieć ich cel. Raport sprawia, że trudno przeoczyć udział agentów; wasza kolejna decyzja powinna zależeć od pracy, którą ten udział pomaga ukończyć. Jakie dowody pokazałyby, że wasz zespół dostarcza bardziej użyteczne oprogramowanie przy mniejszym całkowitym wysiłku?