Agent kończy pracę i melduje: „gotowe”. Otwierasz efekt — i się sypie. Strona nie ładuje połowy elementów, automatyzacja przepuszcza dziwne dane, diagram ma nachodzące na siebie podpisy. Model był przy tym zupełnie pewny siebie. I to jest pierwsza rzecz, którą musisz sobie ułożyć w głowie, jeśli zaczynasz pracować z agentami AI: „gotowe” nie znaczy „działa”.
Pokażę ci, dlaczego sama deklaracja agenta jest bezwartościowa, dlaczego zapytanie „czy to wygląda dobrze?” niczego nie wyłapie, i co zrobić zamiast tego — jak ustawić jeden mały mechanizm, dzięki któremu agent sam sprawdzi swoją pracę, zanim odda ci ją z powrotem.
„Gotowe” to nie dowód
Częsty błąd, który widzę u osób zaczynających z agentami: traktują słowo „gotowe” jak odbiór pracy. Agent napisał kod, wygenerował dokument, zbudował automatyzację — powiedział, że skończył, więc zakładasz, że skończył.
Tymczasem agent ocenia własną robotę, patrząc na to, co sam stworzył. To trochę tak, jakby uczeń sprawdzał własne wypracowanie, czytając je jeszcze raz — bez patrzenia, czy odpowiedzi są poprawne. Może mu się wydawać, że wszystko gra, bo myśli dokładnie tak, jak wtedy, gdy to pisał. Przeoczenie, które tam popełnił, popełni i przy sprawdzaniu.
Dlatego moim zdaniem weryfikacja sprowadza się do jednego zdania, które warto sobie powtarzać: udowodnij mi, że to naprawdę jest skończone i naprawdę działa. Nie „powiedz mi”. Nie „oceń sam”. Udowodnij — pokaż wynik, który widać.
Dlaczego pytanie „czy to dobre?” cię oszuka
Jest jeszcze druga, mniej oczywista pułapka. Modele językowe mają skłonność, którą nazywam byciem potakiwaczem — po angielsku mówi się o tym sycophancy. To znaczy, że model dopasowuje się do tego, co chcesz usłyszeć. Pytasz „zrobiłem to tak, dobrze wyszło?” — i z dużym prawdopodobieństwem usłyszysz „tak, świetnie”, bo model wyczuwa, że właśnie tej odpowiedzi oczekujesz.
Proszenie agenta o opinię to śliska droga. Im bardziej pytanie dotyczy oceny, gustu, „czy to jest dobre”, tym więcej w odpowiedzi jest przypochlebiania, a mniej prawdy.
I tu jest sedno: przy konkretnym sprawdzeniu nie ma miejsca na potakiwanie. Jeśli pytasz nie o opinię, tylko o fakt — czy strona się otwiera, czy automatyzacja poprawnie obsłużyła dane, czy w diagramie nic na siebie nie nachodzi — odpowiedź jest czarno-biała. Działa albo nie działa. Nie ma szarej strefy, w której model mógłby ci pochlebić.
To jest cała zmiana, której cię uczę. Przestań pytać „czy myślisz, że to dobre?”. Zacznij mówić „pokaż mi, że to działa”.
Daj agentowi obudowę, w której sam sprawdzi efekt
Skoro samo „gotowe” nie wystarczy, a o opinię pytać nie warto, potrzebujesz mechanizmu, który zmusza agenta do dostarczenia dowodu. W praktyce buduje się go raz, a potem działa przy każdym zadaniu. Nazwę go obudową.
W najprostszym ujęciu obudowa to to, co otacza sam model — narzędzia i kontekst, które pozwalają mu nie tylko myśleć, ale realnie coś zrobić i sprawdzić. Samo narzędzie AI, którego już używasz, jest taką obudową: pod spodem siedzi model językowy, a wokół niego — możliwość uruchamiania poleceń, otwierania plików, sięgania po dane. Na tym możesz dobudować własny, mały krok sprawdzający, dopasowany do tego, co konkretnie robisz. I tylko tyle musisz z tego zrozumieć — reszta to już techniczne szczegóły, w które nie ma sensu się tu zagłębiać.
Zasada, która sprawia, że to wszystko działa, jest prosta: każ agentowi sprawdzić efekt tak, jak zrobiłby to użytkownik. Patrzenie na własny kod albo na własny opis pracy to za mało — to wciąż tylko „przeczytanie wypracowania jeszcze raz”. Daj agentowi sposób, żeby naprawdę użył tego, co zbudował, i obejrzał wynik.
Dwa konkretne przykłady, jak ten mechanizm wygląda w praktyce:
- Strona internetowa. Zamiast czytać kod strony, agent dostaje narzędzie, które otwiera ją w prawdziwej przeglądarce — dokładnie tak, jak zrobiłby to odwiedzający. Klika się przez nią, robi zrzuty ekranu i na nich sprawdza, czy wszystko wygląda i działa, jak powinno. Jeśli coś jest nie tak, poprawia i sprawdza ponownie.
- Diagram albo grafika. Agent nie ogląda samego „przepisu” na obrazek. Renderuje go do prawdziwego pliku graficznego, a potem patrzy na ten obraz — i wyłapuje to, czego z opisu nie widać: nachodzące na siebie podpisy, złe odstępy, bałagan w układzie. Poprawia, renderuje jeszcze raz i ogląda powtórnie.
W obu wypadkach kluczowe jest to samo: agent używa efektu i patrzy na wynik, a nie zapewnia, że wszystko jest w porządku.
Pierwsze podejście nie musi być idealne
Tu zaczyna się część, którą wiele osób rozumie opacznie. Nie chodzi o to, żeby agent zrobił wszystko bezbłędnie za pierwszym razem — to się prawie nigdy nie zdarza. Pierwsza wersja diagramu miała nachodzące podpisy, pierwsza wersja strony coś gubiła. To normalne.
Wczesne, niechlujne podejścia nie mają znaczenia. Liczy się tylko jedno: czy agent potrafi sam poprawić swoją pracę aż do czystego efektu — bez twojego udziału na każdym kroku i bez przepalania absurdalnej ilości pracy na drodze. To, co finalnie ci oddaje, jest tym, co się liczy.
I właśnie po to jest obudowa. Bez tego kroku sprawdzającego pierwsza wersja bywa tylko z grubsza dobra — wygląda sensownie, ale w paru miejscach się sypie. Z nim to, co dostajesz na pierwszy rzut, jest znacznie bliżej działającego, bo agent sam przeszedł kilka rund poprawek, zanim w ogóle pokazał ci wynik.
Zdefiniuj „skończone”, zanim agent zacznie
Jest jeden warunek, bez którego cała weryfikacja nie ruszy: agent musi wiedzieć z góry, jak ma ci udowodnić, że skończył. Sprawdzanie działa tylko dlatego, że jeszcze przed startem powiedziałeś mu dokładnie, co będzie dowodem ukończenia.
Dobrze widać to w całym łuku pracy z agentem: najpierw planujesz, potem oddajesz budowę agentowi, a na końcu weryfikujesz. Ten artykuł jest o tej ostatniej części — ale to, czy ona zadziała, ustalasz już na początku, w planie. Definicja „skończonego” — jak konkretnie agent pokaże ci, że praca jest gotowa i działa — należy do planu, nie do improwizacji na końcu. (Samego planowania uczę osobno; tu wystarczy wiedzieć, że weryfikacja bez wcześniejszej definicji jest ślepa.)
Zaczynasz więc od spisania, co właściwie budujesz i jak będzie wyglądał dowód, że to działa. Dopiero wtedy oddajesz robotę agentowi — bo zarówno ty, jak i on wiecie, na czym ma polegać sprawdzenie.
Pytaj „co może pójść nie tak?”
Na koniec pokażę ci pytanie, które jest zaskakująco rzadko zadawane, a moim zdaniem należy do najbardziej wartościowych w całej tej pracy: co może się tu zepsuć?
Część osób boi się je zadać — jakby szukanie dziur we własnej robocie było przyznaniem się do błędu. A jest dokładnie odwrotnie. To pytanie warto wbudować na stałe w krok sprawdzający. Gdy agent skończy, każesz mu zapytać samego siebie: co może tu pójść nie tak? Gdzie ten efekt się posypie?
Szczególnie warto polować na przypadki brzegowe — czyli rzadkie, nietypowe sytuacje, na których rzeczy się sypią. Wyobraź sobie automatyzację, która przyjmuje jakieś dane. Pytasz: a co, jeśli ktoś poda dane w dziwnym, niepoprawnym formacie? Wtedy projektujesz mały test, który celowo próbuje to zepsuć — podajesz właśnie takie pokraczne wejście i patrzysz, co się stanie.
A jeśli się zepsuło — i to jest punkt, o którym łatwo zapomnieć — poprawiasz i sprawdzasz jeszcze raz tym samym testem. Bo twoja poprawka wcale nie musiała naprawić problemu. Znalazłeś usterkę, naprawiłeś, ponownie przetestowałeś. Dopiero wtedy wiesz, że naprawdę jest dobrze.
To zamyka pętlę. Definiujesz z góry, co znaczy „skończone”. Dajesz agentowi sposób, żeby użył efektu tak jak użytkownik. Każesz mu zapytać, co może się zepsuć, i spróbować to zepsuć. A gdy coś pęka — poprawia i testuje od nowa, aż przejdzie.
Tyle wystarczy, żeby to, co agent oddaje na pierwszy rzut, przestało być „wygląda sensownie, ale się sypie”, a stało się „naprawdę działa”. Nie pytaj, czy skończył — każ udowodnić, że działa. A następnym razem, zanim oddasz agentowi jakiekolwiek zadanie, zacznij od jednego zdania: jak konkretnie pokażesz mi, że to działa?