Pytaj, kto kogo sprawdza

Zanim firma wpuści agentów AI do kodu albo do obsługi klienta, zarząd zwykle pyta, na jakim modelu to działa. Bronię tezy, że przy modelach z czołówki ta odpowiedź rozstrzyga mniej, niż się wydaje. O tym, czy wdrożenie będzie bezpieczne i czy się zwróci, w dużej mierze decyduje układ kontroli: kto planuje, kto kwestionuje, kto zatwierdza i jaką liczbę trzeba pobić, zanim praca w ogóle ruszy.

Spieram się z założeniem, które stoi za porównaniami Claude kontra GPT: że wybór modelu jest główną decyzją wdrożenia, a tabela benchmarków właściwym sposobem jej podjęcia. Nie przypisuję tego założenia żadnej firmie. Spieram się z rozumowaniem. Model ma znaczenie i pokażę, kiedy przesądza o wyniku. Twierdzę tylko, że kupujący usługę AI powinien pytać o niego później, a o układ kontroli wcześniej.

Sprint, z którego najmniej da się skopiować model

Dwudziestego trzeciego września 2026 roku Raymond Wang wraz z dwoma współautorami opisał na blogu claude.dev dwutygodniowy sierpniowy sprint zespołu Anthropic. Cel był prosty: przyspieszyć własne aplikacje firmy. Wpis nosi tytuł How we made claude.ai 3x faster in two weeks. Najgłośniejsza liczba dotyczy jednej miary. Na 75. percentylu czas do strony, na której da się już pisać, przy świeżym wczytaniu claude.ai spadł z 3,1 do 0,55 sekundy. To poprawa 5,6 raza.

Ta liczba łatwo się myli z drugą. Autorzy zmierzyli przed sprintem i po nim trzynaście wartości w czterech ścieżkach użytkownika. Średnia geometryczna poprawy wyszła 3,1 raza i stąd „trzy razy szybciej” w tytule. Zbieżność 3,1 sekundy i 3,1 raza wygląda na przypadkową. Jeśli zobaczysz ten sprint streszczony jako „claude.ai ładuje się trzy razy szybciej”, streszczenie pomieszało dwie miary.

Ciekawsze od wyniku jest to, jak go osiągnięto. Claude pracował w kanale Slacka przez Claude Tag, produkt w wersji beta, na wewnętrznym modelu badawczym, który autorzy opisują jako mniej więcej porównywalny z Opus 5.5. Każdy wątek pracy miał nazwanego właściciela, człowieka. Gdy zmiana była widoczna dla użytkownika, Claude pokazywał zrzuty ekranu albo nagrania przed i po, a o wyniku rozstrzygał właściciel wątku.

Każdy pull request przechodził automatyczny przegląd i co najmniej jedną akceptację człowieka. Testy jednostkowe powstawały przed optymalizacją, nie po niej. Wszystko, co mogło wywołać widoczny problem, wychodziło za krótkotrwałą flagą funkcji. Zmiany wysokiego ryzyka trafiały najpierw do pracowników, potem do jednego procenta użytkowników, a dopiero na końcu do wszystkich.

Jeden element ma angielską nazwę: ratchet, czyli zapadka. Zespół dodał do ciągłej integracji (CI) dwa pomiary liczby instrukcji na wybranych ścieżkach. Od tej chwili każdy pull request, który podnosił ten licznik, nie przechodził CI, a codzienne zadanie obniżało sufit za każdym razem, gdy licznik choć trochę spadł. Liczba mogła iść tylko w dół.

Według autorów zespół scalił w ten sposób ponad trzy tysiące zmian bez żadnego incydentu po stronie klienta i bez wycofania, ale to deklaracja samego Anthropic, bez niezależnego potwierdzenia. Przyjmuję ją jako opis procesu, a nie dowód jego skuteczności w każdej firmie.

Zapytajmy teraz jak kupujący. Co z tego sprintu przenosi się do twojej organizacji? Modelu nie przeniesiesz, bo był wewnętrzny i nie da się go kupić. Wpis nie pozwala też rozdzielić zasługi modelu od zasługi układu. Trzeba to powiedzieć uczciwie. Pozwala za to zobaczyć, którą część procesu da się skopiować, choć bez obietnicy tego samego wyniku: właściciela wątku, liczbę z zapadką, akceptację człowieka i wdrożenie etapami.

Wygodna oś sporu

Kupujący porównuje modele, bo porównanie daje mu liczbę, którą łatwo obronić przed zarządem. To moja interpretacja, nie wynik badania, ale łatwo ją sprawdzić na sobie. Tabela benchmarków jest cudzym pomiarem na cudzym zadaniu. Ma jedną zaletę: jest gotowa. Układ kontroli trzeba zaprojektować samemu i wziąć za niego odpowiedzialność.

Zawody, które od dawna żyją z oceniania cudzej pracy, nauczyły się zarządzać tym problemem bez modeli językowych. Kodeks etyki Międzynarodowej Rady Standardów Etycznych dla Księgowych (IESBA) wymienia pięć kategorii zagrożeń dla przestrzegania zasad etyki, w tym obiektywizmu. Jedna z nich to zagrożenie autoprzeglądem: ryzyko, że profesjonalista nie oceni należycie wyniku wcześniejszej pracy, własnej albo kogoś ze swojej firmy. Rewidenta nie wybiera się po ilorazie inteligencji. Liczy się też to, czy nie ocenia własnej roboty.

Teraz najmocniejszy zarzut wobec mojej tezy. Model naprawdę ma znaczenie. Pokazują to dane Anthropic. Dziewiątego kwietnia 2026 roku firma opisała na blogu claude.com strategię doradcy: tańszy model wykonuje zadanie od początku do końca, a droższy Opus doradza mu w punktach decyzyjnych. Na teście BrowseComp Haiku z doradcą Opus uzyskał 41,2 procent wobec 19,7 procent samego Haiku. Ta para kosztuje na zadanie 85 procent mniej niż Sonnet, ale zostaje za samym Sonnetem o 29 procent wyniku (źródło nie precyzuje, czy chodzi o punkty procentowe). To wyniki testów porównawczych podane przez Anthropic, a nie pomiar z produkcji.

Z tych liczb wynika coś niewygodnego dla obu stron sporu. Zdolności modelu wyznaczają sufit, którego sama recenzja i akceptacja nie podniosą. Jeśli zadanie przekracza możliwości wykonawcy, recenzja pokaże porażkę szybciej, ale jej nie zapobiegnie. Przeciwnik ma też rację wtedy, gdy wolumen jest ogromny, a koszt jednego zadania przesądza o rentowności, bo wybór modelu staje się wówczas decyzją finansową pierwszego rzędu.

Te same liczby pokazują jednak drugą rzecz. Ten sam Haiku ponad dwukrotnie poprawił wynik, gdy dostał drugiego uczestnika w punktach decyzyjnych. Wykonawca się nie zmienił. Zmieniło się to, kto zabiera głos przed decyzją, a był nim silniejszy model. Ten przykład wspiera obie strony sporu naraz. W wariancie z Sonnetem doradca dodał 2,7 punktu procentowego na teście SWE-bench Multilingual i obniżył koszt zadania o 11,9 procent. Doradca, jak piszą autorzy, nigdy nie wywołuje narzędzi i nie tworzy odpowiedzi dla użytkownika. Ma wyłącznie radzić.

Zawężam więc tezę. Jedno zastrzeżenie: dane o doradcy dotyczą modeli o różnej mocy, więc zawężonej tezy wprost nie testują. Przy zadaniu, które leży w zasięgu kilku modeli z czołówki, pytanie o model przestaje być pierwszym pytaniem. Pierwszym staje się pytanie, kto ten model sprawdza i według jakiej liczby. Przy zadaniu na granicy możliwości kolejność się odwraca i zaczynasz od modelu.

Trzy role, których nie łączy jeden wykonawca

Zacznijmy od ról. Planista rozkłada cel na kroki i kryteria akceptacji. Kwestionujący szuka w planie i w wyniku błędów, których planista nie widzi. Zatwierdzający ma prawo powiedzieć „nie” i ponosi skutki swojego „tak”. Czwarta rola, wykonawca, bywa osobna, a bywa połączona z planistą. Tych trzech pierwszych nie powinna pełnić jedna osoba ani jeden model, który widzi to samo co planista.

Powód nie jest estetyczny. W 2023 roku zespół Jie Huanga opublikował pracę Large Language Models Cannot Self-Correct Reasoning Yet, przyjętą potem na konferencję ICLR 2024. Autorzy pokazali, że duże modele językowe mają trudność z poprawą własnych odpowiedzi bez informacji z zewnątrz. W części zadań wynik po samokorekcie był gorszy niż przed nią. Badanie dotyczyło zadań rozumowania, więc nie przenoszę go wprost na każdą pracę agenta, ale wystarcza ono, żeby nie zakładać, że model sam wyłapie własne błędy.

Druga praca idzie dalej. Arjun Panickssery ze współpracownikami opisał w 2024 roku w pracy LLM Evaluators Recognize and Favor Their Own Generations skłonność modelu oceniającego do wyższego punktowania własnych tekstów. Modele takie jak GPT-4 i Llama 2 odróżniały swoje teksty od cudzych z nietrywialną trafnością, a w eksperymentach z dostrajaniem modeli siła tej preferencji rosła liniowo ze zdolnością rozpoznawania siebie. Kierunek jest zgodny z tym, co rewidenci wiedzą od dawna o zagrożeniu autoprzeglądem.

Wyprowadzam z tego regułę praktyczną, choć to moja rekomendacja, a nie wynik badań. Jeżeli ten sam model planuje, sprawdza i zatwierdza, masz jeden punkt widzenia w trzech kostiumach. Zakładam, że świeża sesja tego samego modelu usuwa wspólny kontekst rozmowy, ale nie usuwa skłonności, które ten model ma od treningu. Kwestionujący powinien więc w miarę możliwości pochodzić z innej rodziny modeli albo przynajmniej dostać inne wejście niż planista, na przykład same wymagania bez jego rozumowania. Zatwierdzający, przynajmniej przy decyzjach nieodwracalnych, powinien być człowiekiem z prawem weta.

Rynek narzędzi zaczął ten podział oferować jako gotowy wzorzec. Chase AI udostępnił na licencji MIT repozytorium claudex-loop: umiejętność dla Claude Code, którą da się też uruchomić w Codex. Pracuje w czterech fazach. Po rozpoznaniu i spisaniu wymagań z kryteriami akceptacji plan trafia do recenzji drugiego dostawcy. Recenzja kręci się w pętli, aż recenzent zatwierdzi plan, zablokuje go albo skończy się limit rund, domyślnie pięć. Kto zbudował kod, ten go nie ocenia: inspekcję robi drugi model w świeżej sesji.

W repozytorium znalazłem jeden wynik z użycia. Pierwszy pełny przebieg planowania systemu CRM dał 55 znalezisk w pięciu rundach, a autor sam nazywa to ilustracją, a nie kontrolowanym pomiarem. Nie wiemy więc, o ile claudex-loop zmniejsza liczbę błędów. Wiemy, jaki układ uznał za wart zbudowania.

Ciekawszy sygnał przyszedł od OpenAI. Firma opublikowała w repozytorium openai/codex-plugin-cc oficjalną wtyczkę, która pozwala wywołać Codex z wnętrza Claude Code, narzędzia konkurenta. Ogłoszenie na forum deweloperów OpenAI pochodzi z 30 marca 2026 roku. Wtyczka ma polecenie zwykłego przeglądu, polecenie przeglądu adwersarialnego, które kwestionuje decyzje projektowe, i opcjonalną bramkę. Bramka uruchamia przegląd Codex, gdy Claude kończy pracę. Autorzy uczciwie ostrzegają, że może szybko zużyć limity konta.

Rolka, która pokazywała wtyczkę, dodawała od siebie, że modele z natury fatalnie sprawdzają własną pracę. Nie znalazłem tego zdania w żadnym źródle OpenAI. Zostaje sam fakt i on wystarcza. Gdy laboratorium buduje narzędzie, w którym jego model recenzuje pracę modelu konkurenta, rozdzielenie ról przestaje być pomysłem jednego niezależnego twórcy. Oferuje je dostawca modeli, i to w narzędziu rywala.

Strategia doradcy rozdziela role wewnątrz jednej rodziny modeli, tyle że rozdziela władzę, a nie ocenę wyniku: wykonawca działa, a doradca może wyłącznie radzić. Do kwestionowania wyniku sięgnąłbym jednak po model z innej rodziny, choć to moja hipoteza, której nikt z cytowanych autorów nie zmierzył. Podział ról nie zawsze wymaga więc podziału dostawców. Wymaga jasnej odpowiedzi, kto może zmienić stan systemu, a kto może tylko zgłosić zastrzeżenie.

Rozdzielenie ról kosztuje. Każda runda recenzji to kolejne wywołanie modelu i kolejne tokeny. claudex-loop ma na to domyślne limity rund. Recenzja planu ma domyślnie pięć rund. Po budowie przysługują dwie próby poprawki, a inspekcja dostaje dwie rundy. Wtyczka OpenAI ostrzega przed szybkim zużyciem limitów konta. Kwestionujący bez limitu rund potrafi krążyć w pętli dłużej, niż zadanie jest warte.

Koszt nie musi jednak rosnąć. W teście Anthropic para Sonnet z doradcą Opus wyszła na zadanie o 11,9 procent taniej niż sam Sonnet, choć doradca jest droższym modelem. Źródło podaje, że doradca pisze krótki plan, zwykle 400–700 tokenów, rozliczany po stawkach Opusa. Oszczędności nie rozkłada jednak na składniki. Wniosek wyciągam sam i dotyczy on kwestionującego, nie doradcy: projektując układ, decydujesz także o tym, w którym momencie kwestionujący zabiera głos. Recenzja przy każdym kroku i recenzja przed decyzją nieodwracalną to dwa różne budżety.

Liczba ustalona przed zmianą

Trzy role bez liczby dają porządny proces, który nie wie, dokąd zmierza. Ostatni element układu to cel mierzalny i pomiar wyjściowy, ustalone, zanim agent zacznie zmieniać system. W sprincie Anthropic zespół zaczął od instrumentacji. Cele wyznaczył z szacunków samego Claude'a dla około dwudziestu wybranych projektów. Dwanaście z trzynastu celów osiągnął do trzeciego dnia, a potem ustawiał nowe. W innej firmie celem będzie czas obsługi zgłoszenia albo koszt jednego zadania w tokenach.

Bez liczby agent optymalizuje pod to, co da się ocenić wzrokiem. To również interpretacja, ale łatwa do zaobserwowania. Gdy jedynym sprawdzianem jest wrażenie recenzenta, praca zbiega do tekstu, który dobrze wygląda w przeglądzie. Liczba zmierzona na produkcji tego wrażenia nie podziela.

Zapadka z claude.ai robi z liczby bramkę, choć pilnowała miary zastępczej: liczby instrukcji na dwóch ścieżkach kodu. Jedna składa drzewo wiadomości, druga skanuje linię statusu w Claude Code. Nie trzeba było pamiętać o tej liczbie, bo CI odrzucał każdą zmianę, która ją podnosiła. Licznik instrukcji nie powie jednak, czy nowy wygląd ekranu jest dla użytkownika czytelny. Przy zmianach widocznych rozstrzygał zresztą człowiek na podstawie nagrań przed i po. Liczba pilnuje tego, co da się zmierzyć, a właściciel wątku tego, czego licznik nie zobaczy.

Zastosowanie jest proste i niewygodne. Zanim zlecisz agentom proces, zapisz jedną liczbę, sposób jej pomiaru i wartość wyjściową z ostatnich tygodni. Jeśli tej liczby nie umiesz podać, wdrożenie nie jest gotowe niezależnie od modelu. Za pół roku prawdopodobnie nikt nie będzie umiał powiedzieć, czy agenci cokolwiek poprawili.

Zatwierdzający, który przestaje czytać

W najbardziej zajęte dni sprintu, jak piszą autorzy, scalano ponad dwieście zmian, a każda dostała co najmniej jedną akceptację człowieka. Autorzy nie podają, ile osób zatwierdzało zmiany ani ile czasu zajmowała im jedna.

Ta liczba prowadzi do zarzutu, który trzeba postawić wprost, choć hipotetycznie. Gdyby jedna osoba zatwierdzała dwieście zmian dziennie, w pewnym momencie zaczęłaby klikać bez czytania. Akceptacja zostaje w procesie. Traci treść. Rola zatwierdzającego zamienia się wtedy w pieczątkę, a pieczątka nie wyłapie błędu, który przeszedł już obok planisty i kwestionującego.

Wpis Anthropic nie twierdzi, że ludzka akceptacja wystarczyła. Obok niej działały zapadki w CI i flagi funkcji. Zmiany wysokiego ryzyka szły najpierw do pracowników. Czytam to jako układ, w którym bezpieczeństwo nie zależy od uwagi jednej osoby w ostatniej godzinie dnia pracy. Wzrost liczby instrukcji na dwóch pilnowanych ścieżkach zatrzyma licznik w CI, a przy zmianie wysokiego ryzyka błąd przeoczony przez człowieka trafia najpierw do pracowników, potem do jednego procenta użytkowników, zanim ewentualnie dotrze do wszystkich. To moja interpretacja. Autorzy jej tak nie formułują.

Mój log pozwala policzyć to samo w mniejszej skali. W ciągu 22 dni agenci zużyli 208 moich zgód, czyli średnio niecałe dziesięć dziennie. Każda powstała po moim „tak” w rozmowie, choć co najmniej jedną znaną zużyła niewłaściwa sesja. Przy dziesięciu dziennie to się udaje. Przy dwustu bym nie czytał.

Wniosek dla projektanta układu jest konkretny. Bramkę z człowiekiem stawiaj tam, gdzie decyzja jest nieodwracalna, a liczba takich decyzji pozwala każdą przeczytać. Wszędzie indziej niech pilnują liczba, flaga i wdrożenie etapami. Zatwierdzający zasypany prośbami zostaje w schemacie organizacyjnym tylko z nazwy.

Mój układ: most dwóch agentów i strażnik

Opiszę układ, w którym sam pracuję, bo jego porażki mówią o topologii kontroli więcej niż sukcesy, a każdą z nich mam zapisaną w logu albo w regułach, które po niej powstały. Na co dzień pracuję w Claude Code. Drugi model, Codex od OpenAI, wykonuje przeglądy przez wspomnianą wtyczkę. Oba narzędzia logują się moimi subskrypcjami, więc w tym obwodzie nie płacę za wywołania API od tokena.

Najważniejsza część układu nie jest modelem. To skrypt-strażnik, który uruchamia się przed poleceniami wydawanymi przez agenta. Operacje nieodwracalne, takie jak wymuszone wypchnięcie, kasowanie plików i wdrożenie na produkcję, blokuje domyślnie. Do 11 października pilnował też wypychania na główną gałąź i scalania pull requestów przez GitHuba. Te dwie operacje przejął potem drugi strażnik. Gdy ten skrypt sam ulegnie awarii, przepuszcza polecenie i zapisuje awarię w logu, więc i ta bramka ma szczelinę. Zablokowaną operację przepuszcza dopiero wtedy, gdy istnieje jednorazowy token zgody, który powstaje po moim wyraźnym „tak” w rozmowie. Token ważny jest 30 minut. Zużywa się przy pierwszym użyciu.

Strażnik zapisuje każdą decyzję w logu, więc mogę podać liczby zamiast wrażeń. Od 25 września do wieczora 16 października 2026 roku zapisał 776 blokad. Wśród nich było 97 nieodwracalnych operacji git i GitHuba, 45 rekurencyjnych albo wymuszonych kasowań, 9 prób wdrożenia na produkcję i 6 prób wypisania pliku z sekretami. Do 11 października reguła obejmowała też wypchnięcia na główną gałąź i scalanie pull requestów przez GitHuba, więc część tych blokad mogła ich dotyczyć. W tym samym czasie 208 razy zużyto token zgody. Liczby obejmują wszystkie moje projekty i wszystkie sesje agentów. Pochodzą jednak tylko z jednego logu. Drugi strażnik prowadzi osobny log i nie wchodzi do tych liczb.

Największa grupa blokad mnie zaskoczyła. Aż 346 z 776 dotyczyło wyszukiwania rekurencyjnego z limitem czasu. Strażnik blokuje je, bo pusty wynik takiego wyszukiwania nie dowodzi, że czegoś nie ma. Wyszukiwanie mogło po prostu nie zdążyć. Ta reguła powstała po tym, jak agent ogłosił, że w projekcie nie ma pewnej funkcji, choć była. Około 45 procent blokad chroni więc jakość dowodu, a nie bezpieczeństwo danych.

Co się wywróciło? Dziewiątego września scalenie wylądowało na niewłaściwej gałęzi docelowej. Wcześniej, w sierpniu, diagnoza powstała na nieodświeżonej kopii repozytorium i opisywała stan, którego już nie było. Każde z tych zdarzeń zamieniłem w regułę: przed scaleniem sprawdź gałąź docelową, przed diagnozą pobierz najnowszy stan. Reguły zapisałem tam, gdzie agent czyta je przy każdej sesji, a najważniejsze egzekwuje strażnik.

Najbardziej pouczająca wpadka zdarzyła się 11 października. Pracowałem równolegle w dwóch sesjach nad dwoma projektami. Token zgody, który utworzyłem dla jednej sesji, zużyła druga. Zgoda poszła na cudzą operację. Naprawa polegała na przypięciu tokenu do identyfikatora sesji. Zgoda wydana jednemu wykonawcy przestała działać dla drugiego.

Ten incydent dobrze pokazuje, czym różni się kontrola od jej pozoru. Miałem rolę zatwierdzającego i miałem bramkę. Brakowało przypisania zgody do konkretnego wykonawcy. Gdy agentów jest więcej niż jeden, każda zgoda musi mieć adresata, a w firmie odpowiednikiem tej reguły jest pytanie, czyje uprawnienia dziedziczy agent, gdy działa w imieniu pracownika.

Co zostało? Zatwierdzanie przez człowieka operacji nieodwracalnych, log decyzji i zasada, że liczby w raporcie pochodzą z logu albo pomiaru. Żadna z tych rzeczy nie zależy od tego, który model akurat pracuje w terminalu.

Skala: kiedy centralna bramka ma sens

Pierwszego października 2026 roku Alok Srivastava wraz ze współautorami opisał na blogu inżynierskim Ubera platformę MCP Gateway. MCP to protokół kontekstu modelu (Model Context Protocol), przez który agenci wywołują narzędzia i usługi. Uber ma tysiące wewnętrznych usług. Poszczególne zespoły budowały integracje dla agentów niezależnie od siebie. Skutkiem było rozdrobnienie narzędzi i zdublowana infrastruktura. Autorzy piszą, że bez wspólnej architektury skalowanie MCP zwiększyłoby złożoność operacyjną, ryzyko bezpieczeństwa i tarcie po stronie programistów.

Bramka hostuje dziś ponad 800 serwerów MCP i ponad 5000 narzędzi. Autoryzacja działa na poziomie pojedynczego narzędzia. Ważniejsza od skali jest jednak jedna reguła. Każdy serwer i każde narzędzie startuje wyłączone i musi zostać przejrzane oraz włączone przez zespół, który jest jego właścicielem. Autorzy ujmują to jako zasadę projektową: wykrycie narzędzia nie oznacza jego udostępnienia. Każda zmiana opisu narzędzia wymaga akceptacji właścicieli serwera.

Uber ma rację u siebie. Przy tysiącach usług i setkach zespołów centralna bramka zastępuje liczne osobne integracje jedną infrastrukturą, a o włączeniu narzędzia nadal decyduje jego właściciel. Firma, która zatrudnia dwadzieścia osób, zwykle nie ma tego problemu i nie potrzebuje tej infrastruktury. Potrzebuje za to tej samej reguły. Narzędzie dla agenta startuje wyłączone, a włącza je osoba, która za nie odpowiada.

W małej firmie ta reguła mieści się w pliku konfiguracyjnym i w jednym nazwisku. To mój wniosek, Uber o małych firmach nie pisze. Granicy, od której opłaca się centralna bramka, nie znam i nie będę jej zgadywał. Sygnałem jest moment, w którym różne zespoły zaczynają budować te same integracje osobno.

Cztery pytania do dostawcy usługi AI

Jeśli kupujesz wdrożenie agentów, zadaj dostawcy pytania o układ, zanim zapytasz o model:

1. Kto kwestionuje wynik pracy agenta i czy jest to inny model, inna sesja, czy człowiek?
2. Gdzie stoi bramka, za którą agent nie przejdzie bez akceptacji człowieka, i kto ją zatwierdza?
3. Jaką liczbę mamy pobić, jak ją zmierzymy i jaka jest jej wartość dziś?
4. Co się stanie, gdy liczba się pogorszy: kto cofa zmianę i ile to trwa?

Pierwsze pytanie sprawdza, czy kwestionujący w ogóle istnieje. Dostawca, który odpowiada na nie nazwą modelu, odpowiada na inne pytanie.

Drugie pytanie sprawdza, czy bramka stoi przed operacją nieodwracalną, czy dopiero po niej. Raport po fakcie opisuje szkodę, której bramka miała zapobiec.

Trzecie pytanie odsłania, czy ktoś zmierzył stan wyjściowy. Bez dzisiejszej wartości nie dowiesz się za kwartał, czy agent cokolwiek poprawił. Dostawca, który nie zna odpowiedzi, sprzedaje ci wrażenie postępu.

Czwarte pytanie pada najrzadziej. W sprincie claude.ai odpowiedzią były flagi i wdrożenie etapami, więc wycofanie widocznej zmiany mogło sprowadzać się do wyłączenia flagi. Jeżeli dostawca odpowiada, że zmiany są przetestowane i cofać nie trzeba, usłyszałeś, że planu cofnięcia nie ma.

Pytanie o model zostaje uprawnione, ale przy zadaniu w zasięgu kilku modeli z czołówki pada jako piąte. Ma wtedy sens, bo wiesz już, do jakiej roli ten model trafi.

Te pytania działają również w drugą stronę. Jeżeli wdrażasz agentów sam, odpowiedz na nie na piśmie, zanim uruchomisz pierwszy przebieg. Odpowiedzi zajmą jedną stronę. Brak odpowiedzi na którekolwiek jest informacją ważniejszą niż każdy benchmark.

Co zostaje po wymianie modelu

Wpis o strategii doradcy pochodzi z kwietnia, a sprint claude.ai odbył się w sierpniu na wewnętrznym modelu, niedostępnym publicznie. Nazwy modeli w tym eseju zestarzeją się szybciej niż sam esej.

W firmie, która zaprojektowała układ kontroli, po wymianie modelu zostaje to samo: właściciel wątku, liczba z zapadką, log zgód i reguła, że narzędzie startuje wyłączone. Te rzeczy trzeba było zaprojektować raz. Przy następnej wymianie modelu nie trzeba ich projektować od nowa, choć progi i wartości wyjściowe trzeba zmierzyć ponownie. Jeśli twoje wdrożenie po zmianie dostawcy modelu trzeba budować od początku, kupiłeś model razem z jego obsługą, a układu kontroli nie masz wcale.

Bibliografia

1. primaryWang, R., Attard, S., Issac G. (2026). How we made claude.ai 3x faster in two weeks. Blog claude.dev, 23 września 2026. https://claude.dev/blog/how-we-made-claude-ai-faster/. Źródło liczb sprintu (p75 3,1 s → 0,55 s, średnia geometryczna 3,1 raza z 13 pomiarów), opisu ról i zapadek CI oraz deklaracji o ponad 3000 zmian bez incydentu.
2. primaryAnthropic (2026). The advisor strategy: Give agents an intelligence boost. Blog claude.com, 9 kwietnia 2026. https://claude.com/blog/the-advisor-strategy. Źródło wyników par wykonawca–doradca na BrowseComp i SWE-bench Multilingual.
3. primarySrivastava, A., Mehndiratta, D., Gill, G. i in. (2026). Designing MCP Gateway: Uber's MCP Management Platform. Uber Engineering Blog, 1 października 2026. https://www.uber.com/blog/designing-mcp-gateway/. Źródło skali bramki i reguły wyłączenia narzędzi do czasu przeglądu.
4. primaryHuang, J., Chen, X., Mishra, S., Zheng, H. S., Yu, A. W., Song, X., Zhou, D. (2023). Large Language Models Cannot Self-Correct Reasoning Yet. Preprint z 3 października 2023, przyjęty na ICLR 2024. https://arxiv.org/abs/2310.01798
5. primaryPanickssery, A., Bowman, S. R., Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. Advances in Neural Information Processing Systems 37 (NeurIPS 2024). arXiv:2404.13076. https://arxiv.org/abs/2404.13076
6. primaryOpenAI (2026). codex-plugin-cc, repozytorium wtyczki Codex dla Claude Code, ogłoszone 30 marca 2026 na forum OpenAI Developer Community, https://community.openai.com/t/introducing-codex-plugin-for-claude-code/1378186. Repozytorium: https://github.com/openai/codex-plugin-cc
7. primaryChase AI. claudex-loop, repozytorium na licencji MIT, stan na 16 października 2026. https://github.com/chaseai-yt/claudex-loop
8. primaryLog skryptu-strażnika autora, okres 25 września – 16 października 2026 roku. Materiał własny, niepublikowany. Źródło liczb blokad i zużytych zgód.
9. secondaryIFAC. Exploring the IESBA Code, odcinek 3 o ramach koncepcyjnych i ocenie zagrożeń, wersja z 2022 roku według adresu pliku. Omówienie ram koncepcyjnych kodeksu IESBA (część 1, sekcja 120) z pięcioma kategoriami zagrożeń, w tym zagrożeniem autoprzeglądem. https://www.ifac.org/system/files/publications/files/exploring-the-iesba-code-3-the-conceptual-framework-evaluating-threats-2022-version.pdf