Firma automatyczna, część 3: nadzorca, wykonawca, krytyk

3 listopada 2026

Wprowadzenie

To trzecia część serii „Firma automatyczna”. W części pierwszej pisałem, dlaczego w Elemencie oddajemy rutynę automatom. W części drugiej pokazałem mapę firmy, czyli spis procesów i automatyzacji, od którego warto zacząć. Dziś opisuję, kto u nas te automaty buduje i kto je sprawdza.

Agent AI, który napisał kod i sam go przetestował, zwykle melduje, że wszystko działa. Taki meldunek brzmi przekonująco także wtedy, gdy w kodzie jest poważny błąd. Dlatego pracę dzielimy między trzy role.

Trzy role

  • Nadzorca planuje pracę, dzieli ją na części, pisze dokładną specyfikację, sprawdza gotowy kod linia po linii i decyduje, czy zmiana trafia do działającego systemu.
  • Wykonawca pisze kod i testy według specyfikacji.
  • Krytyk to osobny agent, który dostaje gotowy wynik, cel i zasady, których nie wolno złamać. Nie zna rozumowania nadzorcy ani historii rozmowy. Szuka błędów, a decyzja, co z nimi zrobić, zostaje u nadzorcy.

Ja ustalam cele i rozstrzygam to, czego agenci nie powinni rozstrzygać sami. Tak działają nasze automatyzacje i tak rozwijamy Element, zarówno kod systemu rekrutacyjnego, jak i automatyzacje procesów biznesowych firmy. 

Jak ustawić te role

Rola to w praktyce kilka akapitów tekstu i osobno uruchomiona sesja z modelem AI. Na początek wystarczy narzędzie do pracy z agentami, na przykład Claude Code albo Codex.

  1. Nadzorcę ustawiasz w pliku zasad. Po uruchomieniu, agent czyta na starcie pracy plik z instrukcjami: Claude Code plik CLAUDE.md, Codex plik AGENTS.md. Zapisujesz w nim, że główna sesja planuje i sprawdza, sama nie pisze kodu i zleca go wykonawcy. Te zasady obowiązują w każdej rozmowie, więc nie trzeba ich powtarzać.
  2. Wykonawca dostaje osobną sesję i jedno zadanie. Nadzorca otrzymuje ode mnie zadanie i zapisuje je w pliku: co zmienić, w których miejscach i jakie testy mają przechodzić. Potem prostym skryptem uruchamia inny model (wykonawcę), przekazuje mu ten plik i wskazuje osobną kopię kodu. U nas ten sam skrypt pilnuje kolejności modeli, więc gdy pierwszy ma wyczerpany limit, zadanie dostaje następny.
  3. Krytyk dostaje nową, pustą sesję. Gdy wykonawca skończy pracę, nadzorca uruchamia nowego agenta (krytyka) bez historii rozmowy i przekazuje mu efekt pracy wykonawcy, cel oraz zasady, których nie wolno złamać. Polecenie może być krótkie: „Jesteś niezależnym krytykiem. Oto zmiana i jej cel. Znajdź błędy i podaj na nie dowody. Niczego nie poprawiaj. Jeśli czegoś nie da się sprawdzić, napisz to wprost.”

Skąd agenci wiedzą, co robić i w jakiej kolejności

Całym przebiegiem kieruje nadzorca, bo kolejność jest zapisana w pliku zasad. Wykonawca i krytyk dostają od niego po jednym zadaniu, wykonują je i oddają wynik. U nas wygląda to tak:

  1. Ja podaję cel.
  2. Nadzorca sprawdza obecny system i pisze specyfikację, czyli dokładny opis zadania.
  3. Wykonawca pisze kod i testy na osobnej kopii.
  4. Nadzorca czyta zmianę linia po linii i sam uruchamia testy.
  5. Przy rzeczach ryzykownych krytyk szuka błędów, po czym nadzorca sprawdza każdy zgłoszony błąd.
  6. Jeśli coś wymaga poprawki, wykonawca dostaje opis konkretnego błędu.
  7. Nadzorca włącza zmianę do działającego systemu i zapisuje ją w dzienniku zmian.

Sama zasada w pliku nie zawsze wystarcza, bo agent potrafi ją pominąć. Zmierzyliśmy to: zasady o uruchamianiu krytyka, zapisanej tylko tekstem, agenci nie przestrzegali. Dlatego przy najbardziej ryzykownych działaniach, takich jak mail do klienta wysyłany przez agenta albo kasowanie danych, mamy też blokady techniczne, które zatrzymują agenta. Opiszę je w osobnej części serii.

Role i modele

Dziś nadzorcą jest zwykle Claude Opus 5.5. Jest to model najlepszy według kluczowych rankingów, ale jednocześnie najdroższy. Zaprojektowaną przez nadzorcę pracę dostaje do wykonania najpierw Grok, po nim Codex, na końcu Gemini. Ta kolejność zmieniła się już kilka razy i pewnie zmieni się znowu, więc w zasadach firmy przywiązujemy się do ról, a nie do modeli. Konkretne modele są tylko aktualnym obsadzeniem ról. Gdy jeden z modeli wyczerpie limit, zadanie automatycznie przejmuje następny. We wrześniu pierwszy wykonawca ukończył 168 zaawansowanych zadań, 46 razy trafił na limit i za każdym razem dostępny był inny model, który mógł przejąć pracę.

Wykonawca, który coś napisał, nie ocenia własnej pracy. Zważywszy na to, że każdy z nas najłatwiej przeocza własne założenia, nie widzę powodu, żeby z modelami było inaczej. Poniżej pięć sytuacji z naszej firmy, które to pokazują.

Przykład 1: 526 zielonych testów i 13 błędów

Wykonawca podłączył płatną usługę, która weryfikuje poprawność adresów e-mail. Było to działanie związane z automatyzacją procesów sprzedażowych. Pierwsza wersja przeszła 526 testów. Niezależny krytyk znalazł w niej 13 błędów, w tym jeden dotyczący budżetu: gdy odpowiedź usługi nie zawierała informacji o koszcie, można było obejść wszystkie limity wydatków i tym samym narazić się na nieoczekiwany koszt.

Podejrzewam, że testy tego nie złapały, bo powstały z tym samym założeniem co kod, czyli że usługa zawsze podaje koszt. Test sprawdza to, co jego autor uznał za możliwe. Zielony wynik mówi więc sporo o spójności autora z samym sobą, a znacznie mniej o tym, co się stanie w prawdziwym świecie. Krytyk nie miał tych założeń i przez to mógł weryfikować scenariusze nieprzewidziane w testach wykonawcy.

Przykład 2: odmowa odczytana jako zgoda

Większość rozmów handlowych jest zautomatyzowana. Gdy klient napisze, że decyduje się na współpracę z nami, automat przesuwa rozmowę w CRM na etap zgody i przygotowuje szkic kolejnego maila: prośbę o dane potrzebne do uruchomienia systemu oraz zapowiedź umowy. Nasza automatyzacja taką decyzję klienta rozpoznawała między innymi po typowych frazach. Testy na przykładowych zdaniach przechodziły. Krytyk sprawdził regułę na prawdziwych mailach i okazało się, że ta sama fraza pojawia się też w uprzejmych odmowach, gdy klient pisze, że wybrał innego dostawcę. W CRM jedna rozmowa stała przez to na etapie zgody, choć klient odmówił, co fałszowało obraz sprzedaży. Dla innego klienta, który odmówił nam trzy lata temu, powstałby szkic prośby o dane do umowy. Gdyby taki mail wyszedł, wyglądalibyśmy niepoważnie. W dzienniku bota od końca sierpnia nie ma ani jednej takiej wiadomości, więc szkody nie było.

Tego samego dnia cztery z około 25 poprawek wykonawców przeszły testy, po czym krytyk na prawdziwych mailach pokazał, że są błędne. Wykonawca podczas implementacji przygotował testy ze zdaniami, które były zdecydowanie bardziej zrozumiałe i oczywiste niż to, co piszą klienci. W związku z powyższym przyjęliśmy zasadę, że zmiany w rozpoznawaniu odpowiedzi klienta sprawdza krytyk z dostępem do prawdziwej korespondencji.

Przykład 3: blokada, która działała odwrotnie

Gdy firma odmawia współpracy, chcemy dać jej dłuższy czas spokoju. Odezwiemy się w przyszłości, by sprawdzić, czy nie pojawiły się nowe okoliczności, które sprzyjają powrotowi do rozmów. Zmiana, która miała to wprowadzić, powstała, testy przeszły. Krytyk znalazł, że w praktyce dzieje się coś odwrotnego: w czasie przerwy inne osoby z tej firmy były dla automatyzacji wolne, więc mogły dostać od nas maila zaraz po tym, jak ich firma odmówiła.

Testy wykonawcy sprawdzały tylko to, co wykonawca implementował, czyli wstrzymanie komunikacji z osobą kontaktową. Sprawdzenie nie uwzględniało sytuacji, gdy mamy w CRM więcej osób kontaktowych w jednej firmie. Krytyk wychwycił błąd, którego wykonawca nie przewidział. Mamy teraz zasadę, że specyfikacja każdej zmiany dotyczącej tego, kto nie dostaje od nas maili, zawiera tabelę wszystkich sytuacji firmy (na przykład otwarta rozmowa, przerwa, koniec przerwy) i przejść między nimi, z osobnym testem na każdy wiersz.

Przykład 4: kod, który ruszył przed sprawdzeniem

Wykonawca zmieniał automat, który odpowiada osobom piszącym do nas przez formularz kontaktowy na stronie, czyli potencjalnym klientom. Edytował pliki w katalogu, z którego ten automat działa, a uruchamia się on co 10 minut. Cztery minuty po zmianie harmonogram wystartował z nowym kodem, zanim ktokolwiek go przeczytał. Niesprawdzony kod mógł więc od razu odpowiadać prawdziwym klientom. Nadzorca tego nie zauważył. Zauważył krytyk. Testy by tego nie pokazały, bo problem dotyczył miejsca i momentu zmiany. Wykonawcy pracują teraz na osobnej kopii, więc do działającego systemu zmiana trafia dopiero po sprawdzeniu.

Przykład 5: nadzorca też się myli

Czarna lista to spis firm i osób, do których nie wolno nam pisać. Na tę listę wpadają firmy, które poprosiły o to, aby więcej się z nimi nie kontaktować. Nadzorca przygotował plan pracy, według którego trafiłyby na nią tysiące pozycji z CRM, w tym wiele firm, z którymi właśnie prowadziliśmy rozmowy handlowe. Sami urwalibyśmy te rozmowy. Wykonawca, który nie znał rozumowania nadzorcy, zatrzymał pracę, zanim cokolwiek zmienił.

Moim zdaniem wykonawca zauważył ten błąd właśnie dlatego, że nie znał wcześniejszych ustaleń nadzorcy. Kto zna całą historię decyzji, patrzy na wynik przez te same założenia, które do niego doprowadziły.

Kiedy krytyka nie uruchamiamy

Każde sprawdzenie przez krytyka to dodatkowa praca modelu AI, za którą płacimy. Dlatego uruchamiamy go tam, gdzie pomyłka jest droga albo nie da się jej cofnąć: przy mailach do klientów, przy zmianie dużej ilości danych naraz, przy dokumentach wychodzących poza firmę i przy płatnych usługach. Gdy błąd łatwo naprawić, krytyka pomijamy.

Sprawdziliśmy też, czy warto sprawdzać to samo wiele razy z rzędu. Taka seria kosztowała ponad milion tokenów (to jednostki, w których rozlicza się pracę modeli AI), a znalazła mniej więcej tyle samo co jedno sprawdzenie.

Krytyk też się myli, więc nie wierzymy mu na słowo. Nadzorca sam sprawdza każdy zgłoszony błąd i dopiero wtedy decyduje. Każda z tych ról może się pomylić. Rzadko jednak pomylą się w tym samym miejscu, dlatego 3 agentów niezależnie weryfikujących kod, to skuteczna metoda minimalizowania ryzyka błędów finalnej implementacji.

W kolejnej części serii opiszę, jak zapisujemy sposób pracy firmy w jednym zbiorze zasad, żeby znał go każdy agent, niezależnie od dostawcy.

Więcej o tym, czym jest ATS i jak działa Element, przeczytacie tutaj.

Najczęściej czytane:

  1. Darmowe ogłoszenia o pracę i największa lista źródeł kandydatów – największa w Polsce lista bezpłatnych i płatnych źródeł kandydatów
  2. Praca w HR – najnowsze oferty pracy i aktualne średnie wynagrodzenia w branży HR
  3. Akademia Rekrutacji – zbiór wiedzy na temat rekrutacji oraz raporty z rynku pracy.
  4. Gowork – jak reagować na negatywne opinie o pracodawcach – Kompleksowy poradnik dla pracodawców.
  5. Jak napisać CV i profil LinkedIn – kompleksowy poradnik tworzenia CV i profilów LinkedIn
  6. RODO w rekrutacji – sourcing, direct search, ogłoszenia. Wszystko co musisz wiedzieć – kompleksowy poradnik RODO w rekrutacji z naciskiem na działania typu direct search / sourcing.
  7. Wszystko o systemach ATS – poradnik wyboru systemu rekrutacyjnego
  8. Umowy przedwstępne i listy intencyjne w procesach rekrutacyjnych – wszystko, co musisz wiedzieć o prawnych zabezpieczeniach zobowiązania do zatrudnienia.
Picture of Maciej Michalewski

Maciej Michalewski

Founder & CEO @ Element

Element cennik baner

Nasze artykuły przeczytasz także na Medium, LinkedIn, Substack, Reddit

Ostatnie wpisy: