Agentowe workloady psują założenia testowania oprogramowania - i ukrywają to do momentu, kiedy jest za późno

Ten news ukazał się 2 godziny po komunikacie źródła.

👁 121 przeczytań

Tradycyjne systemy enterprise opierają się na trzech założeniach: zadania kończą się szybko, ponowne uruchomienie jest bezkosztowe, a te same dane wejściowe dają te same wyniki. Agentowe workloady łamią wszystkie trzy naraz - i właśnie to wyjaśnia, dlaczego pilotaże z agentami AI działają sprawnie pod nadzorem człowieka, a rozpadają się w produkcji.

Analizę tych problemów opublikował w SiliconAngle M. Touheed, wskazując trzy konkretne pęknięcia w dotychczasowych praktykach.

Trzy właściwości, których agenci nie mają

Po pierwsze, czas wykonania. Agentowe zadanie może trwać minuty, nie milisekundy - wystarczająco długo, by przekroczyć progi timeoutów, których żaden element stosu wcześniej nie widział. Systemy, które wyglądały na stabilne, zaczynają się wysypywać w sposób, który wygląda tajemniczo, dopóki ktoś nie sprawdzi czasu trwania.

Po drugie, koszt ponownych prób. W tradycyjnym oprogramowaniu retry jest praktycznie bezpłatny, więc zespoły stosują go hojnie. Przy agentach każda próba przeciwko modelowi rozliczanemu per użycie zużywa zasoby obliczeniowe, niezależnie od tego, czy wynik jest użyteczny. Ponieważ rozliczenia za API chmurowe i modele są asynchroniczne i wypadają w miesięcznych cyklach, skumulowane koszty powtórzeń rosną cicho i stają się widoczne dopiero gdy przychodzi faktura - tygodnie później.

Po trzecie, niemożność reprodukcji błędu. To według Touheed największa zmiana. Standardowa praktyka po wykryciu złego wyniku to ponowne uruchomienie i obserwacja błędu. Przy agentach to nie działa: bez krokowego śladu decyzji agenta, wywołań narzędzi i uruchomień API nie ma czego badać, a analiza sprowadza się do spekulacji.

Dlaczego pilotaż tego nie pokazuje

Środowisko ewaluacyjne ukrywa wszystkie te problemy, bo w trybie interaktywnym to człowiek pełni rolę obsługi błędów. Czyta każdy wynik, zauważa problemy, poprawia ręcznie. Koszty są widoczne, bo próby są liczone i naprawiane z palca. Nie ma potrzeby tworzenia śladu audytowego ani mechanizmu reprodukcji błędu.

Automatyczny workflow agentowy działa inaczej: uruchamia się bezgłowo, bez nikogo przy konsoli. Jak pokazuje materiał, workflow, który działał niezawodnie gdy człowiek rozmawiał z AI i sprawdzał każdą odpowiedź, zachowuje się inaczej, gdy harmonogram odpala go 400 razy w nocy bez nadzoru. Błąd był zawsze - był tylko niewidoczny, bo operator ludzki absorbował go i korygował po jednej odpowiedzi na raz.

Stąd praktyczny wniosek: przed przejściem do zautomatyzowanej produkcji z agentami liderzy inżynieryjni muszą zinwentaryzować każde zadanie, które człowiek wykonywał ręcznie, i wskazać, który automatyczny mechanizm przejmie tę odpowiedzialność. Touheed rekomenduje też konkretną zmianę w rozmowach budżetowych: zamiast pytać o koszt wywołania API, pytać o koszt jednostki ukończonej - ta druga liczba wyklucza odrzucone próby i daje realny obraz wydatków.

To jeden z tych artykułów, który warto pokazać każdemu, kto właśnie ogłasza, że „pilot poszedł świetnie” i planuje wdrożenie produkcyjne na przyszły kwartał.